On November 5, the OpenSSH project released version 10.6p2 to fix CVE-2026-123158, nicknamed "sshole". The flaw allows SSH logins without knowing the password on Linux systems built with the musl library and without PAM, which is exactly Alpine Linux's default setup. It has a CVSS 3.1 score of 8.1 (high) and public proofs of concept already exist.
It's worth being clear about the scope from the start: it does not affect Debian, Ubuntu, Fedora or other glibc-based distributions, nor systems that check passwords through PAM, nor Dropbear or OpenBSD. But Alpine underpins a huge number of Docker images, routers and embedded devices, so the number of exposed machines is far from small.
What happened
- November 5: Damien Miller announced OpenSSH 10.6p2 on the oss-security list with a "critical security workaround" for Linux systems using musl with PAM disabled. The flaw was found by Özgün Kültekin of Wakefield.
- November 5: Alpine shipped fixed packages for all its supported branches, from 3.16 to edge, and the technical details went public.
- November 6: Hong Kong's GovCERT issued a high-threat alert noting that proof-of-concept code is already circulating.
How it works
On Linux, accounts that should never accept a password (for example, a user who only logs in with an SSH key) usually have a * in the password field of /etc/shadow. When musl's crypt() function receives a password longer than 256 bytes, it rejects it by returning, of all things, *. OpenSSH's non-PAM code path compared that result with what is stored in /etc/shadow… and since both are *, it accepted the password.
The result: any password longer than 256 characters opens the door to "passwordless" accounts. The OpenSSH team considers the root cause to lie outside sshd, but since it is exploitable through sshd, it fixed it there: version 10.6p2 rejects stored hashes that are too short to be valid.
Who is affected
According to analyses by OX Security, SAFE Security and Help Net Security, a machine is vulnerable only if all of these conditions hold:
- OpenSSH older than 10.6p2 built against musl (Alpine, OpenWrt, Buildroot, Yocto and many Docker images).
- No PAM (Alpine's
openssh-serverpackage doesn't use it by default) and password logins enabled, which is OpenSSH's default. - An account with
*as its password plus another local account with a real password.
The accounts at risk are those that should "never" accept a password: key-only deployment users, LDAP users, or root itself, which has had * on Alpine since 3.16 (although the default PermitRootLogin setting blocks root logins unless it has been changed). The most sensitive case is Alpine's official AWS and Azure images, whose alpine user can run doas without a password: on a vulnerable system, that amounts to administrator access. Accounts locked with ! instead of * are not affected.
Is it being exploited?
Sources disagree here, so it pays to be careful with headlines. Previdian says it detected attempts less than nine hours after disclosure and that an attacker obtained root on one of its Alpine honeypots. SAFE Security, on the other hand, stated on November 6 that real-world exploitation had not been confirmed, and CISA has not yet added it to its Known Exploited Vulnerabilities catalog. What several sources do confirm is that proofs of concept are on GitHub; Previdian warns they are unverified and could contain malicious code, so don't run them.
What to do now
- Update: on Alpine, run
apk upgrade -U -aand thenrc-service sshd restart. Installing the package does not restart the running sshd; without the restart you are still vulnerable. - Check the package version: fixed from
10.6_p2-r0(edge),10.3_p1-r2(3.24),10.2_p1-r1(3.23),10.0_p1-r11(3.22),9.9_p2-r1(3.21),9.7_p1-r6(3.20) and9.6_p1-r3(3.19). - If you can't update yet: disable password logins. It's the measure recommended both by the oss-security advisory and by Damien Miller himself:
echo "PasswordAuthentication no" > /etc/ssh/sshd_config.d/00-no-passwords.conf, check the configuration withsshd -tand restart sshd. - Rebuild Docker images: a container based on an old Alpine image with SSH won't fix itself. Rebuild it on the updated image.
- Review the logs: look for
Accepted password forlines in/var/log/messagesfor accounts that shouldn't have a password. Treat any match as a compromise. - Don't expose SSH to the Internet unless you need to: keep it behind a VPN or firewalled to management networks.
What to watch next
- Whether CISA adds it to its KEV catalog, which would confirm real-world exploitation.
- Updates to Docker images, router firmware and musl-based embedded devices, which tend to lag behind distributions.
- The final NVD entry, which is still awaiting analysis.
This is not the only recent scare for web servers: read about PHP2Shell, the two critical flaws in PHP's core.
Conclusion: sshole is not a universal SSH flaw, but on Alpine it's one that can't wait: a long password is all it takes to get into accounts that were supposed to be closed. Updating, restarting sshd and, better still, allowing key-only logins closes the hole.
Sources and documentation
- OpenSSH — Release notes for 10.6p2
- oss-security — Announce: Portable OpenSSH 10.6p2 released (Damien Miller)
- oss-security — "sshole": password authentication bypass: OpenSSH + musl libc
- Alpine Linux Security Tracker — CVE-2026-123158
- GovCERT.HK — High Threat Security Alert (A26-11-09): Vulnerability in OpenSSH
- OX Security — OpenSSH Password Authentication Bypass on Alpine Linux (*sshole)
- SAFE Security — SSHole: High-Severity OpenSSH Vulnerability
- Help Net Security — OpenSSH flaw exploited in the wild just hours after disclosure