OpenSSH ‘SSHole’ CVE-2026-123158: Unauthenticated Root on Alpine Linux, Exploited Within Hours

A race condition buried in a 2016 OpenSSH security patch now lets any unauthenticated attacker log into locked accounts on Alpine Linux — the base image for the majority of Docker containers in production. Exploitation started within nine hours of disclosure. The fix is a package upgrade plus a daemon restart, but most teams will discover that upgrading alone is not enough.

DataWater Threat Intelligence Desk | Published November 8, 2026 | 8-minute read

Executive Summary

The fix for a 2016 username-enumeration patch introduced a silent bypass for all accounts with no usable password.

When OpenSSH’s developers patched a timing side-channel in 2016 (CVE-2016-6210), they made the daemon hash a submitted password against a borrowed salt even when the target account had no real password hash. The goal was to prevent attackers from learning which usernames were valid by measuring response time. The fix worked as intended on glibc-based systems. On musl-based systems, it did not.

musl’s implementation of crypt() rejects passwords longer than 256 bytes and returns "*" on failure. When the submitted password is at least 257 bytes and the target account stores * as its shadow entry — the standard placeholder for accounts with no usable password — the returned value matches, and OpenSSH accepts the login.

Researcher Özgün Kültekin, who discovered the flaw and named it SSHole, confirmed the bypass in approximately 17,600 login attempts across different OpenSSH builds before disclosure. Only musl builds without PAM were vulnerable. Alpine Linux ships that configuration as its default.

The practical result: on any internet-facing Alpine Linux host with password authentication enabled — the OpenSSH default — and at least one locked account alongside one normal user, an unauthenticated attacker can log into the locked account. On official Alpine cloud images, that locked account is alpine, and alpine can reach root through passwordless doas.

OpenSSH 10.6p2 was published November 5. Alpine released patched packages the same day for every supported branch back to 3.16. Exploitation began within hours.

Why This Matters to CISOs and Security Leaders

Alpine Linux is not a niche distribution. It is the default base image for Docker containers — the smallest, most commonly used starting point for containerized services, CI/CD pipelines, internal tooling, and cloud functions. Organizations that run containers at scale almost certainly run Alpine. Many expose SSH for administrative access or debugging. Those are the systems most at risk today.

The attack does not require finding a zero-day, buying exploit code, or running a complex toolchain. Any SSH client and a 257-byte string is enough. The barrier for exploitation is as low as it gets for a network-accessible service.

Upgrading the package without restarting sshd leaves the system fully exposed. This is the detail most remediation checklists will miss. A team that updates the package, confirms the new version is installed, and marks the ticket closed has not fixed anything until sshd is restarted. In container environments, that may mean redeploying the image, not just running apk upgrade.

Cloud images are specifically at risk. Official Alpine cloud images for AWS and Azure running versions 3.18.11 through 3.24.3 carry the vulnerable configuration out of the box. Once any administrator account on those images gets a password — a common onboarding step — the bypass becomes exploitable and the default alpine user’s passwordless doas provides a path to root.

The Timeline

The same patch that fixed a username-enumeration timing leak a decade ago is the reason any attacker with a 257-byte password can log into your Alpine Linux servers today.

Vulnerability & Exploit Analysis

Root cause

CVE-2026-123158 (CWE-287: Improper Authentication) traces directly to the 2016 remediation for CVE-2016-6210, a timing side-channel that allowed username enumeration. The 2016 fix made OpenSSH hash the submitted password against a borrowed salt even when the target account had no usable password, equalizing the response time regardless of whether the account existed. The fix worked as intended on glibc, whose crypt() implementation handles overlong passwords. It did not account for musl’s behavior: musl’s crypt() rejects passwords longer than 256 bytes and returns the string "*" on failure. Since * is exactly the placeholder value that locked accounts store in /etc/shadow, the comparison succeeds and OpenSSH accepts the login.

Attack prerequisites

All four of the following must be true for a system to be exploitable:

1. The host runs openssh-server (not openssh-server-pam, or openssh-server-pam with UsePAM no)
2. PasswordAuthentication is set to yes (the OpenSSH default)
3. At least one account has * as its shadow entry — such as key-only users, directory users via musl-nscd, or the default alpine user on cloud images
4. At least one local account has a valid password hash ($5$ or $6$), which OpenSSH uses to borrow the salt

Affected and fixed versions

Attack Chain Analysis

Threat Intelligence Breakdown

Attribution: No threat actor has been named. The only observed source is IP 89.116.89[.]18, geolocated to Japan by Previdian. The initial activity involved reconnaissance commands (id, uname, hostname), which is consistent with automated scanning for vulnerable hosts rather than a targeted campaign. No ransomware or espionage tooling has been associated with the activity observed so far.

Proof-of-concept code: GitHub repositories claimed to contain working exploits appeared shortly after disclosure. Previdian explicitly warned that at least some of these may be malicious and advises against running unverified PoC code.

Indicators of compromise (source: Previdian, Detectify, Kültekin research; defanged):

What is still unknown: No confirmed victim count has been published. No attribution to a named threat actor or group. No ransomware or espionage tooling has been confirmed in connection with active exploitation. The full scope of automated scanning activity is unknown.

