A single asterisk in /etc/shadow tells Linux that an account takes no password at all. For about a decade, on one branch of the Linux family, it told attackers something very different. Researchers disclosed an OpenSSH vulnerability on November 5 that opens locked accounts to anyone typing a password longer than 256 bytes. No key, no credential and no prior access required.
How a 256-byte password opens a locked door
This OpenSSH vulnerability lives in the gap between two programs that each behave sensibly alone. Linux keeps password hashes in /etc/shadow, and an account that should refuse passwords gets a lone asterisk instead of a hash. No real hash can produce that value. So the login should fail, every time.
The musl C library changes that in one narrow case. Alpine and its relatives use musl instead of glibc, and its crypt() function caps passwords at 256 bytes. Go past the limit and crypt() returns the string “*” to flag the error. OpenSSH compares that asterisk against the one stored for the account, sees a match, and opens a shell.
Any password between 257 and 1,024 characters does the job. The bar is absurdly low. There is no exploit chain to build and no tool to download, so someone leaning on a keyboard could trip over a root shell by accident.
Where this OpenSSH vulnerability actually bites
Most of the internet is safe, because the preconditions are narrow. This OpenSSH vulnerability only reaches systems built on musl: Alpine Linux, OpenWrt, Buildroot and Yocto. Debian, Ubuntu, Red Hat and every other glibc distribution stay clear, as do macOS, the BSDs and any server that authenticates through PAM.
Three further conditions have to line up before anything happens. The SSH server must run without PAM, password logins must be switched on, and the target account must carry an asterisk rather than the exclamation mark that marks a properly locked account. Alpine’s default openssh-server package ticks the first two out of the box. One other account also needs a genuine hash.
Nothing here touches an account with a real password hash. The OpenSSH vulnerability cannot crack a hash or guess a credential, so a server where every user holds a proper password sees nothing strange. All the risk lands on accounts locked down to key-only access.
Why containers turn a narrow bug into a wide problem
Alpine earned its reputation by being small, fast and heavily stripped down. A base image of a few megabytes keeps builds quick, which is why it anchors a vast number of public Docker images. That popularity stretches a musl-specific OpenSSH vulnerability well past a niche distribution.
Alpine cloud images sharpen the problem a good deal further. The default cloud user and the root account both ship with an asterisk in the password field, set up for SSH keys and nothing else. Admins who built those machines assumed password logins were off, and on an unpatched host facing the internet that assumption fell apart.
Container images that bundle openssh-server make the cleanup noticeably messier. Patching the host does nothing for an image built months ago with the vulnerable package still inside. Those images need rebuilding.
Patching the OpenSSH vulnerability
OpenSSH 10.6p2 shipped on November 5 and closes the hole by rejecting stored hashes shorter than four characters. Alpine backported packages across every supported branch, from 3.16 up to edge. About a day passed between the report and the release.
Plenty of admins will finish the upgrade and still leave a vulnerable process running, because installing a package does not restart sshd. The old binary keeps serving connections until somebody restarts the service. Run the upgrade, restart sshd, then confirm the running version with apk info -v openssh-server.
If you cannot patch right away
Setting PasswordAuthentication to no in sshd_config shuts down the attack path completely, with no patching required. On servers already running on keys, which covers most Alpine deployments, the change costs nothing. Machines that never needed remote access can simply drop SSH.
Signs that somebody already walked in
Admins who want to rule out past abuse of the OpenSSH vulnerability should start with the authentication logs. On Alpine, grep “Accepted password” /var/log/messages pulls up every successful password login. Any hit on an account that should refuse passwords needs a look straight away. Nobody had reported real-world exploitation at disclosure.
Keeping SSH off the open internet
All of these conditions matter far less when the SSH port cannot be reached from outside. Running sshd behind a VPN or a private network forces an attacker through that layer first, long before any OpenSSH vulnerability matters. Many teams expose port 22 for convenience and lean on key authentication alone. A gap in that barrier leaves nothing between a scanner and a shell.
Defense in depth helps here as plainly as anywhere else. A VPN gateway, an allowlist of source addresses or a bastion host each shrink what a casual scan can reach. None of that replaces patching, but it buys time during the window between disclosure and rollout.
Final Thoughts
Ten years is a long run for a flaw to survive in software this heavily audited, and the reason is almost boring. Neither project did anything clearly wrong on its own. The failure showed up only where the two met, in a corner case nobody thought to test.
Fixes are out, the conditions are narrow, and most servers were never exposed, but the machines that were exposed tend to be the ones humming along in production with nobody watching them. Patch the OpenSSH vulnerability, restart the service, rebuild your Alpine images, and read your logs while you are in there. A decade-old bug has earned an afternoon of attention.
