OpenSSH 10.6p2 Fixes a Password Bypass on musl Systems Without PAM, and Alpine Images Are the Main Exposure

Portable OpenSSH 10.6p2, released on 5 November 2026, works around a password authentication bypass in sshd that affects Linux systems built on musl libc with PAM disabled. Tracked as CVE-2026-123158 (CVSS 3.1 base score 8.1, assigned by MITRE), it lets a remote attacker log in to some accounts with any password between 256 and 1024 characters. Alpine Linux, which defaults to musl and an sshd without PAM, is the platform the CVE record names. A public reproduction, a lab container called sshhole-lab, is available, and CISA's SSVC entry records exploitation as "PoC".

What is affected

The NVD record covers OpenSSH before 10.6p2 on Linux. In practice the bug needs several conditions together. The researcher write-up at sshhole.com lists them: sshd built against musl (Alpine, OpenWrt, Buildroot and Yocto are named), PAM not in use, password logins enabled (the default), and an account whose password field in /etc/shadow is *, such as a key-only user, an LDAP user, or root on Alpine. The password must be 257 to 1024 characters. NVD words the lower bound as 256; Alpine and sshhole.com say 257, matching musl's 256-byte limit.

Alpine's advisory adds that the exposed setups are openssh-server (no PAM) or openssh-server-pam with UsePAM no, with PasswordAuthentication yes, and that at least one account on the machine has a $5$ or $6$ hash. Root is protected only if PermitRootLogin is not yes. Alpine's official tiny-cloud images from 3.18.11 through 3.24.3 ship an alpine user that becomes exploitable once such a hash exists, and sshhole.com notes that this user has passwordless doas on AWS and Azure images, so a login leads to root. Alpine says every release it checked is affected, from 3.16 through 3.24 and edge.

Not affected, per sshhole.com: glibc systems such as Debian, Ubuntu and Fedora, PAM-based setups, Dropbear, and OpenBSD. Container images that run sshd on Alpine, for example the panubo/docker-sshd image discussed in a GitHub issue linked from the CVE, and embedded musl devices are the likeliest exposed targets.

An sshd is exposed only when all four conditions hold; the fix is OpenSSH 10.6p2 or Alpine's patched package.

Why it happens

The researcher write-up traces the bug to two musl changes from 2012. First, musl's crypt() stopped returning NULL on failure and began returning *, a value that should never match a real hash. Second, musl's SHA-512 crypt has a 256-byte key limit, so a longer password makes crypt() fail and return *. sshd compares that result to the stored field, and for an account whose field is also * the strings match and the login succeeds. A 2016 change for CVE-2016-6210 made sshd hash attempts using another account's salt for invalid users and for * accounts, which sends the attempt down the SHA-512 path where the length limit applies.

The OpenSSH commit 4353fdc, "avoid password authn bypass", says the maintainers do not consider the root cause to be within OpenSSH but are well placed to avoid it. It adds a MIN_PASSWORD_HASH_LEN of 4 in auth-passwd.c, so a stored hash must be at least four characters before a match is accepted, and changes how the fake password and shadow_pw() results are copied and freed in auth-passwd.c, xcrypt.c and port-uw.c. The release notes credit Özgün Kültekin of Wakefield with the report.

Patched packages

Alpine published fixed openssh packages for every branch it checked:

Alpine backported the workaround rather than moving every branch to 10.6p2. We did not find fix information for other musl distributions or embedded vendors in the sources reviewed.

What defenders should do

1. Upgrade and restart. On Alpine run apk upgrade -U -a, then rc-service sshd restart. The upgrade alone does not replace the running sshd.
2. If you cannot patch yet, set PasswordAuthentication no (for example in /etc/ssh/sshd_config.d/00-no-passwords.conf) and restart sshd. Confirm with sshd -T | grep -i passwordauthentication. Test key login in a second session before closing the first.
3. Check exposure: confirm sshd runs on musl, UsePAM is off, PasswordAuthentication is on, and some account in /etc/shadow has * as its password field. sshhole.com links a checker at github.com/oz9un/sshole, which we did not review.
4. Look for abuse. Alpine advises searching /var/log/messages for Accepted password for entries on accounts with no password such as alpine, root or key-only users, and reviewing doas use, new users, new files and changed authorized_keys. If a login cannot be ruled out, treat the machine as compromised.
5. Rebuild container images from a patched base and redeploy, since a running container keeps its old sshd.

The NVD entry was still marked "Received", not analyzed, as of 8 November 2026, and the CVSS score shown is the MITRE-supplied one.

Sources

• NVD record CVE-2026-123158
• OpenSSH commit 4353fdc
• OpenSSH release notes
• Alpine Linux advisory
• sshhole.com write-up
• sshhole-lab repository