High
OpenSSH, SSHole, CVE-2026-123158, Alpine Linux, musl, authentication bypass, sshd, Linux, containers
OpenSSH SSHole CVE-2026-123158: Alpine Root Login Bypass
OpenSSH SSHole (CVE-2026-123158) lets attackers log in to password-disabled accounts on Alpine and other musl systems. Exploited within hours. Fixed in 10.6p2.
CVE-2026-123158, nicknamed SSHole, is an OpenSSH authentication bypass that lets an unauthenticated attacker log in to password-disabled accounts by sending a very long password. It only affects Linux systems where OpenSSH is built on the musl C library without PAM, which includes Alpine Linux's default SSH server. Attackers began trying it less than nine hours after disclosure, and one honeypot was taken to root. The fix is OpenSSH 10.6p2.
The bug sits in how sshd handles a password-hashing failure. In 2016, OpenSSH added a workaround for a username enumeration flaw (CVE-2016-6210). Under specific conditions on musl, a failed hash of the submitted password now returns an asterisk, the same "*" value Linux stores for accounts whose password login is disabled. sshd then compares the two asterisks, finds a match and lets the user in. Researcher Ozgun Kultekin found the issue, and the NVD entry says any password between roughly 256 and 1,024 characters works on an affected account.
The precondition matters. The attack only works against accounts whose password field is "*", which is common on Alpine for root and for key-only users. Accounts with a real password hash cannot be bypassed this way, and glibc-based distributions such as Debian, Ubuntu and RHEL, systems that check passwords through PAM, Dropbear and non-Linux systems are not affected, according to The Hacker News. That still covers a lot of real infrastructure: Alpine is a default base image for containers and small appliances, and many of those run sshd for debugging or management.
Is SSHole (CVE-2026-123158) being exploited?
Yes, at least opportunistically. Threat intelligence firm Previdian told The Hacker News it saw the first attempt under nine hours after the CVE was published on November 5, and confirmed root access on an Alpine honeypot running OpenSSH. The attacker sent oversized passwords and then ran id, uname and hostname over non-interactive sessions, which looks like scanning for usable boxes rather than a targeted intrusion. By November 8, Previdian counted 20 attempts from 13 IP addresses in nine countries. Public lab and reproduction repositories are linked from the NVD entry, so the barrier to trying it is low.
The scores lag behind that activity. NVD rates the flaw 8.1 (High) with high attack complexity, its EPSS probability is 1.0% (63.5th percentile), and it was not in CISA's Known Exploited Vulnerabilities catalog as of November 9. A working, public, unauthenticated root login on a common base image is worth more weight than those numbers suggest.
Which systems are affected by CVE-2026-123158 and how do you fix it?
System | Affected? | Action |
|---|---|---|
Alpine Linux with default OpenSSH (musl, no PAM) | Yes | Update to the patched openssh package, restart sshd |
Other musl-based Linux builds without PAM | Yes, if an account has a "*" password | Update to OpenSSH 10.6p2 |
glibc distributions (Debian, Ubuntu, RHEL, SUSE) | No | None for this flaw |
Any system checking passwords through PAM | No | None for this flaw |
Dropbear, BSD, macOS | No | None for this flaw |
The OpenSSH 10.6p2 release notes carry the fix, released November 5. After updating, restart sshd, since the old daemon keeps running until you do. If you cannot patch right away, setting PasswordAuthentication no and KbdInteractiveAuthentication no in sshd_config blocks password logins entirely on hosts that only use keys, which is most Alpine containers.
How do you check if an Alpine server was compromised through SSHole?
Alpine advises, as quoted by The Hacker News, searching /var/log/messages for sshd lines that read "Accepted password for" on an account that has no password, such as alpine, root or any key-only user. Also review doas use, recently created users, new files and changes to authorized_keys on exposed machines. Alpine's own guidance is blunt: if you cannot rule out a login, treat the machine as compromised and rebuild it. For containers, that usually means redeploying from a fixed image rather than cleaning in place.
Our read
SSHole is a narrow bug with a wide footprint. It needs musl, no PAM and a password-disabled account, and Alpine ships exactly that combination by default. The practical question for most teams is not "do we run Alpine" but "where do we run Alpine with sshd reachable", which often includes forgotten debug containers and appliance images nobody inventories. Scores like EPSS will catch up after the fact; here the public exploit and honeypot root shell are the signal. See how to prioritize vulnerabilities beyond CVSS, what CISA KEV is and our coverage of the MikroTik SSH router hijack. To check what is actually reachable on your exposed hosts, Nexus Void runs VAPT on web apps, APIs and mobile apps.
Reporting by The Hacker News; fix per OpenSSH; CVSS per NVD, EPSS per FIRST.