OpenSSH flaw lets any long password into key-only Alpine accounts

OpenSSH servers running on the musl C library without PAM, which is how Alpine Linux ships them, let anyone log in to accounts that have no password by sending a password between 257 and 1,024 bytes long. Alpine published an advisory on Thursday telling everyone who runs sshd to update and restart it, and the OpenSSH project released version 10.6p2 with a fix the same day. No CVE had been assigned.

The accounts at risk are the ones meant to be safest: key-only users whose password field is *, users from a directory service and, where root logins are allowed, Alpine's root account. The attack takes one connection and works every time, Alpine says. Researcher Özgün Kültekin of Wakefield, who reported the flaw, says it has been present since 2016 on musl systems such as Alpine, OpenWrt, Buildroot and Yocto builds.

Who is exposed

All of these must hold, according to Alpine: sshd runs without PAM (Alpine's default openssh-server package, or UsePAM no); PasswordAuthentication is on, which is OpenSSH's default; an account has * as its password field; and at least one other local account has a $5$ or $6$ password hash. One user with a real password makes every passwordless account reachable.

Root on Alpine has shipped as root:* since about version 3.16, but OpenSSH's default PermitRootLogin prohibit-password still blocks it. The bigger risk is Alpine's official tiny-cloud images for AWS and Azure, versions 3.18.11 to 3.24.3. Their default alpine user has a * password field and passwordless doas, so once any password hash exists on the machine, for example after an admin sets a console password, an attacker gets a shell and then root. Alpine says Docker containers that do not run sshd, systems using PAM, and cloud images configured by cloud-init, which turns password logins off, are not affected; glibc systems and the Dropbear SSH server are not either, Kültekin says.

How it happened

Three changes made years apart combine, Kültekin explains. In 2012 musl made crypt() return the string * on failure instead of NULL, and it rejects keys over 256 bytes. In 2016 OpenSSH began borrowing another account's salt to hash attempts for accounts with no usable hash, to stop attackers timing logins to find valid usernames. And * is exactly what a passwordless account stores. Hashing an overlong password fails, returns *, and matches. Kültekin says he found it by building sshd in every combination of C library and PAM and sending about 17,600 unusual logins with help from AI agents; only musl without PAM disagreed.

OpenSSH calls the root cause outside sshd but fixed it there. In the same release notes the project says bugs found by AI tools are being rediscovered independently by other researchers, which suggests attackers can find them too, so it will make more frequent releases instead of batching fixes.

What to do

Install the fixed openssh package, included in Alpine 3.21.10, 3.22.8, 3.23.8 and 3.24.4 and back-ported to releases down to 3.16, then restart sshd: upgrading does not replace the running daemon. Otherwise set PasswordAuthentication no and restart. To check for past use, Alpine advises searching /var/log/messages for Accepted password for lines naming an account with no password, and reviewing doas use, new users and authorised keys. If a login cannot be ruled out, it says to treat the machine as compromised.