"Set PasswordAuthentication=no or disable SSH for these systems IMMEDIATELY," OpenSSH developer Damien Miller said, summing up an emergency response to a flaw that lets specially crafted long passwords bypass SSH authentication on some Alpine Linux systems.
How the bypass works: sshd, musl, and crypt()
The vulnerability is a precise interplay between OpenSSH's sshd, musl (the C library Alpine uses), and crypt(), the library call sshd uses to hash a login attempt. When sshd is built without PAM and must check passwords itself, it hashes the supplied password with crypt() and compares the result to the stored field in /etc/shadow. An account with no password stores a single asterisk (*) in that field; that is too short to contain the salt crypt() needs, so sshd borrows the salt from another account on the machine that does have a real hash.
For $5$ and $6$ hash types, musl's crypt() returns * when a supplied password exceeds 256 bytes, signalling an error. Because sshd then compares that returned * to the stored * for a passwordless account, the values match and sshd accepts the login. Sshd itself limits password inputs to 1,024 bytes, so the exploitable range is between 257 and 1,024 bytes.
The behavior traces to changes in musl in 2012 (an Aug. 9 change to return an "unmatchable hash rather than NULL," and an Aug. 29 change limiting passwords to 256 bytes) and to a 2016 OpenSSH change that caused sshd to borrow salts after CVE-2016-6210. OpenSSH describes the 10.6p2 change as a workaround that makes sshd refuse matches when the stored field is shorter than four characters; the project says the root cause lies outside sshd.
Which Alpine systems and users are exposed
Alpine's advisory lists four conditions that must all be true for a server to be exposed: it runs the openssh-server package built without PAM (or runs openssh-server-pam with UsePAM no); PasswordAuthentication is yes (the OpenSSH default); an account's shadow entry contains only * (meaning no password set); and at least one other local account has a $5$ or $6$ password hash. An attacker also needs the username of an account with no password.
On Alpine, examples of passwordless accounts include key-only users created with adduser without a password (or with usermod -p '*'), users from a directory service through musl-nscd that lack a shadow entry, the root account where root:* shipped in the base image since around Alpine 3.16, and the alpine user in tiny-cloud images built with tiny-cloud.
Some default protections do not fully mitigate the risk: PermitRootLogin prohibit-password protects root unless PermitRootLogin yes is set, and that does not prevent escalation if an exposed account can become root (for example, via doas). The tiny-cloud images from 3.18.11 through 3.24.3 give the alpine user passwordless doas; those images are safe at first boot but become vulnerable once any $6$ hash exists on the machine (for example, after an admin sets a console password). Containers that do not run sshd, systems already running PasswordAuthentication no, cloud images provisioned by cloud-init (which writes that setting), and accounts locked with ! in /etc/shadow are not affected. The advisory says the attack succeeds on every try with a single connection and that no attacks using the flaw have been reported.
Your scanner finds 4,000 vulns. Which 12 matter?
Nubivance is a Rapid7 Registered Partner delivering vulnerability management as a service - scanning, risk-based prioritization, and remediation follow-through across IT and OT.
Fix the backlogPatching and short-term mitigations
OpenSSH rated the flaw critical and released version 10.6p2 to block the behavior on Nov. 5, 2026. Alpine has published fixed packages for every release back to 3.16; point releases 3.21.10, 3.22.8, 3.23.8 and 3.24.4 already include the fix, and branches 3.16 to 3.21—though past end-of-support—also received fixed packages. No CVE identifier had been assigned as of today.
On Alpine the advisory prescribes a package upgrade followed by a manual restart, because upgrading the openssh-server package does not restart the running sshd. The commands it gives are:
- apk upgrade -U -a
- rc-service sshd restart
If immediate updating is impossible, the advisory tells administrators to first confirm SSH key logins work (keeping the current session open until a new login succeeds), then set PasswordAuthentication no, verify the configuration with sshd -t, and restart sshd. The advisory also shows how to add the setting in a drop-in file under /etc/ssh/sshd_config.d and recommends ensuring sshd -T | grep -i passwordauthentication prints passwordauthentication no afterward.
Operators should also search /var/log/messages for sshd lines reading Accepted password for an account that has no password (for example, alpine or root) and review recent doas use, recently created users, files, and authorized_keys. The advisory states, "If you cannot rule out a login, treat the machine as compromised."
How cloud and embedded operators, and system administrators should react
Cloud and image operators: Tiny-cloud images built prior to the fixed point releases must be updated or have PasswordAuthentication disabled. Images are safe at first boot but can become exposed after an administrator creates any $6$ hash on the machine.
OpenWrt, Buildroot, and Yocto builders: Özgün Kültekin, who reported the problem, named these musl-based systems as additional platforms to check. OpenWrt uses Dropbear by default and Dropbear is not affected, but the advisory warns the flaw can matter on OpenWrt only when an admin has installed OpenSSH.
System and security administrators: Follow the Alpine advisory's two parallel tracks—apply the fixed openssh-server packages and restart sshd, or (if you cannot update immediately) disable password authentication after confirming keys work. Review logs for unexpected "Accepted password for" entries and treat any doubt about logins as potential compromise.
OpenSSH said its team moved and published the fix rapidly after learning of the issue earlier in the week, noting in the release announcement that "the team now sees long embargoes as dangerous and mainly helpful to attackers" because AI agents have been rediscovering bugs quickly. For operators, the immediate choice is stark and simple: patch and restart sshd, or turn off password authentication until you can.
