CVE-2026-123158 (sshole): OpenSSH Password Bypass on Alpine Linux

CVE-2026-123158, nicknamed sshole, lets anyone log in over SSH without the password to certain accounts on Linux systems built on musl libc, most notably Alpine Linux. It affects OpenSSH's sshd before 10.6p2 when built without PAM, and is rated CVSS 3.1 8.1 (High). Public reproduction labs are available; no exploitation in the wild has been reported so far.

OpenSSH 10.6p2 and patched Alpine packages shipped on 5 November 2026. Upgrade, restart sshd, or turn off password authentication now.

What is CVE-2026-123158?

CVE-2026-123158 is an authentication bypass in how sshd checks passwords on musl-based Linux systems without PAM. The CVE record says sshd "lacks a workaround for a password authentication bypass (related to misinterpretation of whether a string is intended to be a password hash)" (CVE record). It is classed as CWE-394, unexpected status code or return value.

The bug comes from two conventions colliding. When musl's crypt() gets a key longer than 256 bytes, it returns the string * to signal an error. Glibc returns NULL instead, which sshd already rejects. On Alpine, * is also what /etc/shadow stores for an account that has no password. So sshd compares musl's error string to the stored field, finds * equals *, and accepts the login (Alpine Linux advisory).

OpenSSH says the root cause sits outside sshd, but the bug is exploitable through it, so sshd now blocks it: the fix in auth-passwd.c rejects any stored hash shorter than four characters. The researcher, Özgün Kültekin of Wakefield, traces the behaviour back to 2016 (sshhole.com).

How the sshole bypass works

The attacker connects and offers a password between 257 and 1024 bytes for an account whose shadow field is *. That field holds no salt, so sshd borrows the salt from another account's $5$ or $6$ hash and calls crypt(). musl rejects the over-long key and returns *, which is exactly the stored value, so the comparison succeeds and sshd logs the attacker in.

Is CVE-2026-123158 being exploited?

No exploitation in the wild has been reported as of 5 November 2026, but exploitation is trivial and public labs exist. Alpine puts it plainly: "It takes one connection, works every time, and needs no retries." CISA's enrichment marks exploitation status as "poc". The flaw is not in the KEV catalog.

The fix shipped without a long embargo. OpenSSH's Damien Miller said the team now considers "long embargo periods to be a dangerous practice that primarily benefits attackers", so expect mass scanning to start quickly.

Who is affected by CVE-2026-123158?

A system is exploitable only when all of these hold (Alpine Linux advisory):

• sshd runs on musl libc and is built without PAM, or with UsePAM no
• PasswordAuthentication is on, which is the default
• An account's shadow field is exactly * (locked ! accounts are safe)
• At least one other local account has a $5$ or $6$ password hash, whose salt sshd borrows

Glibc distributions such as Debian, Ubuntu, Fedora and RHEL are not affected, nor are systems using PAM. Alpine's root account has used * since about 3.16, but the default PermitRootLogin prohibit-password blocks it unless you changed that setting. Alpine's official cloud images (3.18.11 to 3.24.3) ship a user alpine with * and passwordless doas, so they become exploitable for root once any $6$ hash exists. Docker containers are only at risk if they run sshd with password logins.

Upstream, every OpenSSH portable release before 10.6p2 on Linux is in scope. Note that Alpine's fixed packages keep older version numbers, so scanners that only compare against 10.6p2 will flag patched Alpine hosts. Other musl systems, such as OpenWrt or Buildroot images, may also be exposed if they meet the conditions above.

How to fix CVE-2026-123158

1. Upgrade. On Alpine, run apk update && apk upgrade to get the fixed openssh package for your branch. Elsewhere, upgrade to OpenSSH 10.6p2 (release notes).
2. Restart sshd. Upgrading the package does not restart it: run rc-service sshd restart.
3. Or turn off password logins now. Keep a key-based session open, then create /etc/ssh/sshd_config.d/00-no-passwords.conf containing PasswordAuthentication no. Check with sshd -t, restart sshd, and confirm with sshd -T | grep -i passwordauthentication.

To see whether a host meets the conditions, list accounts with a * field and accounts with a real hash:

awk -F: '$2=="*"{print $1}' /etc/shadow awk -F: '$2 ~ /^\$[56]\$/{print $1}' /etc/shadow

If both commands print something and password logins are on, the host was exploitable.

How to check for compromise

Search /var/log/messages for Accepted password for entries naming an account that has no password, such as alpine, root or a key-only service account. Any such line is suspicious. Then review doas use, new users, changed files and authorized_keys entries on that host (Alpine Linux advisory). No network IoCs have been published.

How Ethiack helps

Ethiack's continuous attack surface testing now detects CVE-2026-123158. We find every internet-facing SSH service you expose, including hosts outside your known inventory, and flag musl-based servers that still accept password logins. Because Alpine's patched packages keep older version numbers, we check how each server behaves rather than its version banner alone.

Follow new signals on this flaw in the sshole entry on Ethiack Zero. For other recent pre-auth flaws, read our analysis of the PHP2Shell interpreter RCEs and CVE-2026-85706 in GitLab.

Validate your exposure before attackers do. Start your 30-day free trial of Ethiack, no commitment.

FAQ

Are Ubuntu, Debian or RHEL servers affected by CVE-2026-123158? No. They use glibc, whose crypt() returns NULL on error, which sshd already rejects. Systems using PAM are also safe.

Can attackers log in as root? Not directly with Alpine's default PermitRootLogin prohibit-password. They can reach root through another * account with do-as rights, such as the alpine user on official cloud images.

Does the attacker need to know a password? No. Any password between 257 and 1024 bytes works against an account whose shadow field is *.

Is there a public exploit for sshole? Yes. Public reproduction labs are linked from the CVE record. No attacks in the wild have been reported yet.

Is updating enough? Only after you restart sshd. The running daemon keeps the old code until it restarts.

References

• OpenSSH 10.6p2 release notes
• OpenSSH fix commit 4353fdc
• Damien Miller on openssh-unix-dev
• Alpine Linux: OpenSSH password authentication bypass
• CVE-2026-123158 record (CVE JSON)
• *sshole, researcher write-up by Özgün Kültekin