CVE-2026-123158: OpenSSH sshhole Bypass Hits Alpine Linux

OpenSSH has shipped an emergency release, OpenSSH 10.6p2, to stop a password authentication bypass that lets a remote attacker log in to some Linux SSH servers by typing any password longer than 256 bytes, with Alpine Linux the most widely exposed platform.

The flaw, tracked as CVE-2026-123158 and nicknamed sshhole by its discoverer, carries a CVSS 3.1 score of 8.1 (High) from MITRE. It affects sshd in OpenSSH before 10.6p2 when the server is built against the musl C library and runs without PAM (Pluggable Authentication Modules), which is how Alpine Linux ships its default openssh-server package. The code path behind it has been in portable OpenSSH since version 7.3 in 2016.

OpenSSH maintainer Damien Miller announced the release on Thursday, November 5, one day after the project learned of the bug, and told operators of affected systems to set PasswordAuthentication=no or disable SSH “IMMEDIATELY.” Researcher Özgün Kültekin of Wakefield, credited in the OpenSSH 10.6p2 release notes, has published a full technical write-up at sshhole.

As of November 6, OpenSSH and Alpine Linux have both shipped fixes, while other musl-based platforms such as OpenWrt, Buildroot, and Yocto have not published a fix status. Debian, Ubuntu, Fedora, Red Hat Enterprise Linux, and other glibc-based distributions are not affected.

How the OpenSSH sshhole Bypass Works

CVE-2026-123158 is a logic bug, not memory corruption, and it sits in the gap between two projects. Without PAM, sshd checks a password itself: it runs the submitted password through the C library’s crypt() function with a salt, then compares the result with the hash stored in /etc/shadow.

Accounts meant for key-only login, LDAP-mapped users and root on Alpine often have a single asterisk (*) in that password field, which normally means no password can ever match. For those accounts, sshd borrows a salt from another local account that has a real SHA-256 ($5$) or SHA-512 ($6$) hash. OpenSSH added that salt-borrowing behaviour in 2016 to fix CVE-2016-6210, a timing leak that let attackers work out which usernames existed.

musl’s SHA-based crypt() refuses keys longer than 256 bytes, and since 2012 musl has returned the string * on failure instead of the NULL that POSIX expects. So when an attacker sends a password between 257 and 1,024 bytes, crypt() returns *, sshd compares it with the stored *, the two strings match, and the login succeeds. The attacker needs only network access to the SSH port and the name of a * account; there is no password to guess.

Kültekin says he found the bug while testing sshd builds across combinations of glibc, musl, PAM and shadow support, roughly 17,600 logins in all, and only the musl build without PAM accepted logins it should have rejected. He says he used “agent swarms” for the testing; the write-up does not say AI found the flaw on its own.

Miller wrote the workaround, committed as 4353fdc4 on master and 90f9c2f7 on the 10.6 branch under the title “avoid password authn bypass.” According to TuxCare’s analysis, the change makes sshd reject any stored hash shorter than four characters, so a value like * can never match.

Why OpenSSH Blames musl, and musl Disagrees

OpenSSH’s release notes say the project considers the root cause of CVE-2026-123158 to lie outside sshd, but the bug is exploitable through sshd and can be avoided there, which is why the fix landed in OpenSSH.

musl maintainer Rich Felker has taken the opposite view, according to TuxCare: he calls it an erroneous use of crypt() by the caller rather than a musl bug, while saying the error behaviour will likely change in the next musl release cycle. Felker had already floated revisiting the “unmatchable hash” design in a December 2024 musl mailing list thread about long passwords crashing passwd on Alpine.

Why OpenSSH Skipped the Embargo

OpenSSH released 10.6p2 without the weeks-long embargo that usually precedes a coordinated fix. Miller said the project had recently seen several cases of AI agents rediscovering reported bugs, “sometimes within hours,” and now regards long embargo periods as a dangerous practice that mainly helps attackers.

The short window shows in the downstream picture. Alpine published fixed packages the same day, but on release day many other distributions and mirrors were still offering OpenSSH 10.6p1.

Which Alpine Linux Versions Have a Fix for CVE-2026-123158

Alpine Linux’s November 5 security advisory covers every branch back to 3.16, including branches that no longer receive regular updates. Stable branches carry a backported fix, so a patched Alpine 3.24 server still reports OpenSSH 10.3p1, not 10.6p2.

Alpine warns that its official tiny-cloud images, from 3.18.11 to 3.24.3, ship an alpine user with a * password field and passwordless doas. That account is safe on first boot, but once any other account on the machine gets a $5$ or $6$ password hash, an attacker can log in as alpine and become root. Default settings still block direct root password logins.

The official Alpine Docker image is not exposed on its own, because containers that do not run sshd cannot be reached this way. Images that add sshd and a hashed password are exposed and should be rebuilt on a fixed base. The openssh-server-pam package with UsePAM yes is not affected, and Dropbear’s maintainer has confirmed Dropbear is not affected, which matters for OpenWrt routers that use Dropbear by default.

Is CVE-2026-123158 Being Exploited?

As of November 6, neither OpenSSH nor Alpine reports attacks using CVE-2026-123158, and Cyber Kendra found no CISA Known Exploited Vulnerabilities listing for it. CISA’s enrichment on the CVE record marks exploitation status as “poc,” meaning proof-of-concept code is public.

The CVE record links two public reproduction labs on GitHub, sshhole-repro and sshhole-lab, and Kültekin publishes a check script that reports accounts that accept the bypass. Because the attack needs one connection and one long string, Alpine tells admins to treat affected machines as compromised if they cannot rule out unauthorised access.

What Alpine and musl Admins Should Do Now

On Alpine Linux, run apk upgrade -U -a and then rc-service sshd restart. Alpine stresses that the package upgrade does not replace the running daemon, so sshd stays vulnerable until it restarts. Confirm the installed version with apk info -v openssh-server and compare it with the table above.

Until the update is in place, Alpine and OpenSSH both advise setting PasswordAuthentication no and restarting sshd, or turning SSH off. Check that key-based login works and keep an existing session open while you restart. On Alpine 3.18 and older, drop-in files in /etc/ssh/sshd_config.d/ are ignored, so put the setting in /etc/ssh/sshd_config itself.

To see whether a host meets the attack conditions, list accounts with a bare asterisk using awk -F: '$2=="*"{print $1}' /etc/shadow, and accounts with a SHA-256 or SHA-512 hash using grep -E '^[^:]+:\$[56]\$' /etc/shadow | cut -d: -f1. A host with entries in both lists, password authentication on and sshd without PAM is exposed.

For signs of compromise, Alpine suggests searching /var/log/messages for Accepted password for entries on accounts that have no password, along with unexpected doas activity and new entries in authorized_keys files. Anyone building OpenSSH against musl without PAM on OpenWrt, Buildroot, Yocto, Void Linux or another platform should move to OpenSSH 10.6p2 directly, since none of those projects has published a fix status.