If you run Alpine Linux in Docker containers, Kubernetes pods, routers, NAS boxes, or edge devices — and you rely on key-only or “locked” passwordless SSH accounts to keep intruders out — this is a stop-and-patch alert. Tracked as CVE-2026-123158 and nicknamed “SSHole,” this authentication-bypass flaw in OpenSSH lets anyone who can reach your SSH port log into accounts that have no password at all, in a single try. It is being actively exploited in the wild, and CISA added it to its Known Exploited Vulnerabilities (KEV) catalog on November 9, 2026.

What the bug is

SSHole hits sshd on Linux when it is built against the musl C library with PAM (Pluggable Authentication Modules) disabled. The canonical victim is Alpine Linux: its default openssh-server package ships without PAM, and password authentication remains enabled by default.

The root cause is a hash-matching mistake. Normally, when you send a password, sshd hashes it and compares the result to the hash stored in etc/shadow. But for accounts whose shadow password field is a single asterisk (*) — the standard way to mark an account as having no login password — a password longer than 256 characters (up to 1,024) makes musl’s crypt() routine return * as its error output instead of a real hash. OpenSSH then treats that * as a successful match against the locked account’s * field. Result: any password between 256 and 1,024 characters long logs you straight in.

Who’s affected and why it’s dangerous

This does not require a weak password — it requires an account with no password. That is exactly the setup security-conscious admins intentionally create. The affected accounts include key-only service accounts, the alpine user in many tiny-cloud images, and even root if PermitRootLogin is enabled. Once inside, an attacker gets a real shell and can read cloud metadata, harvest SSH keys and password hashes, drop persistence into authorized_keys, and deploy malware. Alpine has confirmed every release from 3.16 through 3.24 and edge is vulnerable, along with openssh-server-pam when configured with UsePAM no.

Active exploitation

OpenSSH patched the flaw in portable release 10.6p2 on November 5, 2026, and researchers released a proof of concept almost immediately. Within nine hours, threat-intel firm Previdian recorded the first exploitation attempt. All eight attempts observed so far came from a single IP address and were caught on a honeypot running real Alpine Linux — with root access confirmed. In the wild, attackers used the bypass to run reconnaissance, harvest keys and hashes, install persistence, and drop a Python-based command-and-control implant, reinforcing CISA’s decision to list it as actively exploited.

What you should do

• Patch OpenSSH to 10.6p2 or later. Alpine has released updated packages — update immediately with apk upgrade openssh, and update the base image for every container and VM you build.
• If you cannot patch right now, disable password authentication with PasswordAuthentication no in sshd_config. SSHole only matters while password auth is enabled; key-based-only deployments are not exposed.
• Do not rely on the bare asterisk to lock accounts. Properly lock accounts with a real, unreadable hash or an account lock, rather than the empty-* field.
• Restrict the SSH port. Bind sshd to your management network and firewall off direct internet exposure where possible.
• Hunt for compromise. If you ran an affected version, check etc/shadow for altered * accounts, inspect authorized_keys for unexpected keys, scan auth logs for oversized-password attempts, and watch for the TAC Agent implant seen in the wild.
• Treat CISA KEV entries as deadlines. Federal agencies must remediate these on a fixed schedule under BOD 26-04 — and you should give the same urgency to any vulnerability that is confirmed to be exploited in the wild.

SSHole may target container distros, but the blast radius is every service you run on them. Patch now.