The Patch Is Out. The Attacks Are Already Here.

OpenSSH shipped the fix. Attackers were already inside.

Less than nine hours after the disclosure of CVE-2026-123158 — the “SSHole” authentication bypass — a threat intelligence firm observed the first exploitation attempt in the wild, and confirmed successful root access on an Alpine Linux honeypot running OpenSSH. The window between patch and exploit was measured in hours, not days. If your servers run OpenSSH on a musl-based system, that window is the story.

What happened

SSHole affects OpenSSH builds on musl libc with PAM disabled, a combination that includes the default openssh-server configuration on Alpine Linux. An unauthenticated attacker sends an oversized password — between 257 and 1,024 bytes — to an account that has no usable password. The failed password-hash operation returns the string *, which happens to be exactly the value stored for password-disabled accounts. The daemon compares the two, finds a match, and grants the login.

The bug traces back to a 2016 patch for username-enumeration hardening, and it only works when at least one account on the target has * as its password hash. Accounts with valid password hashes are not affected, and neither are Dropbear, glibc-based distributions, non-Linux systems, or PAM-based authentication.

That narrow scope did not slow anyone down. Threat intel firm Previdian recorded eight attempts from a single IP address, 89.116.89.18, geolocated to Japan. The attacker ran simple reconnaissance commands — id, uname, hostname — through non-interactive SSH sessions, and reached root on the honeypot. The vulnerability was discovered by researcher Ozgun Kultekin.

Why it matters

Alpine Linux is everywhere defenders forget to look: containers, edge devices, embedded systems, and the base images underneath larger deployments. A vulnerability that needs no credentials, no interaction, and no valid password — just a reachable SSH port and a disabled account — is exactly the kind of flaw that gets scanned for at scale within hours of disclosure. This one was, and it worked.

The other lesson is about the tail of an old fix. A 2016 hardening change, written to stop attackers from learning which usernames exist, silently created a path to root ten years later. Code that touches authentication deserves re-examination every time the surrounding system changes.

What to do now

1. Patch and restart. Upgrade to OpenSSH 10.6p2, or install your distribution’s patched package, then restart sshd. Patching the binary without restarting the daemon leaves the vulnerable process running.

2. Check your logs for logins that should never have happened. On Alpine, search /var/log/messages for Accepted password for lines naming accounts that should never accept password logins. Any hit is a red flag.

3. Hunt for persistence. Review doas usage, look for newly created users, files, and authorized keys, and check for unexpected processes or network connections. Treat any machine where a password login cannot be ruled out as compromised and rebuild it.

4. Audit your exposed surface. Confirm which of your systems run musl-based OpenSSH without PAM, and make sure SSH is not reachable from the internet where it does not need to be. If it must be exposed, key-based authentication only, and a firewall allowlist in front of it.

The patch is out. The proof that attackers move faster than patch cycles is already in the logs. Close the gap before your server is the one in the next honeypot report.