A Password Between 257 and 1,024 Bytes Logs You Into Alpine Linux Accounts That Have No Password. There Is No CVE Yet and No Attacks Are Reported. One Config Line Closes It.
If you run Alpine Linux with sshd, patch it today and check one setting. The Hacker News reports that OpenSSH shipped an emergency fix for a flaw that lets an attacker log in to any account with no password, including key-only accounts, by sending a password between 257 and 1,024 bytes long. No CVE had been assigned when it was reported, and the report says no attacks using it have been seen. The advisory says it works on every try with a single connection.
How it works
The report ties the flaw to how sshd uses the musl C library, which Alpine ships instead of glibc. For passwords hashed with the $5$ or $6$ schemes, musl's crypt() returns a lone asterisk when the password is longer than 256 bytes. An account with no password stores an asterisk too, so the two match and the login succeeds. According to the advisory as reported, sshd borrows the salt of another account that has a real hash, which is why the attack needs at least one such account on the machine.
The reported requirements are short: network access to sshd, the name of an account that has no password, and one other account with a $5$ or $6$ hash. Key-only accounts and the default alpine or root accounts are the kind of target it names.
Who is affected
Per the report, this is Alpine's openssh-server package built without PAM, or openssh-server-pam with UsePAM no. The reporter, Özgün Kültekin of Wakefield, also says other musl-based systems are worth checking: OpenWrt, Buildroot and Yocto.
Not affected, per the report: non-Linux systems, glibc-based Linux, systems that check passwords through PAM, Dropbear on OpenWrt, and cloud-init images that set PasswordAuthentication no.
What to do now
- Update and restart. The report says to run apk upgrade -U -a and then rc-service sshd restart. The fix is OpenSSH 10.6p2. Alpine's fixed point releases are 3.21.10, 3.22.8, 3.23.8 and 3.24.4, and branches 3.16 through 3.21 also received fixed packages.
- Or turn passwords off. Set PasswordAuthentication no in the sshd config, check it with sshd -t, restart sshd, and confirm with sshd -T. Keep an existing session open and confirm key login works before you close it.
- If you cannot patch, this setting is the stopgap the report describes. It does not need the new package.
How to check whether someone got in
The advisory, as reported, points to /var/log/messages. Look for sshd lines reading "Accepted password for" that name accounts which should have no password, such as alpine, root or key-only users. Also review doas use, recently created users and files, and authorized_keys. The advisory's own guidance, as quoted, is that if you cannot rule out a login, you should treat the machine as compromised.
What is not known
The CVE identifier, once assigned. The affected OpenSSH version range, which the report does not give. Whether anyone is exploiting it. Whether other musl-based distributions beyond the ones named are affected. No indicators of compromise were published beyond the log pattern above, so there is nothing for us to add to the feed from this story.
Limits
One secondary report from The Hacker News, summarizing an advisory. We did not read the OpenSSH or Alpine advisories ourselves, did not test the flaw, and did not check any system. The version numbers, commands and log paths are as reported. Our own containers are built on Debian, not Alpine, so we are not affected on that front, but we have not audited every machine we run.
Five percent of this is wrong somewhere. It always is. The advisory text will correct a version number or a detail about which builds are exposed.
Was this useful? Rate this post. The widget is at the bottom of the page, and we read every response.
Every indicator in this post is in the feed. Free.
1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.