CVE-2026-123158: OpenSSH sshd Password Authentication Bypass on musl Libc Without PAM (Alpine Linux)

Background

OpenSSH’s sshd is a widely deployed SSH server. CVE-2026-123158 affects a specific build combination: Portable OpenSSH before 10.6p2 on Linux when musl libc is used and PAM is not. The CVE record names Alpine Linux as an example platform. Systems that use glibc, or that run PAM-enabled sshd with UsePAM yes, are outside the stated combination (per Alpine).

The OpenSSH 10.6p2 release notes (5 November 2026) call this “a critical security workaround” and describe the bug as a password authentication bypass. The OpenSSH team states that it considers the root cause to be outside sshd, but that it is exploitable via sshd and can be avoided there. CISA added the CVE to KEV on 9 November 2026.

Technical Mechanism

The CVE record states that sshd “lacks a workaround for a password authentication bypass (related to misinterpretation of whether a string is intended to be a password hash)”, and that for some account configurations any password between 256 and 1024 characters succeeds (Alpine’s advisory states 257 to 1024 bytes). CISA’s KEV description classes it as an unexpected status code or return value issue.

Alpine Linux’s advisory gives the practical conditions. An attacker needs the name of an account whose password field is * (a normal state for key-only accounts) and the machine needs at least one other account with a $5$ or $6$ password hash. The attacker then sends a 257 to 1024 byte password; per Alpine, it takes one connection, works every time and needs no retries. The public repro’s README instead describes two password attempts in one connection (the first primes a cached value); the sources differ and we did not run the PoC. A public reproduction (sshhole-repro) linked from the CVE record describes the mechanism as a musl crypt() behavior in which a cached value from an earlier attempt is reused; we have not independently verified that explanation.

The CVE record carries a CVSS 3.1 base score of 8.1 from the CVE program’s own container (assigner mitre), vector CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H. NVD lists the same 8.1 score sourced from [email protected].

Real-World Exploitation Evidence

• CISA added CVE-2026-123158 to KEV on 9 November 2026, due 12 November 2026.
• Public reproduction material is linked from the CVE record (predkambrij/sshhole-repro and leonjza/sshhole-lab). Our judgement: that lowers the bar for anyone who meets the account-name condition.
• As of 10 November 2026 we found no named campaign or threat actor in the KEV entry, the OpenSSH release notes or the Alpine advisory. The KEV ransomware field reads “Unknown”.

Impact Assessment

A successful bypass gives a remote attacker an interactive login as the targeted account without knowing its password. Alpine notes that root ships as root:* in base images, but the default PermitRootLogin prohibit-password protects it unless set to yes; a reachable non-root account that can escalate (for example via doas) still matters. Other * accounts include key-only users, directory-service users via musl-nscd, and the alpine user in the official tiny-cloud images.

Alpine lists as not affected: containers that do not run sshd, systems with PasswordAuthentication no, openssh-server-pam with UsePAM yes, locked accounts (!), systems with no $-style hash, and cloud-init images that write PasswordAuthentication no.

Affected Versions

Remediation Steps

1. Update OpenSSH: on Alpine run apk upgrade -U -a, or build Portable OpenSSH 10.6p2.
2. Restart sshd. Alpine stresses that upgrading the package alone does not replace the running daemon.
3. If you cannot update yet, set PasswordAuthentication no in the sshd configuration and restart sshd. Alpine says either step closes the hole.
4. Review accounts with a * password field and remove unneeded ones.

Detection Guidance

• Look in auth.log or the journal for successful Accepted password for <user> entries on accounts that have no password set (shadow field *). Any such success is anomalous.
• Correlate with multiple password attempts within a single connection.
• Use grep -E '^[^:]+:\*:' /etc/shadow to list accounts with the * field, then compare against logins.
• Where possible, check the sshd binary’s build: musl-based systems without PAM are the exposed population.

These are suggestions, not vendor-published signatures. We did not confirm whether the long password appears in logs; it should not, so rely on the accepted-login pattern.

Timeline

References

• OpenSSH release notes — 10.6p2
• Alpine Linux security advisory (5 Nov 2026)
• Upstream commit 4353fdc
• CVE record
• NVD — CVE-2026-123158
• sshhole-repro (public reproduction)