A newly disclosed flaw in the way OpenSSH works with the musl C library can let attackers log in to Linux accounts that were set up to refuse password logins, simply by sending an oversized password. BleepingComputer and Tom's Hardware both reported it on November 5, and BleepingComputer says the fix is in OpenSSH 10.6p2.
This matters beyond server rooms. Alpine, the biggest concern here according to Tom's Hardware, could amount to millions of installs across containers, servers, cloud VMs and embedded devices, and it often arrives as a dependency of something else.
We couldn't check the original OpenSSH and musl advisories, or the researcher's own write-up, directly for this report, so every technical claim below is attributed to the two outlets. Neither report names a CVE for the new flaw.
Who is exposed
BleepingComputer credits security researcher Ozgun Kultekin, who it says found the issue and released details on November 5. It reports the flaw has existed since 2016, and that Kultekin found it using AI agents that ran about 17,600 authentication tests.
According to BleepingComputer, Kultekin says exploitation needs all of the following:
- OpenSSH running on a musl-based Linux system
- PAM authentication disabled, which BleepingComputer says is the default in Alpine's openssh-server package
- SSH password authentication enabled
- At least one account with an asterisk as its password hash
- Another account with a valid password hash
The two outlets word the preconditions differently, and we've followed BleepingComputer's more detailed list here. BleepingComputer names Alpine Linux, OpenWrt, Buildroot and Yocto as musl-based systems. Tom's Hardware adds Void Linux to the list where the bug is present, though not necessarily enabled, and notes that OpenWrt uses Dropbear by default, so its users would have had to install OpenSSH.
Systems using glibc, including Debian, Ubuntu and Fedora, are not vulnerable, BleepingComputer reports, and neither are systems using PAM authentication. It also says the flaw doesn't get attackers past accounts with valid password hashes. The risk sits with accounts that were locked with an asterisk.
One detail deserves attention. BleepingComputer says the researcher warns that Alpine's official AWS and Azure cloud images include an affected default "alpine" account with passwordless doas privileges, which could allow root access.
How it went wrong
The short version, per BleepingComputer: a 2016 OpenSSH patch for a username enumeration bug made the server run password hashing even for accounts with no usable hash. Separately, musl's crypt() function returns an asterisk when hashing fails, including for a password over its 256-byte limit. That result can then match the asterisk stored for a locked account.
Tom's Hardware says both projects have published advisories, that each seems to believe the other is at fault, and that from the outside the blame looks shared.
It also adds some perspective. Tom's Hardware says the vast majority of Alpine and similar installs aren't reachable from the internet, but that an attacker already inside a network, whether corporate, cloud, VPN or home lab, could still let themselves in.
What to do
BleepingComputer says Alpine administrators should run apk upgrade openssh. If you can't update right away, both outlets give the same mitigation: set PasswordAuthentication no in your SSH server configuration and restart the service.
To check for past abuse, BleepingComputer says Kultekin recommends looking through SSH authentication logs for password logins on accounts that shouldn't allow them. On Alpine, it gives grep "Accepted password" /var/log/messages to find those logins and grep '^alpine:' /etc/shadow to check the alpine account. An asterisk in that account's shadow entry alongside a successful password login could indicate exploitation. Neither report says attacks have been seen in the wild so far.
Mason's take: The uncomfortable lesson is that a fix for one small bug in 2016 quietly set up this one a decade later. Neither piece of code looks outrageous alone. They just disagreed about what an asterisk means, and that's the kind of gap that's easy to miss where two projects meet.
Reporting notes
