OpenSSH released version 10.6p2 on November 5 to fix a flaw that could let attackers into passwordless accounts on some Alpine Linux servers. The risk is not present on every Alpine machine: it depends on several settings being in place, but an attacker who meets them can reportedly succeed in a single connection.

The vulnerability could expose accounts intended for SSH key access, as well as other accounts without a password. Alpine has released patched packages for its supported releases and older branches back to version 3.16.

Which servers are at risk

An affected server must run OpenSSH with the musl C library and without PAM, a framework that can handle password checks. It must also allow password-based SSH logins, have a target account marked with an asterisk in its password field, and have another local account with a password hash beginning with $5$ or $6$.

Alpine’s standard openssh-server package is built without PAM, and password logins are enabled by default. That makes the required combination possible, but the distribution alone does not determine whether a particular server is exposed. The attacker also needs network access to the SSH service, the name of a passwordless account and a password between 257 and 1,024 bytes long.

Alpine’s advisory says a qualifying account with a password hash can expose every passwordless account on the machine. Check Point researchers said their tests also required the account with the hash to be active. Systems using glibc or PAM are not affected, nor are systems without a running SSH server or with password authentication turned off.

Why a long password works

Without PAM, OpenSSH checks a submitted password itself. For an account marked with an asterisk rather than a usable password hash, the server borrows the salt—the value used in calculating a password hash—from another account.

On musl, the password-hashing function can reject inputs longer than 256 bytes and return an asterisk to signal an error. That is the same marker stored for the passwordless account. OpenSSH can then mistake the matching markers for a successful password check.

Wakefield researcher Özgün Kültekin traced the interaction to an OpenSSH change made in 2016 to reduce the risk of attackers discovering valid usernames through timing differences. He also named OpenWrt, Buildroot and Yocto as other musl-based systems to check. OpenWrt uses Dropbear by default, which Kültekin said is not affected; the issue there matters only if an administrator has installed OpenSSH.

How administrators can close the gap

Alpine’s instructions are to update packages with apk upgrade -U -a and then restart SSH with rc-service sshd restart. Updating the package alone does not restart the running server. Alpine point releases 3.21.10, 3.22.8, 3.23.8 and 3.24.4 include the fix, and patched packages are available for older branches as well.

If an update cannot be installed immediately, administrators can set PasswordAuthentication no and restart the server. Alpine advises first checking that key-based login works and keeping the current session open until a new login succeeds.

No attacks using the flaw had been reported as of November 5. The immediate change for administrators is therefore to check whether their server meets all the conditions, then patch and restart it—or disable password-based SSH access in the meantime.