OpenSSH flaw: can a 300-letter password unlock Linux?

A flaw fixed in OpenSSH on November 5, 2026 let people log in over SSH with a password of 257 to 1,024 characters, on certain accounts. It only affects Linux systems built with the musl library and without PAM, like Alpine Linux.

Key takeaways

• The flaw is real: OpenSSH 10.6p2, released on November 5, works around it.
• It requires a precise combination: musl, sshd without PAM, password login allowed, and an account whose password is marked "*".
• Locked accounts (marked "!") are not affected, according to Alpine's advisory.
• The "ten years" figure picked up by the press doesn't appear in Alpine's advisory, which gives no start date.

Can a 300-letter password unlock any Linux system?

No. Most Linux servers use the glibc library and PAM, which aren't affected. Four conditions have to line up:

1. sshd compiled without PAM (Alpine's openssh-server package, or its PAM version with UsePAM no);
2. PasswordAuthentication yes, OpenSSH's default setting;
3. an account whose password field is *, like root in base Alpine images or a user who only logs in with a key;
4. at least one other local account with a password hashed as $5$ or $6$.

The bug was reported by researcher Özgün Kültekin, of the company Wakefield. The OpenSSH 10.6p2 release notes describe a "password authentication bypass" that affects some Linux systems without PAM, with a root cause outside sshd that the software can work around.

Why 257 characters changes everything

When you type a password, sshd runs it through the crypt() function and compares the result with the value stored for the account. With musl, if the password is longer than 256 bytes, crypt() computes nothing and just returns "". But "" is also the value stored for an account with no password. The two match, the comparison succeeds, and the door opens on the very first try.

Alpine's advisory adds a detail: sshd borrows the salt from another account when the stored field is too short to contain one, which explains condition number 4. The flaw's CVE entry gives it a score of 8.1 out of 10 on the CVSS severity scale.

What about the "ten years" in Numerama's headline?

Numerama, a French tech news site, ran a headline about a flaw left open "for ten years." Alpine's advisory only says that every version tested is affected, including the older 3.16 through 3.20, and doesn't say when the exposure began. So taking "ten years" literally is risky. Numerama also mentions "locked" accounts, while Alpine lists accounts marked "!" among those that aren't affected.

Our conclusion: the flaw is serious for the servers concerned, and the idea that 300 letters would unlock any Linux server is false. Alpine containers that don't run sshd aren't affected either.

What should you do if your server runs Alpine?

Update the package with apk upgrade -U -a, then restart sshd with rc-service sshd restart: the update alone doesn't restart the program that's already running. If you can't update right away, set PasswordAuthentication no in the configuration and restart sshd, keeping a session open to test your key login. Alpine also recommends searching /var/log/messages for "Accepted password for" lines for accounts that have no password.

It's the same kind of problem as the supermarket fridges hacked in early November: an ordinary entry point, left open by default. The fixed Alpine versions range from 3.21.10 to 3.24.4 depending on the branch.