OpenSSH 'sshole' Bypass Was Exploited Within Nine Hours of Disclosure

An attacker with no credentials can log in to OpenSSH on musl-based Linux such as Alpine by sending an oversized password, provided PAM is off and the target account has no usable password hash. Previdian, a threat-intelligence firm, saw attempts less than nine hours after the CVE was published, according to The Hacker News.

The fix is OpenSSH 10.6p2, released Nov. 5. After updating, restart sshd: Help Net Security reported that the running daemon keeps serving connections on the old binary until it is restarted.

What the 10.6p2 release notes say

The OpenSSH release notes describe the change as "avoid password authentication bypass that is exploitable through sshd(8)" and say it affects "some Linux systems when built and run with PAM support disabled." They add a line that matters for who owns the problem: "We consider the root cause of this bug to be outside sshd, but it is exploitable via sshd and can be avoided there." The notes credit Özgün Kültekin of Wakefield with the report.

The CVE is CVE-2026-123158, a tracking number for one specific flaw. The Hacker News gives it a CVSS score of 8.1, on the 10-point severity scale.

How a failed hash becomes a login

According to the account Help Net Security relays from Kültekin, the chain has two old parts. Since 2012, musl's crypt() function has rejected SHA-256 and SHA-512 passwords longer than 256 bytes and returns the string *. In 2016, the fix for CVE-2016-6210, a username-enumeration bug, made sshd borrow another account's salt when the target has no usable hash.

The two meet when the target account's password field is also *, the marker for "no password set". The failed hash and the stored value match, and sshd accepts the login. The Hacker News puts the working password length at 257 to 1,024 bytes.

Kültekin ran about 17,600 unusual login attempts against sshd builds, Help Net Security said. Only the musl build without PAM accepted logins it should have refused.

Which systems are exposed

System	Affected	Condition
Alpine Linux, default sshd	Yes	musl C library, PAM off
Debian, Ubuntu, Fedora	No	glibc systems
Any setup checking passwords through PAM	No	PAM in use
Dropbear, OpenBSD	No	Listed as unaffected

The attacker also needs an account whose hash field is *, such as root, a key-only deploy user, an LDAP user or the default Alpine cloud user, plus a second local account that does have a hash. Root is shielded by OpenSSH's default PermitRootLogin setting unless an administrator changed it. Help Net Security said the larger worry is the default Alpine user on images where it can run doas without a password.

The score overstates exposure across Linux as a whole, because glibc distributions are untouched. It understates it for Alpine container and cloud images, where the vulnerable combination is the default.

Timeline

• 2012: musl's crypt() starts returning * for passwords over 256 bytes, per Kültekin.
• 2016: the CVE-2016-6210 fix introduces the salt-borrowing behaviour.
• Nov. 5: OpenSSH 10.6p2 ships. Alpine releases patched packages for branches 3.16 through edge the same day, according to Help Net Security.
• Nov. 6: Help Net Security and The Hacker News publish. Previdian's first observed attempt came less than nine hours after CVE publication, and it confirmed root access on an Alpine honeypot from one Japan-based address that ran id, uname and hostname.
• Nov. 8: The Hacker News updated its count to 20 attempts from 13 addresses across nine countries.
• Nov. 9: a CISA alert relayed by DEFCON Level lists the OpenSSH flaw among four additions to the Known Exploited Vulnerabilities catalog.

The Terminal's earlier coverage of the same Nov. 9 alert, FreeSWITCH and IBM Aspera Faspex, dealt with two of those four entries, and the Ivanti Connect Secure chain is another recent addition to the same catalog. DEFCON Level's page gives no remediation deadline for the OpenSSH entry.

What to do now

Update to OpenSSH 10.6p2 or the distribution's patched package, then restart sshd. Anyone who cannot update can set PasswordAuthentication no, which OpenSSH developer Damien Miller urged, according to Help Net Security.

Search /var/log/messages for "Accepted password for" lines naming accounts that should never take a password, and review doas use, new users and authorized_keys files. If a login cannot be ruled out, The Hacker News's mitigation list says to treat the machine as compromised. Proof-of-concept exploits are on GitHub, and Previdian said they are unverified and may contain malware.

Neither Help Net Security nor The Hacker News says how many internet-facing hosts run the affected combination.