An OpenSSH flaw that lets remote attackers log into passwordless accounts on Alpine Linux and other musl-based systems is being exploited, threat intelligence firm Previdian has warned.
The flaw (CVE-2026-123158), nicknamed sshole by Wakefield researcher Özgün Kültekin, was fixed in OpenSSH 10.6p2 on November 5.
“An attacker who can reach your SSH port can log in without knowing any password. It takes one connection, works every time, and needs no retries,” the Alpine Linux team wrote in its security advisory.
On Friday, Previdian founder Ryan Dewhurst revealed that the company’s sensors had picked up attacks against the bug, and that at least one of them got all the way in.
“Our first observed attempt arrived less than nine hours after CVE publication, and we’ve confirmed successful root access on a Previdian honeypot running real Alpine Linux and OpenSSH,” he told Help Net Security.
“The observed source IP, 89.116.89[.]18, used oversized passwords to bypass authentication and ran reconnaissance commands including id, uname and hostname through non-interactive SSH sessions,” Dewhurst said.
So far, the company has counted eight attempts, all from that single Japan-based address and all caught by one sensor.
Previdian has put the bug on its own list of known exploited vulnerabilities, while CISA has not included it in its KEV catalog.
In Dewhurst’s view, attackers are getting faster with the aid of AI. “This vulnerability was particularly trivial to exploit, which significantly shrunk that timeline.”
One character with two meanings
Kültekin, who found the flaw, put up a site explaining it in a casual, lowercase style.
“accounts that should never take a password at all (root, your key-only deploy user, ldap users, the default user on alpine’s aws and azure images) take any password longer than 256 characters,” he wrote. “yes, any password. yes. i know. yes.”
Kültekin traces the problem to old choices made in OpenSSH and musl, the C library Alpine is built on. Those accounts carry a “*” in place of a password hash in /etc/shadow.
In 2016, he recounts, to fix a timing issue that let attackers work out which usernames exist on a server (CVE-2016-6210), OpenSSH changed sshd so that it borrows another account’s salt and hashes the password anyway when an account has no usable hash.
Since 2012, musl’s crypt() function has refused SHA-256 and SHA-512 passwords longer than 256 bytes, and when it fails it returns “*”. That output matches the “*” stored for the passwordless account, and sshd lets the user in.
Kültekin built sshd in every combination he could think of and threw some 17,600 unusual login attempts at the builds. Only the musl build without PAM let in logins it should have refused. He did not do it alone, though. “oh did i say “i”? sorry. i had agent swarms. a lot of them. let’s not get into it,” he admitted.
Who is at risk
The flaw affects OpenSSH versions before 10.6p2 on Linux systems that use the musl C library and don’t check passwords through PAM. Alpine Linux builds its default openssh-server package that way, and Kültekin lists OpenWrt, Buildroot and Yocto among the other musl-based systems worth checking, along with “a lot of the docker images you’ve pulled.”
An attack needs password logins to be enabled, which is the OpenSSH default, along with an account that has only “*” in its password field and another local account that has a password hash. Key-only users created without a password and users pulled from a directory service through musl-nscd fit the description of the target account, SOCRadar notes.
Root has shipped with a “*” since around Alpine 3.16, though OpenSSH’s default PermitRootLogin setting keeps it out of reach unless an admin has changed it. “Indirect root access is the larger concern,” SOCRadar argued.
“on alpine’s official aws and azure images that’s the default alpine user, and it has passwordless doas. so it’s root,” Kültekin explained. SOCRadar lists the affected tiny-cloud images as versions 3.18.11 through 3.24.3.
Systems built on glibc (Debian, Ubuntu and Fedora among them), setups that go through PAM, Dropbear and OpenBSD are safe, the researcher confirms.
Patch and restart
OpenSSH 10.6p2 fixes the issue, and SOCRadar reports that Alpine pushed patched packages for every branch from 3.16 to edge the same day. The company also reminds admins that installing the update leaves the running sshd untouched, so the old binary keeps accepting connections until they restart the service.
Anyone running musl-based Linux without PAM should “stop reading and set PasswordAuthentication=no or disable SSH for these systems IMMEDIATELY,” OpenSSH developer Damien Miller urged on Mastodon.
To spot a break-in, SOCRadar recommends searching /var/log/messages for “Accepted password for” entries naming accounts that have no password, such as alpine, root or key-only users, and reviewing doas use, recently created users and authorized_keys files. If a login can’t be ruled out, the machine should be treated as compromised.
Proof-of-concept exploits for the flaw have been posted on GitHub, but Previdian cautions that they are unverified and could contain malware.
Subscribe to our breaking news e-mail alert to never miss out on the latest breaches, vulnerabilities and cybersecurity threats. Subscribe here!
