- What: OpenSSH disclosed a critical flaw where sshd built without PAM on musl-based systems like Alpine Linux accepts any password of 257 to 1,024 bytes for accounts that have no password set.
- Impact: An attacker with network access and one valid username can log in to key-only, directory-sourced or default cloud accounts, and on tiny-cloud images from 3.18.11 through 3.24.3 can escalate to root through passwordless doas.
- Fix / mitigation: OpenSSH 10.6p2 fixes the flaw, Alpine point releases 3.21.10, 3.22.8, 3.23.8 and 3.24.4 ship the fixed package with backports to 3.16, and the vendor mitigation is disabling password authentication.
- Who's at risk: Alpine Linux servers and other musl-based systems (OpenWrt with OpenSSH installed, Buildroot, Yocto) running sshd without PAM with password logins enabled and at least one account holding a $5$ or $6$ hash.
An attacker who can reach an exposed Alpine Linux server over SSH and knows one account name can log in without credentials. The trick is a password between 257 and 1,024 bytes long. According to Alpine's advisory, the attack succeeds on every try with a single connection. OpenSSH rates the flaw critical and released version 10.6p2 on November 5, 2026. Alpine published fixed packages for every release back to 3.16, including branches already past end of support. No attacks using the flaw have been reported.
The targets are accounts that have no password at all: SSH key-only users, users pulled from a directory service, the root account in the Alpine base image, and the alpine user in official cloud images. These are the accounts administrators usually think of as safe from password attacks, and that is exactly where this bug hits.
Who Is Exposed
Alpine's advisory says a server is exposed only when all four of these conditions are true:
- It runs the openssh-server package, which is built without PAM, or runs openssh-server-pam with UsePAM set to no.
- PasswordAuthentication is set to yes, which is the OpenSSH default.
- An account has * as its password field, meaning no password is set.
- At least one other local account has a password hash starting with $5$ or $6$.
One account with a real password is enough to expose every passwordless account on the machine. On Alpine, passwordless accounts include key-only users created with adduser without a password or with usermod -p '*', users from a directory service through musl-nscd (they have no shadow entry), root, which has shipped as root:* in the base image since about Alpine 3.16, and the alpine user in official cloud images built with tiny-cloud.
Systems that are not affected: non-Linux systems, glibc-based Linux, any system checking passwords through PAM, containers that do not run sshd, systems with PasswordAuthentication set to no, and cloud images configured through cloud-init, which writes that setting. Accounts locked with ! in /etc/shadow are also safe, as are machines where no account holds a $-style hash.
Root itself is shielded by the default PermitRootLogin prohibit-password setting. That protection does not matter when an exposed account can become root. Tiny-cloud images from 3.18.11 through 3.24.3 give the alpine user passwordless doas. They are safe at first boot, but once any $6$ hash exists on the machine, for example after an admin sets a console password, an attacker can log in as alpine and use doas to become root.
Beyond Alpine
The bug lives in the interaction between sshd and musl, not in Alpine specifically. Özgün Kültekin of Wakefield, who reported the flaw, names OpenWrt, Buildroot and Yocto as other musl-based systems to check. OpenWrt uses Dropbear for SSH by default, and Kültekin says Dropbear is not affected, so OpenWrt devices are exposed only where an admin has installed the OpenSSH server. Embedded and appliance builds on Buildroot or Yocto that pair musl with OpenSSH and password logins deserve attention, since those images often go years without an update.
Why Long Passwords Work
Without PAM, sshd checks passwords itself. It hashes the attempt with crypt(), the C library function that turns a password into its stored form, and compares the result with the stored field. A passwordless account holds only * in that field, which is too short to contain a salt. So sshd borrows the salt from another account that has a real hash.
For $5$ and $6$ hash types, musl's crypt() refuses passwords longer than 256 bytes and returns * to signal the error. That * matches the stored *, and sshd accepts the login. The upper limit of 1,024 bytes is sshd's own cap on password length.
Three separate, reasonable decisions combined to create the hole:
- August 9, 2012: musl changed a failed crypt() call to return an unmatchable hash rather than NULL, because many programs did not check for failure.
- August 29, 2012: musl added the 256-byte limit to protect servers from denial-of-service attacks.
- July 15, 2016: OpenSSH added salt borrowing to address CVE-2016-6210, a flaw that let attackers learn which usernames exist.
Each change made sense alone. Together, the error value musl chose as unmatchable turned out to match the exact marker Alpine uses for accounts with no password.
Vendor Fix and Mitigation
OpenSSH 10.6p2 contains the fix, per its release notes. Alpine point releases 3.21.10, 3.22.8, 3.23.8 and 3.24.4 already include the fixed package, and branches 3.16 to 3.21 received fixed packages despite being past end of support. Alpine notes that upgrading the package does not restart the running sshd, so a patched package on disk does not protect a server until the daemon restarts. Cloud instances launched from tiny-cloud images older than those point releases still carry the vulnerable build until updated.
Where updating is not yet possible, the vendor mitigation is to turn off password authentication. Damien Miller of the OpenSSH project told operators of affected systems to "set PasswordAuthentication=no or disable SSH for these systems IMMEDIATELY." Alpine's advisory warns that the setting must change everywhere it appears, including inside Match blocks, and that key-based login should be confirmed working before password logins are removed, to avoid locking out administrators.
Alpine's advisory points to sshd entries in /var/log/messages reading Accepted password for an account that has no password, such as alpine, root or a key-only user. On exposed machines it also calls for review of doas use, recently created users, changed files and authorized keys. Its guidance: "If you cannot rule out a login, treat the machine as compromised."
RedEye Assessment
This is a low-complexity, high-reliability bug: one connection, one username, a long string, and no failed attempts to trip lockouts. The prerequisites look narrow on paper, but they line up on default Alpine installs where an admin has set even one console password. The biggest risk sits in places teams do not inventory well: Alpine-based VMs launched from older tiny-cloud images, appliances and embedded devices built on Buildroot or Yocto, and OpenWrt gear where someone swapped in OpenSSH. A patched package does not close the hole until sshd restarts, so package scans alone can report a fixed system that is still exposed. Any exposed host that was reachable from untrusted networks before the fix should be treated as a possible compromise until its logs show otherwise. RedEye can help identify affected musl-based assets across your environment and assess whether exposed hosts show signs of unauthorized access.
Questions about your exposure?
RedEye Security provides assessments for organizations that need to understand their real risk.
Talk to us