OpenSSH Password Bypass on musl (CVE-2026-123158)

Summary

CVE-2026-123158 lets a remote attacker log in over SSH as an account whose /etc/shadow password field is exactly *, using any password longer than musl's 256-byte limit. It needs four things together: musl libc, sshd without PAM, password authentication on, and the right mix of local accounts. OpenSSH 10.6p2 fixes it

What happened

With PAM off, sshd checks a password by calling crypt() with the stored hash as the salt, then comparing the result to the stored hash. For an account with no usable hash, sshd borrows the salt of another account so that timing does not reveal which usernames exist.

musl's crypt() returns the string * when the password is too long. An account locked with * in /etc/shadow stores the same string. The comparison matches, and sshd accepts the login. The OpenSSH fix rejects any stored password field shorter than four characters before comparing, which closes the path whatever the C library returns.

Am I affected?

A system is exposed only when all of these hold:

1. sshd runs on musl libc. Alpine Linux is the common example.
2. sshd is built without PAM, or runs with UsePAM no.
3. PasswordAuthentication yes is in effect.
4. One account has exactly * as its shadow password field, and another has a $5$ or $6$ hash.

CleanStart packages and images

CleanStart is built on glibc. The bypass exists only in musl's crypt(), and musl is absent from every CleanStart package and image.

Resolution

No action is needed for CleanStart packages or images.

For a musl-based system that meets the conditions, upgrade to OpenSSH 10.6p2, or to the fixed package for the distribution branch (Alpine has backported the fix to its supported branches), and restart sshd. A running daemon keeps the old binary until it restarts.

CVE IDs, CWE and references