Enterprise Impact

Container fleets: Any container that runs sshd and uses Alpine as its base image must be assessed. The majority of containerized services do not run sshd, but ops teams frequently enable SSH for debugging or as a legacy holdover. Finding those containers is the first task.

Cloud VMs: All official Alpine cloud images for AWS and Azure from 3.18.11 through 3.24.3 carry the vulnerable configuration. The window of risk opens once any account on the image receives a password hash — a step many organizations take during provisioning or through user-data scripts.

Embedded and edge systems: OpenWrt, Buildroot, and Yocto environments using musl without PAM are affected. These are harder to patch than a managed Linux VM and are often forgotten in vulnerability management programs. For organizations that have already been managing edge device exposure, this adds another category to track.

Credential and secrets exposure: An attacker who gains a shell on an Alpine container may find environment variables, mounted secrets, service account tokens, and cloud metadata endpoint credentials. The lateral movement potential from a compromised container or cloud instance is significant, particularly in Kubernetes environments where the service account token may carry permissions beyond the pod itself.

Compliance and notification: If an attacker accessed a system before patching and reached production data or credentials, that may constitute a reportable incident under applicable regulations. Organizations should document when they became aware of the vulnerability, what systems were exposed, and what actions were taken.

What Security Leaders Should Do Next

Today

1. Inventory Alpine Linux hosts. Find every Alpine-based VM, container base image, cloud image, and embedded system in your environment. Check whether sshd is running and whether PasswordAuthentication yes is set.
2. Apply the immediate mitigation on all exposed systems. Set PasswordAuthentication no in /etc/ssh/sshd_config and restart sshd. Confirm key-based login works before disabling password auth. This protects systems you cannot immediately repatch.
3. Upgrade the openssh-server package. Run apk update && apk upgrade openssh-server on each Alpine host. For branch-specific targets: 3.24.4+, 3.23.8+, 3.22.8+, 3.21.10+ or the latest patched package for older branches.
4. Restart sshd immediately after upgrading. Run rc-service sshd restart (OpenRC) or the equivalent for your init system. Without this step, the upgrade does not change anything about the running daemon.

Within 48 hours

1. Check for compromise. Review /var/log/messages on all affected systems for “Accepted password for” entries, especially for accounts like alpine, root, or any key-only users. Cross-reference shadow entries — if an account has * in its password field and shows a successful password login, treat that system as compromised.
2. Audit doas usage on cloud images. Review logs for any unexpected doas invocations by the alpine user, particularly doas sh or commands that would escalate to root.
3. Rebuild container images. For containerized workloads, pushing a package update to a running container is often insufficient. Rebuild affected base images to include the patched openssh-server, update your image registry, and redeploy affected containers.
4. Block or firewall port 22 on systems that do not require internet-facing SSH. This is defense in depth — the patch is what matters, but reducing exposure is always valuable.
5. Scan for IP 89.116.89[.]18 in firewall, proxy, and SSH logs going back to November 5, 2026, the date exploitation was first observed.

Long-term

1. Establish an inventory and patching program for Alpine Linux and musl-based systems. These systems have historically been treated as immutable and exempt from traditional patching programs. CVE-2026-123158 demonstrates that the base OS matters, not just application-layer dependencies.
2. Disable password authentication globally where possible. Enforce key-based SSH across your environment. This is both a remediation for SSHole and a durable reduction in SSH attack surface generally.
3. Add Alpine sshd to your vulnerability scanner’s scope. Ensure your scanning platform is running authenticated checks against Alpine hosts, not just glibc-based systems. Many scanner templates default to Debian or Red Hat and miss Alpine-specific findings. For related guidance on proactive Linux system hardening after active exploitation, see our earlier PHP2Shell briefing.
4. Review doas and sudo configurations. Remove passwordless privilege escalation rules that could be used as a post-bypass path to root. The alpine user’s default doas rule on cloud images is a one-step root escalation that survived the patch.

Winners and Losers

Final Executive Takeaway

This is not a vulnerability in an obscure product.

Alpine Linux is in production at virtually every organization that runs containers. OpenSSH is on every Alpine host by default. Password authentication is on by default. The bypass works with a single SSH client and a long string. Nine hours after the CVE was published, an attacker had root on a honeypot.

The two actions that matter are simple but easy to get wrong: upgrade the package, then restart sshd. Doing only the first step leaves the system fully exposed. For container environments, that often means rebuilding and redeploying, not just running apk upgrade.

Upgrade. Restart. Verify. Then hunt the logs for anyone who got in before you did.

Frequently Asked Questions

Sources

Primary sources: OpenSSH 10.6p2 release and security advisory (November 5, 2026); CVE-2026-123158 record; Alpine Linux security advisory (November 5, 2026); researcher Özgün Kültekin’s original disclosure. Corroborating reporting: Help Net Security (exploitation confirmed); The Hacker News (threat intelligence details); Detectify (affected version matrix and enterprise guidance); SOCRadar; Picus Security (attack chain analysis). Reflects public reporting as of November 8, 2026.