OpenSSH SSHole Exploited in 40 Hours: Alpine vs Debian

The OpenSSH SSHole vulnerability (CVE-2026-123158, CVSS 8.1 per NVD) was first exploited successfully about 40 hours after OpenSSH 10.6p2 shipped, according to the GreyNoise event tracker. The verdict on who is at risk is simple: Alpine Linux and other musl-based systems running sshd without PAM are exposed, while Debian and Ubuntu style glibc systems are not exploitable. If you run a musl image with sshd reachable, upgrade and restart the daemon today, then read your logs.

TL;DR

• SSHole is an authentication bypass in OpenSSH on Linux systems that use the musl C library with PAM disabled, fixed in OpenSSH 10.6p2 on 5 November 2026.
• A working exploit appeared on GitHub about 2.5 hours before the CVE ID was reserved, per GreyNoise.
• Alpine Linux is the main exposure. Debian, Ubuntu and other glibc distributions, plus Dropbear and OpenBSD, are not affected per the Alpine advisory.
• Upgrading the package is not enough. You must restart sshd, because the running daemon is not replaced.
• If you cannot patch, set PasswordAuthentication no and restart sshd.

Alpine vs Debian: which systems does the SSHole vulnerability affect?

The flaw needs a specific combination, which is why the same OpenSSH version number can be dangerous on one host and harmless on another.

Condition	Alpine (musl, no PAM)	Debian / Ubuntu (glibc)
Exploitable by SSHole	Yes, if the account conditions below hold	No
Default sshd build	PAM not used	PAM used
Fixed version	Alpine 3.21.10, 3.22.8, 3.23.8, 3.24.4	Upstream 1:10.6p2-1 in forky/sid
Action	Upgrade, restart, audit	Routine update

Debian's security tracker lists bookworm and trixie as vulnerable but marks the urgency as unimportant, because glibc systems cannot be exploited this way. That is the practical point: musl without PAM is the requirement, not the OpenSSH version alone.

Even on Alpine, three conditions must hold at once, according to the Alpine advisory:

1. The musl-based openssh-server is running without PAM, with PasswordAuthentication yes (the OpenSSH default).
2. At least one account has * in its shadow password field. Root ships as root:* in base images since roughly Alpine 3.16, and key-only users, the alpine user in official tiny-cloud images, and directory-service users (nslcd, winbind, sssd) can also match.
3. At least one other local account has a real crypt-style password hash.

Not affected: containers that do not run sshd, hosts with PasswordAuthentication no, openssh-server-pam with UsePAM yes, locked accounts (!), and cloud images configured through cloud-init, which writes PasswordAuthentication no.

How does the bypass work?

Without PAM, sshd checks a password by hashing the attempt with crypt() and comparing the result to the stored field. For accounts whose stored field is too short to hold a salt, sshd borrows another account's salt. The musl crypt() returns the string * when the supplied key exceeds 256 bytes. Since * is also what the shadow file stores for an account with no password, the two values match and the login succeeds. A password between 257 and 1024 bytes triggers it, per the Alpine advisory.

NVD's description frames this as a misinterpretation of whether a string is meant to be a password hash. The OpenSSH team says the root cause sits outside sshd but is reachable through it. The oversized-password handling traces back to a 2016 patch for CVE-2016-6210, a username enumeration fix, as The Hacker News reports. The report was credited to Özgün Kültekin of Wakefield in the OpenSSH release notes.

How fast was the OpenSSH SSHole exploited after the patch?

The timeline below uses UTC stamps from the GreyNoise tracker.

When (UTC)	Event
4 Nov, 21:18	Fix committed, not yet public
5 Nov, 09:00	Fix published; 10.6p2 announced on oss-security at 09:01
5 Nov, 12:19	Researcher write-up published
5 Nov, 13:16	First public exploit appears on GitHub
5 Nov, 15:46	CVE ID reserved by MITRE
5 Nov, 16:17	Published to NVD with CVSS 8.1
7 Nov, 00:46	First successful exploitation seen on a GreyNoise sensor

From the 09:00 publication to the first confirmed compromise is just under 40 hours. The more telling detail is the order: a public exploit existed about 2.5 hours before the CVE ID did. Teams that wait for a CVE number, a scanner plugin or a CISA listing before acting were behind from the start. A Tenable plugin (Nessus 377050) now covers the flaw, but that is a detection aid, not a head start.

