OpenSSH CVE-2026-123158 \"sshole\": Alpine auth bypass exploited in the wild

A remote attacker who can reach the SSH port of an Alpine Linux box — or any Linux system built on musl libc without PAM — can log into accounts that are supposed to reject every password, by sending a password nobody set. The bug, CVE-2026-123158, nicknamed "sshole" by its finder, was fixed in OpenSSH 10.6p2 on November 5. Threat-intelligence firm Previdian says the first exploitation attempt hit its sensors less than nine hours after the CVE was published, and that one of those attempts reached root on a honeypot running real Alpine. This is the rare authentication bypass that is both trivial and already being used.

Developing story — first published 13:54 CET (12:54 UTC), 2026-11-06. Updated as the vendor and CISA publish more.

At a glance

CVE	CVE-2026-123158
Product / affected versions	OpenSSH before 10.6p2 on Linux with musl libc and PAM disabled — e.g. Alpine's default openssh-server; Alpine 3.16 through 3.24 and edge
Fixed in	OpenSSH 10.6p2 (2026-11-05); Alpine edge 10.6_p2-r0 with back-ports per branch (3.24 10.3_p1-r2 · 3.23 10.2_p1-r1 · 3.22 10.0_p1-r11 · 3.21 9.9_p2-r1; 3.16–3.20 also patched)
CVSS	8.1 High · CVSS 3.1 AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H · scored by MITRE (NVD status: Received)
Exploited in the wild	Yes · Previdian reports a successful root login on an Alpine honeypot; first attempt < 9h after disclosure (via Help Net Security)
CISA KEV	Not listed (catalog version 2026.11.04)
Public PoC	Yes · unverified PoCs posted to GitHub; Previdian warns they may contain malware (as of 2026-11-06)
Official advisory	OpenSSH 10.6p2 release notes · Alpine Linux advisory

How a 300-byte password opens a locked account

The bug is a collision of three design decisions, none of which is wrong on its own. The researcher's write-up lays out the chain, and the NVD description confirms the shape of it.

Accounts that should never accept a password — key-only users, directory-service users, root on Alpine — carry a single * in the password field of /etc/shadow. A * is not a valid hash, so in principle no password can ever match it.

In 2016, OpenSSH changed sshd to close a username-enumeration timing leak (CVE-2016-6210): when an account has no usable hash, sshd now hashes the supplied password anyway against a salt borrowed from another account, purely to burn the same amount of time an attacker would see for a real user. As the researcher puts it, "sshd grabs some other account's salt and hashes your password anyway, just to waste the same amount of time."

The third piece is musl. Since 2012, musl's crypt() has refused SHA-256/512 passwords longer than 256 bytes and, on failure, returns the unmatchable string *. So on a musl box, hashing an oversized password against the borrowed salt returns * — which is exactly what the locked account already stores. The two strings match, and sshd lets the login through. The practical trigger is a password of roughly 257 to 1024 bytes. OpenSSH's own view is that "the root cause of this bug [is] outside sshd, but it is exploitable via sshd," which is why 10.6p2 ships a workaround rather than a one-line fix.

The researcher built sshd in every combination he could — glibc, musl, PAM, no PAM, shadow, no shadow — and threw roughly 17,600 unusual logins at it. "Every build agreed on every login. Except musl without PAM."

Who is exposed, and how to check

You are exposed only if all of these hold, per the Alpine advisory:

• You run Alpine's openssh-server (built without PAM), or openssh-server-pam with UsePAM no.
• PasswordAuthentication is yes — the OpenSSH default.
• At least one account has a * password field (root on Alpine ships as root:*; so do key-only users, and directory users via musl-nscd).
• At least one local account has a real $5$/$6$ hash — that account's salt is what gets borrowed.

Not affected: glibc distributions (Debian, Ubuntu, Fedora), anything authenticating through PAM, Dropbear, OpenBSD, locked ! accounts, and any host with PasswordAuthentication no. The blast radius is Alpine and the long tail of musl-based systems — OpenWrt, Buildroot, Yocto, and a great many container images.

Two configurations turn this from "a locked user logs in" into root. On Alpine where an admin set PermitRootLogin yes, root is directly reachable. And on Alpine's official AWS and Azure images (tiny-cloud 3.18.11 through 3.24.3), the default alpine user has passwordless doas — so a login as alpine is, in effect, root.

