sshole (CVE-2026-123158): OpenSSH musl Password Bypass Root Cause, Detection and Mitigation

CVE-2026-123158 (“sshole”) lets an unauthenticated attacker log into any OpenSSH account whose /etc/shadow password field is exactly * by sending a 257 to 1024 byte password. It only works when sshd is linked against musl libc, runs without PAM, has PasswordAuthentication yes, and at least one other local account holds a $5$ or $6$ hash. Fix: OpenSSH 10.6p2 or your distribution backport, then restart sshd.

Upgrading the package does not replace the running daemon. Restart sshd, then confirm with readlink /proc/<sshd pid>/exe that the binary is not marked (deleted).

CVE-2026-123158 at a glance

One CVE, published 2026-11-05 by MITRE as CNA. Each line below is one field.

Topic	Value
Type and CWE	Password authentication bypass. MITRE: CWE-394 (Unexpected Status Code or Return Value). Red Hat: CWE-303 (Incorrect Implementation of Authentication Algorithm).
CVSS v4	None published by MITRE, NVD, GitHub or Red Hat.
CVSS v3.1	8.1 High, CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H. Network reachable, no credentials, no user action, full impact. AC:H reflects that the account and hash layout on the target must line up.
CISA SSVC (Vulnrichment)	Exploitation: poc. Automatable: no. Technical Impact: total.
Precondition	musl libc sshd, no PAM (or UsePAM no), PasswordAuthentication yes, a reachable account with shadow field *, and a separate account with a $5$/$6$ hash.
Exploited in the wild	No confirmed exploitation. Not in CISA KEV catalogVersion 2026.11.04 (dateReleased 2026-11-04T20:00:05Z), which predates the CVE’s publication on 2026-11-05 15:46 UTC, so its absence proves nothing yet. Public reproductions exist.
Fixed builds	Upstream OpenSSH 10.6p2. Alpine: 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.20 9.7_p1-r6, 3.19 9.6_p1-r3, 3.18 9.3_p2-r4, 3.17 9.1_p1-r7, 3.16 9.0_p1-r6.
Vendor workaround	PasswordAuthentication no and restart sshd, or use openssh-server-pam with UsePAM yes.

In brief, these are the affected software and platforms:

Alpine host running openssh-server

• sshd linked against musl, built without PAM
• PasswordAuthentication yes (OpenSSH default)
• an account with shadow field *
• another account with a $5$ or $6$ hash

Exploitable

Any password of 257 to 1024 bytes logs in as the * account

Patch and restart today

Debian, Ubuntu, RHEL with PAM

• glibc or libxcrypt never return a bare *
• PAM handles the password check

Not affected

Vendor statements and the OpenSSH release say not affected

No action for this CVE

1. The Alpine tiny-cloud alpine user becomes root. Official AWS, Azure and qcow2 tiny-cloud images from 3.18.11 through 3.24.3 ship alpine with a * field and passwordless doas. They are safe until any $6$ hash is added to the box, for example a console password or a hashed_passwd in user-data. After that, one connection gives a shell, and doas gives root.
2. “Patched” may still mean vulnerable. Hosts upgraded in April 2026 to OpenSSH 10.3 for the certificate principals bypass (CVE-2026-35414) are still exposed here, as is upstream 10.6p1. Only 10.6p2 or the Alpine revisions in the table are fixed. Spectrum reports that apk upgrade openssh upgrades only the meta-package and leaves openssh-server at the vulnerable revision; Alpine’s advisory uses apk upgrade -U -a.
3. Logs show a normal login. sshd never logs password length. The only host signal is Accepted password for <user> where <user> has no password. If the attacker reached root through doas, they can edit /var/log/messages.

Components: sshd password path in auth-passwd.c and openbsd-compat/xcrypt.c. musl crypt() SHA-256/SHA-512 backends. Endpoint: SSH userauth “password” method on the listening port. Embedded Buildroot, Yocto and OpenWrt builds: affected only if they ship OpenSSH (not Dropbear), without PAM, with matching accounts.

Root cause: sys_auth_passwd() compares a musl error string to a shadow sentinel

The bug is a collision of one byte. musl’s crypt() returns "*" on failure, and * is also what /etc/shadow stores for an account with no password. sys_auth_passwd() in auth-passwd.c compares the two with strcmp() and accepts.

1. The client sends a password-method userauth request. auth_password() rejects anything over MAX_PASSWORD_LEN (1024) and passes the rest to sys_auth_passwd(). That cap is why the window ends at 1024 bytes.
2. shadow_pw() returns the target’s stored field, *. It is too short to hold a salt, so sshd asks xcrypt() to pick one.
3. xcrypt() calls pick_salt(), added in 2016 for the user-enumeration timing fix (CVE-2016-6210). It walks the password database and borrows the salt from the first $-style hash.
4. With a $5$ or $6$ salt, musl routes to its SHA-crypt code, which caps the key at KEY_MAX 256 bytes. A 257 byte or longer key fails, and musl returns "*".
5. strcmp("*", "*") == 0. Authentication succeeds.

