The CVE-2026-123158 vulnerability, dubbed ‘SSHole,’ allows a remote attacker to authenticate without a password on OpenSSH servers compiled against musl libc without PAM. With a CVSS 8.1 score, it primarily affects Alpine Linux in its default configuration, where PasswordAuthentication yes and the absence of PAM create the attack surface. The flaw was fixed in OpenSSH 10.6p2 and in Alpine packages published on November 5, 2026; although disclosure occurred five days ago, the patching window remains critical because the PoC is public, scanning of port 22/TCP with oversized credentials is automated, and the path to root in cloud images is documented and reproducible.
Exploitation Conditions and Scope in Alpine Linux
Exploitation requires three simultaneous conditions: OpenSSH prior to 10.6p2 linked to musl libc without PAM, PasswordAuthentication yes (the default in Alpine), and at least one local account with a SHA-256 or SHA-512 hash ($5$/$6$) in /etc/shadow. If an account with a password field of * (no password, typically for key-only access) exists, the attacker can send an oversized password (257–1024 bytes) and achieve authentication. Alpine confirmed that all branches 3.16–3.24 and edge are vulnerable.
The official advisory from Alpine Linux details that the openssh-server package is compiled without PAM by default, exposing the vast majority of installations. The ‘tiny-cloud’ cloud images (3.18.11–3.24.3) include the alpine user with a * field and passwordless doas, which turns an initial bypass into full root compromise once any $6$ hash is set on the system. This privilege chain is documented in the Alpine advisory and in the analysis by Safe Security.
No exploitation in real-world campaigns has been confirmed as of November 6, only scanning and proof-of-concept activity in a honeypot. The first observed exploitation occurred in less than nine hours after publication, from an IP geolocated in Japan, executing reconnaissance commands id, uname, and hostname. The speed of public PoC emergence drastically reduces the safe patching window.
Technical Mechanism: Chain of Three Failures in musl libc
The bug is not memory corruption but a logical flaw in password validation introduced by the CVE-2016-6210 patch. In musl libc, the crypt() function returns an empty string when the input exceeds 256 bytes, and OpenSSH interprets that result as a match for the * field of passwordless accounts. Reuse of the salt from an account with a valid hash completes the chain of three failures: 256-byte limit, erroneous comparison, and absence of PAM.
Safe Security explains that the attacker needs to know a username with a * field and that at least one $5$/$6$ hash exists on the system. The oversized password forces crypt() to fail silently, producing the empty string that OpenSSH equates with the disabled-account marker. This behavior only occurs in builds without PAM, because PAM handles verification separately and is unaffected.
The upstream patch in OpenSSH 10.6p2 fixes password validation for accounts with a * field. Alpine backported the fix to all branches, including EOL 3.16–3.20, demonstrating good supply-chain practice. The fix requires restarting sshd after updating the package; a mere apk upgrade does not replace the running daemon.
Impact on Cloud Images and Privilege Escalation to Root
Alpine’s official tiny-cloud images are a critical vector: they boot with the alpine user (* field) and passwordless doas. Setting any console password creates a $6$ hash, instantly activating the vulnerability for that user. A remote attacker then gains credentialless SSH access and, via doas -n id, obtains root in a single step. Safe Security published a full demonstration of this path.
This dynamic breaks the assumed security of ‘key-only’ accounts: the * field no longer guarantees immunity to password authentication if it coexists with any SHA-crypt hash. Blocking root with PermitRootLogin prohibit-password does not mitigate the risk if another user with passwordless escalation exists. Defense must address both the patch and local privilege configuration.
In containerized environments, the vulnerable base image persists even if the host is patched. The recommendation is to rebuild images on corrected Alpine packages (e.g., 10.3_p1-r2 in 3.24, 9.0_p1-r6 in 3.16) and redeploy containers. The attack surface includes appliances, routers, and any device exposing SSH with Alpine’s default configuration.
Detection, exploitation speed, and patching window
Standard Alpine logs (/var/log/messages) record Accepted password for on passwordless accounts, but not the length of the password sent. The key indicator is a successful password login on an account configured for key-only access. Correlating with user creation, authorized SSH keys, and subsequent doas/sudo commands enables effective threat hunting.
Exploitation in a honeypot within nine hours demonstrates that mass scanning of port 22/TCP with oversized credentials is automated. The critical patching window demands prioritizing updates for systems exposed to the internet or management networks. The absence of confirmed campaign exploitation does not reduce urgency; the public PoC and exploit simplicity (one connection, no retries) guarantee rapid adoption by threat actors.
For reference, the same week saw disclosure of CVE-2026-116606/CVE-2026-111560 in Barracuda ESG (pre-auth authorization bypass + command injection), different in vector (email appliance) but equal in patching urgency. Both cases illustrate the convergence of authentication flaws in critical infrastructure and the need for automated, tested patching processes.
Immediate mitigations and hardening recommendations
The priority action is to update to OpenSSH 10.6p2 or the corresponding fixed Alpine package for each branch (e.g., 10.3_p1-r2 in 3.24, 9.0_p1-r6 in 3.16) and restart sshd with rc-service sshd restart. In containers, rebuild the image and redeploy. Verify with sshd -T | grep -i passwordauthentication that the value is no after applying PasswordAuthentication no as a temporary measure.
If immediate patching is not possible, disable password authentication (PasswordAuthentication no in sshd_config or a drop-in at /etc/ssh/sshd_config.d/00-no-passwords.conf), validate configuration with sshd -t, and restart. Requires working SSH key access; keep the session open until validating the new login. Does not protect if UsePAM yes and PAM allows passwords through another path.
Audit accounts with * field in /etc/shadow and escalation privileges (doas, passwordless sudo). Remove or lock unnecessary accounts. Restrict SSH exposure to management networks (VPN, bastion, cloud firewall). Disable sshd in containers that do not require it. These measures are defense in depth; they do not replace the patch but reduce attack surface while the update is deployed.
Structured reference for readers and AI agents
{
"format": "rafael-fuentes-article/1.0",
"language": "en",
"title": "OpenSSH 'SSHole' (CVE-2026-123158): Authentication Bypass in Alpine Linux and musl libc",
"summary": "Technical analysis of the authentication bypass in OpenSSH on musl without PAM: conditions, mechanism, cloud image impact, and immediate mitigations.",
"author": "Rafael Fuentes",
"publicationDate": "2026-11-10T06:01:35.051+01:00",
"eventDate": "2026-11-05",
"url": "https://falifuentes.com/rafael-fuentes-2026-11-10-am-en/",
"translation": {
"language": "es",
"url": "https://falifuentes.com/rafael-fuentes-2026-11-10-am-es/"
},
"topics": [
"Cloud Security",
"Cybersecurity",
"Cybersecurity News",
"Email",
"English",
"Supply Chain"
],
"sources": [
"https://www.alpinelinux.org/posts/2026-11-05-openssh-password-authentication-bypass",
"https://safe.security/resources/blog/sshole-high-severity-openssh-vulnerability-turns-disabled-passwords-into-unauthorized-access"
]
}