OpenSSH 10.6p2 fixes password authentication bypass on musl systems without PAM

What happened

OpenSSH 10.6p2 fixes a password authentication bypass that affects servers built with musl libc when PAM is not handling the password check. The flaw, tracked as CVE-2026-123158 and nicknamed *sshole in the disclosure, allows a remote attacker to authenticate to certain accounts without knowing a valid password. According to a dev.to write-up summarizing research by Özgün Kültekin of Wakefield, the issue is rated high severity and affects unpatched OpenSSH on musl-based systems — Alpine Linux, OpenWrt, Buildroot and Yocto deployments are named as examples — where PAM is disabled or not built in.

How the bypass works

The bug is a collision between an error value and a lock marker. For certain password-hashing algorithms, musl's crypt() function returns the literal string * when the supplied password exceeds 256 bytes. Separately, accounts whose stored password field is * are conventionally treated as locked and should never log in with a password. The vulnerable OpenSSH code compares crypt()'s output against the target account's stored field, so when musl hands back *, the comparison matches the stored * and the login succeeds.

One further ingredient is required. As part of its timing-related password-checking behavior, OpenSSH uses a salt taken from another account on the system, and the bypass only works when that borrowed salt is in the $5$ (SHA-256) or $6$ (SHA-512) format.

Input length decides the outcome, per the dev.to analysis. Passwords of 1 to 256 bytes are hashed normally and never equal *, so they fail. Passwords longer than 1024 bytes are rejected by OpenSSH before crypt() is ever called. Only the 257-to-1024-byte window produces the error string — and accounts holding a genuine password hash are unaffected, because * does not match their real hash.

Conditions for exploitation

The dev.to analysis lists six conditions, all of which must hold at once:

• The server runs unpatched OpenSSH on musl libc.
• PAM is disabled or absent, so OpenSSH performs the check itself.
• PasswordAuthentication is enabled in the effective configuration.
• The target account's password field is * and the account is permitted to log in.
• Another account on the system carries a $5$ or $6$ hash to supply the borrowed salt.
• The attacker submits a password of 257 to 1024 bytes.

Other login restrictions still apply. PermitRootLogin prohibit-password, for example, blocks direct root password logins through this route. Escalation to root is a separate stage that depends on the compromised account having passwordless doas or sudo. The write-up also cautions against describing Alpine's tiny-cloud images as uniformly exploitable on first boot — the hash condition must also be met — but once it is, a default user with passwordless doas can provide a path to root.

Patching and detection

OpenSSH 10.6p2 and vendor backports contain the fix, but installing the updated package is not sufficient on its own: the running sshd must be restarted to load the patched code.

For teams checking past exposure, the telltale log entry is an Accepted password record for an account whose stored field is * and which was never intended to accept password logins. Alpine's security advisory points to /var/log/messages as an investigation source, though retention depends on the system. The dev.to analysis adds two caveats: a successful authentication record does not by itself prove root escalation, and encrypted packet sizes cannot establish whether this bypass was used, since password-length analysis requires visibility at the authentication endpoint.

Why it matters

The * password field is a lock marker, and this bug turned the lock itself into the key: the very string meant to signal that no password can ever work became the value an attacker had to produce. musl-based systems are common precisely where headless SSH administration is the norm — containers, routers and other embedded deployments — so the population of servers fitting the vulnerable profile is meaningful even though the preconditions narrow it. Two operational lessons stand out. Switching an account to SSH keys does not make a * account safe while password authentication remains enabled server-wide. And the fix only takes effect after sshd restarts, a step that patch automation frequently skips and administrators should verify host by host.