Long passwords unlock disabled accounts

On a musl-based Linux box, an account whose /etc/shadow password field is set to * is supposed to reject every password. Ozgun Kultekin showed that, with the right configuration in place, sending one longer than 256 bytes logs you straight in. He calls the bug “*sshole,” and it reaches OpenSSH servers on the musl C library, including Alpine Linux, OpenWrt, Buildroot, and Yocto, in certain authentication configurations. It has been exploitable since 2016.

Two sensible changes collide to produce it. Setting a password hash to * is the standard way to disable password login for an account, since * is not a valid hash and nothing should ever match it. Separately, OpenSSH was patched in 2016 to close CVE-2016-6210, a username enumeration flaw. Before that fix, OpenSSH skipped password hashing for accounts with no usable hash, so an attacker could tell real usernames from fake ones by response time. The fix forced OpenSSH to hash the submitted password regardless, including for accounts whose stored hash is *, so the timing gives nothing away.

On glibc that is harmless, because the computed hash never equals *. musl breaks the assumption: its crypt() returns * when hashing fails, and it fails when the submitted password is over its 256-byte limit. OpenSSH compares that returned * against the stored *, finds a match, and grants access. Accounts with real password hashes stay safe; the oversized string only produces a match against the literal *.

Exploitation needs a specific lineup:

• OpenSSH on a musl-based system (Alpine, OpenWrt, Buildroot, Yocto).
• PAM authentication disabled, which is the default in Alpine’s openssh-server package.
• SSH password authentication enabled.
• At least one account with * as its password hash.
• Another account with a valid password hash.

That lineup ships ready-made in places. Alpine’s official AWS and Azure cloud images carry a default alpine account matching the pattern, with passwordless doas, so an attacker who walks through the hole lands with a clear path to root.

Systems on glibc, which covers Debian, Ubuntu, and Fedora, are not affected, and neither is anything using PAM.

Kultekin found the bug by pointing AI agents at it; they ran roughly 17,600 authentication attempts across different OpenSSH configurations, malformed hashes, and oversized passwords until the *-versus-* match surfaced.

The fix is in OpenSSH 10.6p2. On Alpine, apk upgrade openssh pulls it. If you cannot patch immediately, set PasswordAuthentication no in the SSH server config and restart the service, which removes the only path the attack uses.

For anyone who ran an exposed musl host, check whether it was already hit. On Alpine, successful password logins show up with:

grep "Accepted password" /var/log/messages

If the alpine account appears there, confirm whether it is even meant to accept passwords:

grep '^alpine:' /etc/shadow

A * in that password field alongside an “Accepted password” entry for the same account could indicate that the vulnerability was exploited.