OpenSSH 10.6p2 fixes musl password-auth bypass (CVE-2026-123158)

A password-authentication bypass in OpenSSH, nicknamed SSHole, lets an unauthenticated attacker log into some accounts on affected hosts using any sufficiently long password. Per NVD, CVE-2026-123158 affects "sshd in OpenSSH before 10.6p2 on Linux, when musl libc is used without PAM" — and names Alpine Linux as the example platform. It carries a CVSS 8.1 score with high attack complexity. The fix is OpenSSH 10.6p2, in the November 5 release.

What's affected

• Linux hosts running OpenSSH before 10.6p2 on musl libc with PAM disabled. Alpine's default sshd configuration meets this.
• Not affected: glibc-based distributions, systems that authenticate through PAM, Dropbear, and non-Linux systems.

Alpine shipped fixed packages in 3.21.10, 3.22.8, 3.23.8 and 3.24.4, with backports for older branches; see Alpine's advisory. The openssh fix lands in package 10.3_p1-r2.

The flaw

For an account with no usable password, the stored hash is *. Under musl, crypt() refuses to hash a password longer than 256 characters and also returns *. OpenSSH — reusing a code path from the 2016 username-enumeration fix (CVE-2016-6210) — compares the two * values, finds them equal, and treats it as a successful login.

Three conditions must hold: password SSH login is enabled (Alpine's default), at least one account has no password (on Alpine, root ships without one), and at least one other account has a real password. A password of roughly 256 to 1024 characters triggers it. Accounts with valid password hashes are not bypassed.

Exploitation status

The Hacker News reports, citing the honeypot operator Previdian, that the first exploitation attempt landed less than nine hours after the CVE was published, gaining root on an Alpine honeypot and running id, uname and hostname. Previdian logged attempts from an IP geolocated to Japan, 89.116.89[.]18. Treat that as a single-source sighting, not a measured campaign — but the window from disclosure to probing is clearly short.

Detection

Look for password logins to accounts that should never accept one (on Alpine, root or key-only users):

grep "Accepted password for" /var/log/messages

Any hit for a no-password or key-only account is a red flag. If you can't rule out such a login on an internet-facing host, treat it as compromised.

Action checklist

1. Upgrade to OpenSSH 10.6p2 or your distribution's patched package, then restart sshd.
2. On Alpine, apk upgrade openssh to at least 10.3_p1-r2 and restart the service.
3. Patch running cloud instances built from older Alpine images — rebuilding the image alone doesn't fix what's already live.
4. If you can't patch immediately, disable password authentication (PasswordAuthentication no) — after confirming key-based login works.
5. Review authorized_keys, recently created users and doas usage on any exposed host.

Context

SSHole is the second recent reminder that OpenSSH's assumptions and an alternative libc's edge cases interact badly: the regreSSHion work already showed musl targets behaving differently from glibc. The lesson for operators who standardize on minimal Alpine images — common in container base layers — is that "small attack surface" and "default-secure" are not the same claim.