OpenSSH Rushes Out a Fix for a Password Bypass on Alpine and Other musl Linux Systems

Who Is Affected

According to the write-up by Özgün Kültekin of Wakefield, who found the flaw, a machine is open when all of this is true:

• sshd runs on musl. Alpine is the main case. Embedded Linux built with Buildroot or Yocto, and OpenWrt devices that run OpenSSH, can use musl too.
• sshd checks passwords itself. Alpine’s standard openssh-server package is built without PAM. A build with PAM support counts too if UsePAM no is set, Miller confirmed.
• Password logins are on. OpenSSH’s default for PasswordAuthentication is yes.
• An account has only * in its password field in /etc/shadow. That is the usual way to say “no password login for this account”: key-only users, LDAP users and, since Alpine 3.16, root.
• Another account has a real password.

Then the * account takes any password between 257 and 1,024 characters.

Alpine’s official AWS and Azure images make the stakes higher. Their setup tool, Tiny Cloud, creates the default user alpine with * as its password and lets it use doas without a password. On such a server, once any account has a real password, a long enough password gets an attacker in as alpine, and from there to root. Root itself is safer by default, because OpenSSH doesn’t accept passwords for root unless PermitRootLogin was changed.

Containers built on Alpine are exposed only if they run sshd. The ones that do have to be rebuilt so they pick up the fixed package.

Not affected, according to Miller and the write-up: non-Linux systems such as OpenBSD, Linux systems with glibc (Debian, Ubuntu, Fedora and most other big distributions), and systems where PAM handles password logins. Dropbear, the small SSH server that many routers and embedded devices use instead of OpenSSH, is not affected either. Alpine maintainer Natanael Copa checked Dropbear’s source code, and musl’s maintainer Rich Felker said the same. OpenWrt routers run Dropbear out of the box. If you replaced it with OpenSSH, the fixed version has been submitted to OpenWrt’s package feed.

What to Do Now

On Alpine, update and restart the SSH server: apk update && apk upgrade, then rc-service sshd restart. Fixed packages are already in Alpine’s repositories for every current release.

If you can’t update right away:

• Turn off password logins. Set PasswordAuthentication no in /etc/ssh/sshd_config and check any Match blocks, which can switch it back on for some users or addresses. Make sure your own key login works first, or you could lock yourself out. Then restart sshd and confirm the setting with sshd -T | grep -i passwordauthentication.
• Or close the door. Stop sshd, or allow SSH only from addresses you trust in your firewall or your cloud provider’s security group.

Then check whether someone already used it. Search the log for password logins with grep "Accepted password" /var/log/messages (Alpine’s default log file). For each account name you find, look up its line in /etc/shadow, for example grep '^alpine:' /etc/shadow. If the second field is only *, that account has no password and should never have logged in with one. Treat the machine as compromised.

If you already log in with SSH keys, turning password logins off costs you nothing. On a server that faces the internet, keys were the better choice before today as well.

How the Bug Works

Three decisions, each reasonable on its own, made the bug.

In August 2012, musl changed its crypt() function, which hashes passwords, to return an unmatchable value instead of NULL when hashing fails, because many programs never checked for NULL and crashed. The value it returns is *. Twenty days later, musl’s SHA-512 hashing got a 256-byte limit on passwords, to stop very long passwords from tying up the server. Past that limit, hashing fails, and the answer is again *.

In 2016, OpenSSH fixed a timing leak (CVE-2016-6210) that told attackers which usernames exist. When there is no real hash to check a password against, sshd now borrows another account’s salt and hashes the password anyway, so every “no” takes the same time. An account whose field is just * takes that path too.

Put together: you try to log in as a * account with a 300-character password. sshd hashes it with another account’s SHA-512 salt, musl gives up at 256 bytes and returns *, and sshd compares * with *. They match. The 10.6p2 workaround makes sshd refuse a match when the stored value is shorter than four characters.

Both projects have said the root cause is not theirs. OpenSSH says it lies “outside OpenSSH itself”; Felker wrote that “it is not a musl vulnerability.” Kültekin’s explanation for why it went unnoticed for ten years is simpler: OpenSSH is tested on OpenBSD and glibc, musl doesn’t test sshd, and most distributions go through PAM, which never calls crypt() for a * account. Each part works as designed. Together, a star matches a star.

He found it by building sshd in every combination he could think of (glibc, musl, PAM, no PAM) and throwing about 17,600 unusual logins at it, with what he calls “agent swarms”. At the time of writing, no CVE number has been assigned. Alpine applied the fix to every branch back to 3.16, which came out in May 2022.

Why OpenSSH Didn't Wait

Serious flaws are normally fixed quietly first. Distributions get the patch under embargo, and the public hears about it once packages are ready. The distros mailing list, where Linux distributions get advance notice, allows embargoes of up to 14 days. This time, the gap between the report and the public release was about a day. Alpine committed its fixed packages between 06:53 and 09:05 UTC, around the time of Miller’s post.

The reason is AI. In the release notes, the OpenSSH team says it has received “a large number of security bug reports, many of which are findings from AI models”, and has seen bugs found by AI tools discovered again by other researchers. “This suggests that adversaries who do not report bugs to OSS projects are likely to be able to discover these bugs too.” Miller’s post is blunter. AI agents have rediscovered bugs “sometimes within hours”, so OpenSSH now considers long embargoes “a dangerous practice that primarily benefits attackers”. The project will ship fixes in more frequent releases instead of saving them for the next planned one. This bug was itself found with AI agents, which is exactly the worry.

For admins, this means less notice and more patch days. An embargo only works while the other side doesn’t know, and the other side now has the same tools.