Any password over 256 characters opened locked accounts on Alpine. A NULL license plate explains why.

On 5 November 2026 OpenSSH released version 10.6p2 and Alpine Linux published an advisory for a bug that sounds like a joke: on some systems, any password longer than 256 characters logs you in to accounts that are not supposed to accept a password at all. It needs four things together: OpenSSH built against the musl C library without PAM (Alpine's openssh-server package), password logins left on (the default), an account whose password field is *, such as root or a key-only user, and one other local account with a real SHA-256 or SHA-512 password hash. The fix is OpenSSH 10.6p2 or Alpine's patched packages, then a restart of sshd, or PasswordAuthentication no. The cause is two meanings sharing one character.

How can a long password open a locked account?

In the shadow password file, a * means no password will ever match, because it is not a valid hash. Without PAM, sshd checks a password itself: it runs what you typed through the C library's crypt() with the stored salt and compares the result with the stored field. A * has no salt in it, so sshd borrows one from another account on the machine. According to the researcher's write-up, that borrowing goes back to a 2016 OpenSSH change made to stop attackers from telling real usernames from fake ones by timing.

Then musl's crypt() hits a limit. musl caps SHA-crypt passwords at 256 bytes, a guard against denial of service, and fails on anything longer. Its failure value, in the words of its own source comment as quoted on sshhole: "on error "*" is returned." So sshd hashes your 300-character password, gets back *, compares it with the stored *, and they match. The door's "locked" sign and the library's "something went wrong" sign are the same character.

Who got it wrong?

My first reaction was that musl broke the rules. The POSIX specification for crypt() says that on failure "it shall return a null pointer and set errno". musl chose in 2012 to return a string instead. But that was a safety choice, not carelessness: a program that forgets to check for a null pointer can crash or worse, and a string that can't match any hash looked safer. sshhole notes that a 2013 Debian bug asked glibc to do the same. It was closed after the move to libxcrypt, which returns *0.

Then look at the other pieces. OpenSSH's salt borrowing was a fix for a real enumeration bug. Alpine changed root's password field from ! to * in 2022 so that key logins kept working without PAM, with a commit message saying it "still forbids password login". The OpenSSH maintainers wrote in the 10.6p2 release notes that they consider "the root cause of this bug to be outside sshd". Every step was reasonable on its own. The bug lives in the space between them, which is why the researcher's test of about 17,600 logins across builds found that "every build agreed on every login. except musl without pam."

What does a license plate have to do with it?

In late 2016 a security researcher named Joseph Tartaro picked a vanity plate in California: NULL. At DEF CON in 2019 he explained what followed, as The Drive reported. A privately run citation processing centre kept tickets with missing plate details under "NULL". Its system could not tell those apart from his plate, so it sent them to him, more than $12,000 worth. "Instead, I got all the tickets," he told the audience.

The shape is identical. A system needed a way to say "nothing here" and wrote it in the same alphabet as real values.

As long as no real value equalled the marker, nothing happened. The moment one did, whoever held it received everything addressed to nothing.

On the plate it was a person. In sshd it was any attacker who could type 257 characters.

That is also why I'm wary of calling libxcrypt's *0 the fix. It is safer today because no stored field is *0. It is still a value. The only marker that can't collide is one that lives outside the data, which is what POSIX's null pointer was trying to be. It reminds me of the certificate keys that could be guessed in 256 tries: a small assumption nobody wrote down, sitting between components that each passed their own review.

What should you do now?

Update OpenSSH with apk upgrade -U -a and restart sshd, because the upgrade does not restart a running daemon. If you can't update yet, set PasswordAuthentication no after confirming key login works. Alpine says official tiny-cloud images from 3.18.11 through 3.24.3 ship an alpine user with a * password and passwordless doas, so those need checking instance by instance. And look in /var/log/messages for "Accepted password for" on accounts that have no password. Alpine's advice is to treat the machine as compromised if you can't rule a login out. Nobody knows yet whether this was used before 5 November. The researcher's own line is "as far as anyone knows, nobody noticed."

If this is your stack, the PHP end-of-life piece asks a related question: who carries the fix for the versions nobody maintains.

More on Daily Ferment: NIST's curve seeds were timestamps. No record said so. and The HFS bug was public for 11 weeks. The write-up got it exploited in a day.

Sources

• Alpine Linux, openssh-server password authentication bypass, 5 Nov 2026
• OpenSSH 10.6p2 release notes, 5 Nov 2026
• sshhole, Özgün Kültekin, Wakefield, November 2026
• crypt(), The Open Group Base Specifications Issue 8, IEEE Std 1003.1-2024
• California man's plot to avoid tickets with NULL vanity plate nets him $12K in fines, The Drive, 13 Aug 2019
• Vanity license plates have proven traffic ticket systems faulty for four decades, SlashGear, 15 Aug 2019
• How a NULL license plate landed one hacker in ticket hell, WIRED via IOActive, 13 Aug 2019