CVE-2026-123158: Lab Tests Validate OpenSSH Password Bypass Conditions on musl

Summary

Step Security reproduced CVE-2026-123158 on an Alpine VM and container: vulnerable OpenSSH on musl without PAM can accept an overlong password for an eligible passwordless account after a failed attempt. Upgrade to OpenSSH 10.6p2 or patched Alpine packages.

Key points

The bypass combines musl crypt() returning "*" for passwords over 256 bytes with OpenSSH's non-PAM password path and an eligible account whose shadow field is "*".
Exposure requires unpatched OpenSSH on musl, PAM disabled, PasswordAuthentication enabled, an eligible SSH account, and a local account with a real SHA-crypt hash to supply a salt.
In tests with pre-fix OpenSSH, the bypass worked on an Alpine 3.24 VM and Docker container; a failed authentication attempt had to precede the successful long-password attempt.
The tested PAM configuration with UsePAM yes blocked the bypass. Disabling password authentication or upgrading are also stated mitigations.
OpenSSH fixed the flaw in 10.6p2; Alpine published patched packages for branches back to 3.16. Restart sshd after upgrading.
Version-banner checks can misreport patched systems because Alpine backports fixes; check package revisions or test behavior. Review logs for a failed attempt followed by an accepted password login to an eligible account.
The reviewed disclosure and advisories did not report confirmed exploitation in the wild; the article says public PoCs exist.

Article Details

Attack Vectors: An unauthenticated network attacker can exploit an unpatched sshd running on musl without PAM when PasswordAuthentication is enabled, an SSH-eligible account has `*` in its shadow password field, and another local account has a real SHA-crypt hash whose salt sshd can borrow.
The attacker submits a password longer than musl crypt()'s 256-byte input limit, within sshd's accepted length. crypt() returns `*` on failure, which matches the target account's stored field. In the tested configuration, an initial failed authentication attempt in the same connection was required before the long-password attempt succeeded.
Direct root login additionally requires PermitRootLogin yes. The article reports that OpenWrt with openssh installed, Buildroot, and Yocto using musl may also be in scope, subject to the applicable conditions.
Defensive Notes: Upgrade to OpenSSH 10.6p2 or the applicable Alpine patched package, then restart sshd. Compare installed package revisions with vendor fixed-version information; upstream version banners may not reflect distribution backports.
Review authentication logs for successful password logins to accounts whose shadow field is `*`; investigate unexpected successes, including a preceding failed attempt in the same session.
Where immediate upgrading is not possible, disable PasswordAuthentication or use the PAM flavor with UsePAM yes. Validate the replacement login method and restart sshd after configuration changes.
Audit Alpine-based runner containers and images that install and expose sshd, rebuild images or refresh cached and mirrored packages, and consider whether sshd is needed. The article states that GitHub-hosted Ubuntu runners and glibc-based self-hosted runners are not affected.
Do not rely on a scanner that sends only one long password per connection: in the tested setup, the bypass required a prior failed attempt in that connection.