OpenSSH: *sshole password authentication bypass on musl libc (CVE-2026-123158) fixed in 10.6p2, exploited in the wild
Published 06/11/2026 18:26 · Updated 11/11/2026 19:15 (revision 4)
Timeline
7 events over 20 d
- 22/10/2026 14:10ConfirmedBSI CERT-Bund (WID)+15 d
- 06/11/2026 17:37CorroboratedCommunity post+48 min
- 06/11/2026 18:26Published on WatchtowerPro CISO+20 h
- 07/11/2026 15:05UpdatedGreyNoise reports it is monitoring scanning, exploitation attempts and successful…+1 d 9 h
- 09/11/2026ExploitedCISA Known Exploited Vulnerabilities+17 h
- 09/11/2026 18:55UpdatedBleepingComputer reports hackers are actively exploiting *sshole to run commands, steal…+2 d
- 11/11/2026 19:15UpdatedCISA added CVE-2026-123158 to its known-exploited list on 09/11/2026, and…
In short
OpenSSH before 10.6p2 on Linux systems that use musl libc without PAM (for example Alpine Linux) lets an attacker log in over SSH to some accounts by sending a very long password. CISA lists the flaw as exploited, VulnCheck, GreyNoise and BleepingComputer also report attacks, and public proof-of-concept code exists. The OpenSSH project calls 10.6p2 a workaround, as it sees the root cause outside OpenSSH. Update to 10.6p2 or later. Shodan estimates 42,854 internet-facing systems tagged with CVE-2026-123158 worldwide, 11,042 of them in the EU (11/11/2026).
How bad is it
High. An attacker who can reach a vulnerable SSH server can log in to accounts that should have no password by sending a very long password, and attacks are confirmed by CISA's known-exploited list.
Being exploited - on CISA's known-exploited list since 09/11/2026.
Severity score
CVSS 3.1 from NVD, from mitre.org, read 11/11/2026.
What an attacker needs
- Internet access to itEnough
- A loginNot needed
- A user to clickNo
- Special settingsUsually yes
Red helps the attacker, blue holds them back, grey is not published yet.
If it works, an attacker can
- Read the data it holds
- Change or delete that data
- Take it offline
Type: authentication bypass.
A score is the worst case for the flaw, not a verdict on any one system. How we score · ReconX customers see which of their own systems are affected.
Affected versions
- sshd in OpenSSH before 10.6p2 on Linux, when musl libc is used without PAM. Alpine Linux is the example platform given.
- Red Hat says its products are not affected; they use glibc and PAM by default.
Fixed in
- OpenSSH 10.6p2 (released 05/11/2026) contains a workaround for the problem. Use your distribution's patched package where one is available.
What to do now
- Update OpenSSH to 10.6p2 or later, or to your distribution's patched package, as soon as possible (BSI advice).
- Restart sshd after upgrading; a running daemon stays vulnerable until restarted.
- If you cannot update yet, set PasswordAuthentication no in the sshd configuration and restart sshd. This interim measure reduces exposure and does not make the server safe.
- Restrict SSH access to trusted source addresses where you can.
- Check logs for 'Accepted password' entries for accounts that should have no password; if you cannot rule them out, treat the machine as compromised.
ReconX customers see the full notice - and their own systems
Our customers are alerted at every phase. Until a patch exists, the ReconX agent watches their servers from the inside for anomalies, and our outside view - the attacker's view - shows which systems to fix first.
In ReconX: the full analysis, 7 open questions, followed up as sources answer, all 5 sources with their dates and every revision. And technology matching: which of your systems run OpenSSH, at which version, fixed or not - and what each one needs.
Main sources
Known exploited (VulnCheck KEV): OpenBSD OpenSSH - OpenBSD openssh Unexpected Status Code or Return Value Research · Re: "sshole": password authentication bypass: OpenSSH + musl libc Research · Re: "sshole": password authentication bypass: OpenSSH + musl libc Research