OpenSSH 10.6p2 Fixes a Password Bypass on musl Linux, and CISA Gave Agencies Three Days

An unauthenticated network attacker can log in to an OpenSSH server as any account whose password field is locked with *, by submitting a password longer than 256 characters (CVE-2026-123158, CVSS 8.1). The attack needs sshd built without PAM on a Linux system that uses the musl C library, with password authentication left on, which describes the default Alpine Linux server install. CISA added it to its Known Exploited Vulnerabilities catalog on November 9 with a due date of November 12 for federal agencies, a three-day window.

The fix is OpenSSH 10.6p2, released November 5, and Alpine shipped patched packages the same day. Upgrade, restart sshd, and verify by package revision rather than by the version banner.

What the attacker needs for CVE-2026-123158

The flaw is a collision of three old decisions, laid out on the researcher's write-up at sshhole.com. In 2012 musl made its crypt() function return the string * on failure instead of NULL. Later that year musl's SHA-512 crypt gained a 256-byte limit on the password, and a longer password makes it fail and return * too. A * in the shadow file is the conventional marker for an account that cannot log in with a password, so the comparison of the stored field against the * that crypt returned succeeds.

The preconditions, from StepSecurity's November 6 lab write-up:

• PasswordAuthentication yes, which is the default.
• An account allowed to log in over SSH whose shadow field is *, such as a key-only deploy user or, on Alpine, root.
• PermitRootLogin yes if the target is root.
• At least one local account with a real $5$ or $6$ hash, which supplies the salt that sshd borrows for the comparison.

Glibc systems, PAM configurations (UsePAM yes) and the default Alpine tiny-cloud first-boot state are not affected, per the same write-up.

The score overstates the reach and understates the outcome

The CVSS vector (AV:N/AC:H/PR:N/UI:N) marks attack complexity as high, which fits the preconditions. The score of 8.1 does not say who is exposed: Alpine-based container images that run sshd with passwords enabled, OpenWrt builds that use OpenSSH instead of Dropbear, and Buildroot and Yocto images built with musl. The researcher's page notes that Alpine's official AWS and Azure images ship a default alpine user with passwordless doas, which makes a login there effectively root.

There is also a disagreement on the threshold. The NVD record says any password "between 256 and 1024 characters" succeeds. StepSecurity's lab, run on Alpine's pinned 10.3_p1-r1 package, rejected a 256-byte password and accepted 257 bytes or more, and only on a second or later attempt within the same connection. Both agree on the ceiling: sshd's MAX_PASSWORD_LEN is 1024.

Timeline

Date	Event
October 30, 2026	OpenSSH commits a fix to pick_salt() (per sshhole.com)
November 5	OpenSSH 10.6p2 released; NVD record published; Alpine patches all branches
November 6	StepSecurity publishes lab results; reports no confirmed exploitation
November 9	CISA adds the CVE to the KEV catalog, due November 12

The release notes credit "Özgün Kültekin of Wakefield (wakefield.co)" and say of the cause: "We consider the root cause of this bug to be outside sshd, but it is exploitable via sshd and can be avoided there." The OpenSSH notes name no CVE; the identifier comes from the NVD record, whose source is MITRE.

Fixed packages and what to run

Alpine's fixed packages, per StepSecurity: edge 10.6_p2-r0, 3.24 10.3_p1-r2, 3.23 10.2_p1-r1, 3.22 10.0_p1-r11, 3.21 9.9_p2-r1 and 3.20 9.7_p1-r6, with patched builds also published for 3.16 to 3.19. Because Alpine backports, the banner can still read an old version on a patched host; check with apk info -v openssh-server.

The Debian security tracker lists bookworm and trixie as vulnerable and forky and sid as fixed in 1:10.6p2-1. Its description limits the flaw to musl without PAM, so read the preconditions, not the status column.

Hosts that cannot upgrade today can set PasswordAuthentication no or use a PAM build with UsePAM yes; StepSecurity verified both. Review logs for Accepted password against key-only accounts, and rebuild container images created before November 5.

Is it being exploited?

StepSecurity found no confirmed exploitation as of November 6 but expected scanning because proof-of-concept code is public. CISA's KEV entry, flagged for forensic triage, came three days later and gives no source for its evidence. Treat the KEV listing as the only authoritative statement of exploitation so far. Who is exploiting it, and against what, is still open. Earlier this month CISA's KEV listing for an Apple flaw also arrived with the evidence cited by a third party, not by CISA. For automated bug-hunting context, see our report on OpenAI's GPT-6 Cyber.