Why it breaks only here: glibc returns NULL and libxcrypt returns "*0"/"*1", never a bare "*". With PAM active, sshd never calls sys_auth_passwd(). A ! field, or !$6$…, never equals *. If the first borrowed hash is bcrypt, musl truncates at 72 bytes instead of failing.

CVE-2026-123158 patch (commit 4353fdc)

This patch spans across three files, 34 additions and 17 deletions.

/* auth-passwd.c */
+#define MIN_PASSWORD_HASH_LEN 4
 #define MAX_PASSWORD_LEN 1024
 ...
-  char *pw_password = authctxt->valid ? shadow_pw(pw) : pw->pw_passwd;
+  char *pw_password = authctxt->valid ?
+      shadow_pw(pw) : xstrdup(pw->pw_passwd);
 ...
-  return encrypted_password != NULL &&
+  ret = encrypted_password != NULL &&
+      strlen(pw_password) >= MIN_PASSWORD_HASH_LEN &&
       strcmp(encrypted_password, pw_password) == 0;
+  freezero(pw_password, strlen(pw_password));
+  return ret;

/* openbsd-compat/xcrypt.c, shadow_pw() */
-  return pw_password;
+  return pw_password == NULL ? NULL : xstrdup(pw_password);

This patch introduces two changes. First, a stored field shorter than 4 characters can never match, so *, !, !! and *0 are dead. Second, shadow_pw() now returns a heap copy instead of a pointer into libc’s static getspnam() buffer, and pick_salt() frees each copy. openbsd-compat/port-uw.c gets the same copy-and-free change.

The commit message says OpenSSH does not consider the root cause to be inside OpenSSH. The CWE-394 assignment is confirmed as the caller did not handle a legitimate but unexpected return value.

CVE-2026-123158 Detections:

These were a few approaches I think can help detect exploitation attempts. Some rules definitely need correlation and will need baselining.

1. Sigma rule 1: password login to an account with no password
2. Sigma rule 2: Failed then Accepted pair (correlation)
   The correlation groups on src_ip and user. Your SIEM must extract those fields from the syslog line; keyword rules alone do not create them. Raise it to high when the user is in the * list.
3. Sigma rule 3: doas by the cloud-image user

Which government CERTs have issued alerts?

Four national bodies had published something by 2026-11-06: France (two notices), Hong Kong, Hungary and Canada. CERT-FR is the only one that issued an alert rather than a routine advisory, and the only one that names the trigger correctly. Every one of them lists “all OpenSSH before 10.6p2” as affected, which is broader than the real scope.

Agency (country)	Notice and date	Rating	Information	Data Issue
CERT-FR (France)	CERTFR-2026-ALE-015, alert, 2026-11-05	Called “trivial to exploit” when conditions are met	musl without PAM, or PAM disabled. Login with two passwords, the second longer than 256 and shorter than 1024 characters. Workaround: disable password authentication, or SSH entirely	Affected systems line says all versions before 10.6p2; does not name Alpine
CERT-FR (France)	CERTFR-2026-AVI-1468, advisory, 2026-11-05	Security policy bypass	One-line summary, points to the OpenSSH release notes	Lists no CVE
HKCERT (Hong Kong)	Security bulletin, 2026-11-06	Medium	CVE-2026-123158, security restriction bypass, apply 10.6p2. Notes public proof of concept and that glibc distributions are unaffected	URL and summary say “multiple vulnerabilities” for one CVE; lists all versions before 10.6p2; reads the CVE record’s “lacks a workaround” as “no workaround exists”
NKI (Hungary)	Vulnerability notice, 2026-11-05 16:46	High, CVSS 8.1, priority “Elevated”	Restates the CVE record; links the commit, mailing list post and reproductions; cross-references ENISA EUVD-2026-117552	Repeats the record’s 256 lower bound; advises patching on the normal schedule with no immediate action
Canadian Centre for Cyber Security	AV26-1130, “OpenBSD security advisory”, 2026-11-05	None stated	Points to the OpenSSH release notes	Says “OpenBSD is affected”, which contradicts OpenSSH: non-Linux systems are not affected

Frequently asked questions

What is CVE-2026-123158?
It is an OpenSSH password authentication bypass, nicknamed sshole, in sshd before 10.6p2 on Linux systems that use musl libc without PAM. A password of 257 to 1024 bytes logs into any account whose shadow field is *.

Is Alpine Linux affected?
Yes, Alpine 3.16 through 3.24 and edge with the default openssh-server package, password logins on, a * account and a $5$/$6$ hash present. Fixed revisions are listed above.

Are Debian, Ubuntu or RHEL affected?
No. They link OpenSSH against glibc and use PAM. Red Hat lists every product as not affected.

Are Docker containers affected?
Only containers that run sshd. An Alpine base image without sshd is not exposed.

What is the fastest mitigation?
Set PasswordAuthentication no, run sshd -t, restart sshd and confirm with sshd -T.

How do I know if I was attacked?
Search the auth log for Accepted password for an account whose shadow field is *. Any hit means the host is compromised until proven otherwise.

Is it being exploited?
No confirmed exploitation, and it is not in CISA KEV catalogVersion 2026.11.04, a catalog released the day before the CVE was published. Public reproduction code exists.