A high-severity authentication bypass in OpenSSH is already being exploited in the wild, letting attackers log into accounts that were never supposed to accept a password. If you run Alpine Linux or any musl-based system with SSH exposed, patch now.
What Happened
On November 5, 2026, the OpenSSH project released version 10.6p2 to fix CVE-2026-123158, a vulnerability quickly dubbed “SSHole” by its discoverer, security researcher Özgün Kültekin of Wakefield. The flaw carries a CVSS score of 8.1 (High) and allows a remote, unauthenticated attacker to log into Linux accounts whose passwords have been intentionally disabled — accounts that are only supposed to be accessible via SSH keys or not at all.
Within nine hours of the CVE going public, threat intelligence firm Previdian confirmed the first in-the-wild exploitation attempt. The speed of weaponization makes this one of the fastest vulnerability-to-exploit turnarounds of the year, and it underscores a growing pattern: attackers are monitoring disclosure channels in near real-time.
How the Bug Works
The root cause traces back to a 2016 patch meant to fix a different vulnerability. CVE-2016-6210 was a username-enumeration timing issue — attackers could figure out which usernames existed on a system by measuring how long sshd took to process a login attempt. The fix introduced a clever workaround: when sshd encounters an account with no usable password hash (marked with an asterisk “*” in /etc/shadow), it borrows a salt from another local account and hashes the supplied password anyway, keeping the timing consistent.
That fix worked fine on glibc-based systems. But on systems built with the musl C library — most notably Alpine Linux — there is a critical difference. Since 2012, musl’s crypt() implementation has refused to process SHA-256 and SHA-512 passwords longer than 256 bytes. When it encounters one, it does not return an error in the way sshd expects. Instead, it returns the string “*“.
Here is the fatal chain: an attacker sends a password between 257 and 1,024 bytes long. musl’s crypt() fails and returns “*“. sshd then compares that result against the stored password field for the target account — which, for a disabled-password account, is also “*“. The comparison matches. The door opens.
No stolen credentials are needed. No SSH keys. Just an oversized password string and an account that was supposed to be locked down.
Who Is Affected
The vulnerability requires a specific combination of conditions, all of which must be true simultaneously:
The system must be running OpenSSH compiled against the musl C library (not glibc). PAM (Pluggable Authentication Modules) must be disabled, which is the default for Alpine’s openssh-server package. Password authentication must be enabled in sshd (also the default). At least one account on the system must have its password field set to “*” — a key-only user, an LDAP-managed user, or the default alpine user on cloud images. And at least one other local account must have a real password hash, so sshd has a salt to borrow.
Alpine Linux is the primary target, but it is far from the only one. Any musl-based distribution is potentially vulnerable, including OpenWrt, Buildroot, and Yocto-based embedded systems. The biggest concern may be containers: Alpine is one of the most popular base images on Docker Hub, and many containerized SSH deployments inherit Alpine’s default configuration. SOCRadar identified Alpine cloud images from versions 3.18.11 through 3.24.3 as affected, noting that the default alpine user on AWS and Azure images has passwordless doas — meaning a successful login gives the attacker a straight path to root.
Systems that are not affected include glibc-based distributions (Debian, Ubuntu, Fedora, RHEL, and derivatives), systems using PAM-based authentication, Dropbear SSH, and OpenBSD.
Active Exploitation
Previdian’s threat sensors detected eight exploitation attempts originating from a single IP address geolocated to Japan (89.116.89[.]18). The attacker confirmed root access on a honeypot running a real Alpine Linux instance with default OpenSSH configuration. The attack pattern involved sending oversized passwords and then running reconnaissance commands — id, uname, and hostname — over non-interactive SSH sessions, a classic pattern for automated scanning and initial access operations.
Ryan Dewhurst of Previdian described the bug as “particularly trivial to exploit.” Meanwhile, proof-of-concept exploit code has appeared on GitHub, though Previdian warns that some published PoCs are unverified and may contain malware — a recurring problem with any high-profile vulnerability disclosure.
As of November 6, CISA has not added CVE-2026-123158 to its Known Exploited Vulnerabilities (KEV) catalog, though given the confirmed exploitation, that addition may be imminent.
The Fix
Alpine Linux shipped patched packages for every supported branch from 3.16 through edge on the same day as the upstream release. The fix is available in OpenSSH 10.6p2 at the upstream level. One critical detail: installing the update does not automatically restart sshd. The old, vulnerable binary will keep accepting connections until the service is explicitly restarted. OpenSSH maintainer Damien Miller urged administrators who cannot patch immediately to set PasswordAuthentication no in sshd_config and restart the service as an interim mitigation, after confirming that key-based logins are working.
For Alpine systems, the remediation steps are straightforward. First, check if your system is exposed by running sshd -T | grep -i -E 'passwordauthentication|usepam' as root — if password authentication is off or PAM is on, you are not vulnerable. If you are exposed, run apk upgrade -U -a followed by rc-service sshd restart. For containerized environments, rebuild and redeploy images with updated packages. For Alpine versions before 3.16, no official patch is available — disabling password authentication is the only fix.
How to Check for Compromise
Administrators should search /var/log/messages for any sshd "Accepted password for" entries associated with accounts that should never have accepted a password login — particularly root, alpine, and any key-only service accounts. If any such entries are found, review doas usage, recently created users, modified files, and changes to authorized_keys. If a suspicious login cannot be ruled out, treat the machine as compromised.
The Bigger Picture
There is an irony worth noting: the SSHole vulnerability exists because of a fix for a previous vulnerability. The 2016 timing-attack patch was well-intentioned and worked correctly on mainstream Linux distributions for a decade. But the interaction between that patch and musl’s strict input-length handling created a new failure mode that sat undetected for years. It is a textbook example of how security fixes in complex systems can introduce subtle, platform-specific regressions that only surface when someone looks hard enough.
Also notable is how Kültekin discovered the flaw: he reportedly used “agent swarms” — multiple AI agents working in parallel — during his testing. The OpenSSH maintainers themselves cited this dynamic in their decision to skip a long disclosure embargo, noting that AI tools have begun rediscovering reported bugs within hours of private disclosure. The era of extended embargoes may be ending, replaced by a race between patch deployment and automated exploitation.
For now, the takeaway is immediate and practical: if you run Alpine Linux or any musl-based environment with SSH exposed, patch to OpenSSH 10.6p2 and restart sshd today. If you cannot patch, disable password authentication. And check your logs — the attackers arrived within hours.
Leave a Reply