Typing a password longer than 256 characters is enough to log in to some Linux servers that run OpenSSH on the musl C library. The attacker needs no guessing: they name an account that has no password, paste the long string, and the server accepts it.
Administrators of Alpine Linux machines with SSH reachable should update openssh and restart the daemon today. Turning off password authentication in the sshd settings is a workable stopgap.
Alpine’s advisory, dated 5 November, lists the conditions. The server must be built without PAM (or run the PAM package with UsePAM off), keep password login on, which is OpenSSH’s default, and hold an account whose password field is an asterisk. That covers root on the base image, key-only deploy users, directory-service users and the default user on the project’s cloud images. It also needs one other account with a real $5$ or $6$ hash, and a single such account exposes all the passwordless ones.
The reason is a collision of two conventions. For keys over 256 bytes, musl’s crypt() returns an asterisk to say it failed, and an asterisk is also what an account with no password stores. Compare the two and they match. Alpine says no CVE number existed at the time of writing and credits the discovery to Özgün Kültekin of Wakefield.
Every release Alpine checked is affected, 3.16 through 3.24 and edge. The patched packages are 3.21.10, 3.22.8, 3.23.8 and 3.24.4, and the project also built fixes for the older branches it no longer updates routinely. The upstream correction is OpenSSH 10.6p2. musl’s maintainer, Rich Felker, posted a separate notice saying versions before 10.6p2 on musl are affected when UsePAM is no and PasswordAuthentication is yes.
Not exposed: containers that never start sshd, the PAM build with UsePAM on, locked accounts marked with an exclamation mark in /etc/shadow, and cloud-init images, which turn password login off. Alpine’s tiny-cloud images are the odd case. Releases 3.18.11 to 3.24.3 include a user named alpine with no password and doas access without one. That is harmless on first boot, but the machine becomes exploitable the moment anyone sets a console password.
Updating the package is only half the job, because the running sshd keeps the old code until it restarts, which on Alpine means rc-service sshd restart. Test a new login before closing your current session. Afterwards, check /var/log/messages for password logins by accounts that have none; Alpine says a machine where that cannot be ruled out should be treated as compromised.
The write-up on sshhole.com, which documents the bug, says the same combination has been present since 2016 and reaches other musl-based systems as well, among them OpenWrt, Buildroot, Yocto and many Docker images. Most distributions go through PAM, which never calls crypt() for an asterisk. The 256-byte ceiling itself dates from 2012, when musl added it so very long inputs could not keep a server busy.
