OpenSSH 10.6p2 Patched a Password Bypass on musl Systems. If Your Containers Run Alpine With Password Logins On, Here Is the Two-Minute Check.
OpenSSH 10.6p2, dated November 5, 2026, carries what its release notes call a critical security workaround for Linux systems that use the musl C library with PAM disabled. If you run a small VPS or a Docker image based on Alpine and you left SSH password logins on, this one is worth two minutes today.
What the bug is
The finder, Özgün Kültekin of Wakefield, published a write-up at sshhole.com. According to it, musl's SHA-512 password hashing refuses keys longer than 256 bytes and signals the failure by returning an asterisk. An account locked with * in /etc/shadow stores that same asterisk. When sshd compares the two, a long enough password can "match". The write-up says the practical window is passwords between 257 and 1024 characters.
The conditions are narrow. Per the write-up you need musl, an sshd built without PAM (Alpine's default), password authentication enabled, and a target account whose shadow entry is exactly *, which is how key-only users and root are often set up. The write-up's checklist also needs some other account with a real password, because sshd borrows material from it when checking a locked account. It names the default alpine user on Alpine's AWS and Azure images, which can become root through passwordless doas.
What OpenSSH did
The 10.6p2 notes say the team considers the root cause to be outside sshd, but exploitable through it and avoidable there, so the workaround lives in sshd. The notes list no CVE number. I looked, and I did not find one in either the release notes or the write-up, so if you are tracking this in a scanner, expect it to show up late.
How reachable is it really
This is where I would slow down before panicking. A commenter on the Hacker News thread reported being unable to reproduce it on the official Alpine Docker image with OpenSSH 10.3p1, trying both ! and * and a password over 256 characters. Others argued the chain is technically possible and practically unlikely. I have not reproduced it myself, and those comments are anecdotes, not a refutation. The OpenSSH team calling the workaround critical is the stronger signal than either camp on a forum.
The other thing worth noticing is the history. The write-up traces the sshd side of the chain to a 2016 change and says Alpine switched root's shadow entry to * in version 3.16. A bug that took years to line up is exactly the kind a one-person shop never hears about, because nobody on your team reads release notes for a living.
What I'd actually do
First, find out whether I am even exposed. On each box I run: is it musl, is sshd built without PAM, is PasswordAuthentication on. If the answer to the third is no, I am done. Most of my servers should already be key-only, and I would rather confirm that than assume it.
Second, turn passwords off everywhere that does not need them. The write-up's interim fix for Alpine is a drop-in file, /etc/ssh/sshd_config.d/00-no-passwords.conf, containing PasswordAuthentication no, followed by a restart of sshd. That closes the path regardless of what is in the shadow file.
Third, upgrade. The write-up says apk upgrade openssh picks up 10.6p2, though I could not confirm the exact Alpine package version, so check what your mirror ships. For container images, rebuild and redeploy rather than patching a running container.
Where this argument could be wrong
If your images never expose port 22, none of this matters, and spending an afternoon on it would be wasted. Plenty of containers should not run sshd at all, and the cheapest fix for those is deleting it. I would still run the check, because "I never expose SSH" is a claim people tend to believe right up to the moment a debugging shortcut leaves it open.
Author
Lukas
@lukcombinator