OpenSSH and musl-libc Flaw Opens Alpine Linux to Any 257-Character Password

Typing any string longer than 256 characters at the SSH password prompt logs an attacker into an unpatched Alpine Linux system. That single concrete failure mode — confirmed in emergency advisories from both OpenSSH and musl-libc — puts millions of Docker, Kubernetes, Proxmox, cloud VM and embedded installs at risk today.

The bug chain targets a specific configuration: OpenSSH paired with musl libc, password authentication not explicitly disabled, no PAM, and a user account using a SHA-512/256 password hash. Alpine ships with those conditions set and password authentication enabled by default, which is why the project's advisory tells administrators to patch immediately.

How does the attack actually work?

The mechanics sit in two pieces of code that each misbehave. In /etc/passwd and /etc/shadow, accounts without passwords carry a single asterisk as the hash placeholder — shorthand for "no password should work." When musl's crypt() function hits an error, it returns "*" instead of the null value convention demands.

OpenSSH then takes that asterisk and compares it against a submitted password hash, something it shouldn't do at all. An overly long input — anything past 256 characters — triggers the chain of mistakes, and the door opens. The SSHhole website documents the full technical detail.

Both upstreams have shipped fixes. OpenSSH published a patch and advisory, as did musl author Rich Felker. Each side considers the other at fault. Viewed from outside, the blame appears shared.

Who is exposed?

The exposure list runs wide:

• Alpine Linux — the primary concern, as the default choice for potentially millions of installs spanning containers, servers, cloud VMs and embedded devices
• Buildroot, Yocto and Void Linux — the bug is present, though not necessarily enabled
• OpenWRT — uses Dropbear for authentication by default, but users can install OpenSSH

The practical attack surface looks narrower than the install base suggests. The vast majority of Alpine and similar installs aren't reachable from the internet. But any attacker already inside a network — corporate setups, home labs, cloud networks, VPNs — can let themselves in. The attack needs only one valid user account with an empty password, not a hard thing to find in a large corporate environment. Scanning and testing for the vulnerability is trivial, which raises the odds of opportunistic sweeps.

What should administrators do now?

Patch immediately, per the project's advisory note. For teams that can't deploy fixes right away, one configuration change closes the hole: explicitly set PasswordAuthentication to no in the OpenSSH configuration file and restart the service.

The timing stings. The disclosure lands while the industry is still reeling from the PHP engine vulnerability and a string of other security issues surfacing over the past few weeks, stretching incident-response teams thin across unrelated fronts.

With fixes now available upstream and finger-pointing still unresolved between the two projects, the next few weeks will show how quickly the container and embedded ecosystems absorb the patches — and whether anyone built scanning tooling for the 256-character knock before the maintainers did.