Facts checked Nov 7, 2026
OpenSSH fixed on Nov. 5 a bypass that lets anyone reaching sshd on musl Linux without PAM log in to password-less accounts; find those hosts, upgrade and restart sshd.
What happened
OpenSSH 10.6p2, released Nov. 5, carries a workaround for a password bypass on Linux systems using musl libc with PAM disabled. The project says the root cause is outside sshd and credits Özgün Kültekin of Wakefield.
Alpine's advisory explains the mechanism. musl's crypt() returns * as an error when the password is over 256 bytes, and * is also what the password field holds for every account with no password. So a password over 256 bytes matches those accounts. The CVE is CVE-2026-123158.
Who is affected
Alpine lists four conditions: you run openssh-server (built without PAM) or openssh-server-pam with UsePAM no; PasswordAuthentication is yes, the OpenSSH default; an account has * as its password field; and at least one local account has a $5$ or $6$ hash. Directory users that come through musl-nscd (nslcd, winbind, sssd) count too, Alpine says, since they have no shadow entry.
Root ships as root:*, but the default PermitRootLogin setting protects it. Alpine warns that does not help if another account that can log in can become root through doas. On Alpine tiny-cloud images the alpine user has passwordless doas.
OpenSSH's Damien Miller wrote on Nov. 5 that non-Linux systems, Linux/glibc systems and Linux systems using PAM for passwords do not have the bug. Kültekin's site adds Dropbear and OpenBSD. Containers that do not run sshd are not affected, Alpine says.
Kültekin also says to check OpenWrt, Buildroot, Yocto and "a lot of the docker images you've pulled". Buildroot, OpenWrt's package feed and Yocto's OpenEmbedded-core moved their main development branches to OpenSSH 10.6p2 on Nov. 5 and 6.
What to do now
- Platform team, today: list every musl host or image that runs sshd, including Alpine VMs, container images starting sshd, and appliances built on OpenWrt, Buildroot or Yocto, then check the four conditions.
- System owners, today: upgrade to OpenSSH 10.6p2 or your distribution's fixed package, then restart sshd. Alpine's fixed packages are 10.6_p2-r0 (edge), 10.3_p1-r2 (3.24) and 10.2_p1-r1 (3.23); the advisory lists older branches. Alpine says upgrading alone does not replace the running daemon. Where you cannot update, set PasswordAuthentication no and restart sshd; Alpine says either step closes the hole. Also narrow SSH reachability.
- SOC, today: on exposed machines search /var/log/messages for sshd lines reading "Accepted password for" an account with no password (alpine, root or any key-only user). Review doas use, recently created users, new files and authorized_keys. If you cannot rule out a login, Alpine says to treat the machine as compromised. Go back as far as your logs allow.
- Everyone, now: do not test with public exploit code. Previdian says the proof-of-concept code posted on GitHub is unverified and could contain malware.
How strong is the exploitation report
Previdian founder Ryan Dewhurst told Help Net Security on Nov. 6 that the first attempt came less than nine hours after CVE publication, and that the company confirmed root on one of its honeypots running real Alpine and OpenSSH. Follow-on commands were reconnaissance (id, uname, hostname). At that point Previdian counted eight attempts from one Japan-based address, all on one sensor.
As of Nov. 7, about 11:55 UTC, Previdian's tracking page showed 17 attempts from 11 addresses on 4 sensors. It says the counts do not show that a target was vulnerable or that an attempt succeeded. The page's own text does not repeat the root claim. We found no report of a victim outside the honeypot. As of 11:55 UTC on Nov. 7, CISA's KEV catalog did not list the CVE.
