SSHole: the OpenSSH flaw that opens the door to a very long password, and what CISOs should check today

On Thursday 5 November 2026 the OpenSSH project shipped version 10.6p2 with what it called "a critical security workaround" for Linux systems that use the musl C library with PAM switched off. Within hours, attackers were trying it. By Friday, security researchers running honeypots had recorded successful logins, including root access on a test machine running Alpine Linux.

The flaw is tracked as CVE-2026-123158 and has been nicknamed SSHole. It only affects certain configurations, which is the good news. The bad news is that where it applies, it is about as simple as an attack gets.

What is the problem?

Alpine Linux's own advisory puts it plainly: "An attacker who can reach your SSH port can log in without knowing any password. It takes one connection, works every time, and needs no retries."

The attacker sends a password between 257 and 1,024 bytes long. On affected systems, the way sshd checks passwords without PAM meets the way musl handles over-long input, and an account that has no password at all (shown as `*` in the password file) is treated as a match. Those are often exactly the accounts you would expect to be safe: key-only service and deploy users, users pulled in from a directory service, and in some official Alpine cloud images, a default user with passwordless admin rights.

A system is exposed when all of these are true:

• sshd runs on musl-based Linux without PAM (Alpine's default `openssh-server` package is built this way)
• password authentication is switched on, which is the OpenSSH default
• there is at least one account with `*` in its password field
• at least one other local account has a real password hash

Systems built on glibc, such as standard Debian, Ubuntu and Fedora installs, are not affected. Neither are systems that check passwords through PAM, or containers that do not run sshd.

Why this is a CISO problem and not just a sysadmin ticket

The gap between fix and attack has shrunk to hours. The fix and the public explanation landed on 5 November. One threat intelligence firm saw its first attempt less than nine hours after the CVE was published and confirmed a successful break-in on one of its honeypots. Proof-of-concept code is already public on GitHub. Waiting for the next monthly patch window is not a plan for this one.

It hides in places your asset register may not reach. Alpine is popular for lightweight servers, cloud images and container hosts because it is small. The researcher who found the bug also suggests checking other musl-based platforms such as OpenWrt, Buildroot and Yocto, which turn up inside routers, appliances and embedded devices. Many teams cannot say off the top of their heads which of their systems run musl.

Patching is not finished until sshd restarts. Alpine warns that upgrading the package does not replace the running daemon. A host can show as patched in your tooling and still accept the attack until the service is restarted.

It is a sign of things to come. In its release notes, the OpenSSH team says it now receives a large number of security bug reports found with AI help, and that bugs found this way are often found again by someone else. It has moved to more frequent releases as a result. Expect more fixes, faster, and less time between disclosure and exploitation.

What to do this week

1. Find your musl estate. Ask infrastructure, cloud and product teams for a list of Alpine hosts and images, plus any appliances or embedded devices built on musl-based platforms that expose SSH. Include build servers, jump boxes and anything in a lab that faces the internet.
2. Patch and restart. On Alpine, update `openssh` (fixed packages are available back to 3.16, including releases that are out of support) and then restart sshd. Ask vendors of affected appliances when firmware with the fix will be available.
3. Switch off password logins where you can. Setting `PasswordAuthentication no` and restarting sshd closes the hole even before patching. Most production servers should be key-only anyway. Test key access first and keep a session open while you make the change.
4. Take SSH off the open internet. The Dutch National Cyber Security Centre's advisory makes the point that management services like SSH should not be exposed directly to the internet. Put them behind a VPN, a bastion host or an allow list.
5. Check for signs of a break-in. Alpine suggests looking in `/var/log/messages` for "Accepted password for" entries against accounts that have no password, such as `alpine`, `root` or key-only users. Review admin use, new accounts, new files and changes to authorised keys on exposed machines. If you cannot rule out a login, treat the machine as compromised.
6. Do not run proof-of-concept code from strangers. Several public exploits have appeared. Researchers have warned that some are unverified and could carry malware. Use the vendor advisories and your own safe checks instead.

What not to panic about

This is not a flaw in every SSH server. Most mainstream Linux distributions use glibc and PAM, and are outside its scope. Alpine says cloud images configured through cloud-init are not affected, because cloud-init switches password logins off. The Dutch NCSC rated its advisory as normal priority because of how specific the conditions are. That said, CISA added the flaw to its Known Exploited Vulnerabilities catalogue on 9 November, which confirms it is being used in real attacks, and gave US federal agencies until 12 November to deal with it.

But "specific" is not the same as "rare". The systems most likely to be affected are the small, quiet ones that nobody has looked at in a while. That is why it is worth an hour of your team's time today.

The bottom line for CISOs

SSHole is a narrow bug with a wide lesson. A fix and a working attack now arrive almost together, so the questions that matter are the basic ones. Do you know where your Linux variants run? Are password logins switched off where they should be? Is SSH reachable from the internet when it does not need to be? If those answers are clear, this week's fix is a short job. If they are not, this is a good moment to find out.

Sources

• OpenSSH, Release Notes, OpenSSH 10.6p2 (5 November 2026): https://www.openssh.com/releasenotes.html
• Alpine Linux, "Security advisory: openssh-server password authentication bypass", 5 November 2026: https://alpinelinux.org/posts/2026-11-05-openssh-password-authentication-bypass/
• Alpine Security Tracker, CVE-2026-123158 (fixed package versions by branch): https://security.alpinelinux.org/vuln/CVE-2026-123158
• Nationaal Cyber Security Centrum (Netherlands), Advisory NCSC-2026-0469, 6 November 2026: https://advisories.ncsc.nl/2026/ncsc-2026-0469-0.pdf
• Help Net Security, "OpenSSH flaw exploited in the wild just hours after disclosure (CVE-2026-123158)", 6 November 2026: https://www.helpnetsecurity.com/2026/11/06/openssh-sshole-cve-2026-123158-exploitation/
• CISA, Known Exploited Vulnerabilities Catalog (CVE-2026-123158 added 9 November 2026, federal due date 12 November 2026; checked 13 November 2026): https://www.cisa.gov/known-exploited-vulnerabilities-catalog

Image: Sergei Starostin on Pexels (Pexels License).