# Are you musl-without-PAM? (Alpine's default sshd is)
ldd /usr/sbin/sshd | grep -q musl && echo "musl libc"
sshd -T | grep -iE 'passwordauthentication|usepam'
# List accounts whose password field is "*" (candidate targets)
awk -F: '$2=="*"{print $1}' /etc/shadow

Remediation

1. Am I affected?

Run the three commands above. If sshd links musl, passwordauthentication yes is set, and /etc/shadow has one or more * accounts alongside a real-hash account, treat the host as vulnerable.

2. Patch — exact fixed versions

Upgrade to OpenSSH 10.6p2 or the Alpine back-port for your branch: edge 10.6_p2-r0, 3.24 10.3_p1-r2, 3.23 10.2_p1-r1, 3.22 10.0_p1-r11, 3.21 9.9_p2-r1; 3.16–3.20 are patched too. On Alpine, apk upgrade -U -a. The point releases 3.21.10, 3.22.8, 3.23.8 and 3.24.4 carry the fix.

Upgrading the package does not restart the running sshd. The old binary keeps accepting connections until you restart the service: rc-service sshd restart. A patched box that was never restarted is still live. Keep your current session open and test a fresh login before closing it.

3. Can't patch now? Compensating control

One line closes the hole: set PasswordAuthentication no and restart sshd. OpenSSH developer Damien Miller's guidance for affected systems was blunt — set it "or disable SSH for these systems IMMEDIATELY." On Alpine:

echo 'PasswordAuthentication no' > /etc/ssh/sshd_config.d/00-no-passwords.conf
sshd -t && rc-service sshd restart
sshd -T | grep -i passwordauthentication   # must print: passwordauthentication no

4. Hunt for compromise

The attack lands as a successful password login to an account that has no password — so your evidence is a log line that should be impossible. On Alpine, search syslog:

grep "Accepted password for" /var/log/messages | grep -E 'root|alpine|<key-only-users>'

Any Accepted password for root, alpine, or a key-only account is a confirmed hit. Previdian observed the attacker running id, uname and hostname through non-interactive SSH sessions — map this to T1133 (External Remote Services) for the entry, T1078.003 (Valid Accounts: Local) for the resulting access, and T1033/T1082 (owner and system discovery) for the recon. The one public IOC so far is the source address 89.116.89[.]18 (Japan-based); treat it as an indicator, not a boundary. Also review recent doas use, newly created users, and authorized_keys files.

5. Eradicate and verify

If you cannot rule out a successful login, treat the machine as compromised: rotate every credential and key reachable from the affected accounts, review authorized_keys and cron/service persistence, and rebuild if in doubt. Then confirm the fix with the same test that would have exploited it — attempt a password login with an oversized password against a * account from a patched, restarted sshd, and confirm it is refused.

What is not known yet

• Scale. Previdian's public figure is eight attempts from a single address against one sensor. Broader internet-wide scan volume has not been quantified.
• CISA KEV. The CVE is not in the catalog (version 2026.11.04) as of this writing. Given confirmed in-the-wild exploitation of a widely deployed service, that may change; we will update this post if it does.
• NVD status. The record is still "Received" — the 8.1 score is MITRE's; NVD analysis may adjust it.
• PoC provenance. Proof-of-concept code is circulating on GitHub, but Previdian cautions the public copies are unverified and may contain malware. Do not run untrusted PoCs against production.

Finding every exposed box before the next scan does

The honest difficulty here is not the fix — it is one line — but knowing which of your hosts actually meet all four preconditions. A fleet with Alpine base images in CI runners, sidecars, appliances and IoT firmware does not have a tidy inventory of "musl, no PAM, password auth on, a * account plus a real-hash account." That is an exposure-validation problem, and it is exactly the question an autonomous penetration-testing run answers by proving reachability rather than guessing from a version string.

Zero Hunt runs that validation as an autonomous AI red team on an on-premise appliance, on its own private models, with a human approving anything that touches a live host. Its AI Remediation Advisor ranks what it proved exploitable — a passwordless account reachable over SSH outranks a CVSS number every time — hands back the exact fix with the restart step and the PasswordAuthentication no fallback, and re-verifies the box with the same oversized-password check that demonstrated the bypass, so "patched" means proven, not assumed. There is a certain symmetry worth noting: the researcher who found "sshole" said he leaned on agent swarms to grind through 17,600 test logins. Finding the next class of these before an attacker does is now a job for machines that attack — kept in-house, under your control, and switched off nowhere but by you.