From 09:00 on 5 November, GreyNoise counted 27.7 million TCP port 22 SYN scans, 20.2 million attempted SSH sessions and 16 successful intrusion chains from 6 attacker IPs. Other sensor networks saw smaller numbers. SecurityWeek reports that watchTowr linked early activity to botnets and cryptomining, while Defused described a small number of actors rather than mass exploitation.

What have attackers done after getting in?

GreyNoise describes one intruder, from an IP in a Microsoft network range in Hong Kong, gaining root on a sensor, installing a Python-based command-and-control agent called TAC Agent, and trying to enrol it with a server at tac.vpnla[.]org. The agent never reached that server and received no tasks. A second actor, from a China Mobile range, spent almost five hours surveying a sensor: checking for containers, querying AWS, Azure and Alibaba cloud metadata services, and attempting to read root SSH keys and /etc/shadow through doas. The exploit sessions used the Paramiko SSH library.

Ars Technica reports that GreyNoise tracks one group as GT10 and that the backdoor contains Chinese-language comments and appears to be AI-generated. Attribution to any country is not confirmed, so treat that as GreyNoise's tracking and not a finding about a state.

Why did OpenSSH ship the fix so quickly?

OpenSSH developer Damien Miller told SecurityWeek the team had recently seen several cases of AI agents rediscovering bugs within hours, and that long embargo periods now mainly benefit attackers. Whatever you think of that reasoning, the outcome here supports it: the gap between disclosure and use was measured in hours.

How do I patch and check for exploitation?

For Alpine, per the vendor advisory:

# Upgrade all packages, including the openssh-server subpackage.
# "apk upgrade openssh" alone only updates the meta-package.
apk upgrade -U -a

# Upgrading does not replace the running daemon, so restart it.
rc-service sshd restart

If you cannot update yet, set PasswordAuthentication no in sshd_config and restart sshd. On other musl-based builds such as Buildroot, OpenWrt or Yocto images, move to upstream OpenSSH 10.6p2 or later through your build pipeline.

Then audit:

• Search /var/log/messages for Accepted password for lines naming accounts that have no password.
• Look for a Failed password line immediately followed by an Accepted password for the same account. Alpine notes that the first attempt in a connection fails and the second succeeds because of a salt-cache quirk, so this pair is the signature.
• Review doas usage and recently created users, files and authorized_keys entries on exposed machines.
• On unpatched hosts, check for TAC Agent files or startup services.

Patch-race stories like this one are now common. For comparable cases see our coverage of Ivanti Connect Secure's three zero-days, the WordPress patch-first decision, Synology DSM and outdated firmware, and the Chainalysis breach, where exposed credentials were the common thread.

What is the verdict?

Patch windows are now counted in hours. If you run any musl-based image with sshd reachable from the network, upgrade, restart and review logs today. If you run Debian or Ubuntu, you can deprioritise this one. I could not find a CERT-In advisory for this CVE as of 9 November 2026, so Indian operators should rely on the vendor and upstream notices above.

FAQ

Q: Which OpenSSH version fixes SSHole?

A: OpenSSH 10.6p2, released on 5 November 2026, contains the fix. Alpine backports it per release, in versions 3.21.10, 3.22.8, 3.23.8 and 3.24.4.

Q: Is my Ubuntu or Debian server affected?

A: Not in practice. The bug needs sshd linked against musl with PAM disabled, and glibc distributions such as Debian and Ubuntu are not exploitable this way.

Q: Are Docker containers affected?

A: Only if sshd runs inside the container and the Alpine conditions hold: no PAM, password authentication on, and an account with a * shadow field plus another with a $-style hash. Containers without sshd are not affected.

Q: How do I check whether I was exploited?

A: Look for Accepted password for entries naming passwordless accounts, especially a Failed password followed straight away by an Accepted password for the same account. Also review doas use, new users and authorized_keys changes.

Q: Do I need to restart sshd after upgrading?

A: Yes. A package upgrade does not replace the running daemon, so run rc-service sshd restart on Alpine after apk upgrade -U -a.