A bug in how OpenSSH checks passwords on Linux systems built with the musl C library lets an attacker log into accounts that are supposed to refuse passwords entirely, just by sending one longer than 256 bytes.
Alpine Linux warned in its advisory that anyone who can reach a vulnerable server's SSH port can break in on a single connection, with no retries needed. Fixes have shipped in OpenSSH 10.6p2 and in new Alpine point releases.
The flaw, nicknamed *sshole and tracked as CVE-2026-123158, was disclosed by security researcher Ozgun Kultekin, who said it has existed since 2016. He said AI agents helped him find it by running roughly 17,600 authentication tests across OpenSSH configurations, malformed password hashes and oversized passwords.
A single asterisk
Administrators often block password logins for an account by putting an asterisk where its hash would normally sit in /etc/shadow. Since an asterisk is not a valid hash, no password should ever match it.
A 2016 OpenSSH patch, written to stop attackers from identifying real usernames by measuring response times, made the server hash every attempt, even for accounts with no usable hash. On musl, the crypt() function signals failure, including input past its 256-byte limit, by returning an asterisk. OpenSSH then compares that against the stored asterisk and lets the attacker in.
Systems built on glibc, which covers nearly every Linux distribution including Debian, Ubuntu and Fedora, are not affected because that library returns NULL on error, a result sshd already rejects. Servers that authenticate through PAM are also safe.
Exposure requires OpenSSH running without PAM and with password authentication turned on. An attacker needs the name of a passwordless account plus at least one other account on the machine with a real password hash; Alpine said a single user with a password exposes every passwordless account.
Beyond Alpine, musl-based systems named as potentially vulnerable include OpenWrt, Buildroot, the Yocto Project, Adélie Linux, Void Linux and Sabotage Linux. Wind River, maker of the commercial embedded Wind River Linux, said it is reviewing the issue.
Cloud images at risk
Alpine found the problem in every release it examined: the current 3.21-to-3.24 lines, the older branches going back to 3.16, and its edge development tree.
Its official tiny-cloud images, versions 3.18.11 through 3.24.3, carry the most risk. They ship with an alpine account that has an asterisk for a password and passwordless doas rights, giving an intruder a path to root; Kultekin flagged the AWS and Azure images specifically. Those images are safe at first boot but become exploitable once a hashed password lands on the machine, such as when an administrator sets a console password.
The root account itself is generally shielded, since OpenSSH's default PermitRootLogin setting of prohibit-password blocks the trick. Any other account able to escalate, for instance through doas, still opens a route.
Patching and checking logs
Alpine released versions 3.21.10, 3.22.8, 3.23.8 and 3.24.4 on Thursday and published fixed packages for releases back to 3.16. It told users to run apk upgrade -U -a and then restart sshd, cautioning that upgrading the package does not replace a daemon that is already running.
Administrators who cannot update right away can set PasswordAuthentication to no and restart the SSH server, after first making sure key-based logins work.
If you cannot rule out a login, treat the machine as compromised.
Alpine Linux security advisory
To hunt for intrusions, Alpine advised searching /var/log/messages for accepted password logins on accounts that have no password, and reviewing doas activity along with newly created users, files and authorized keys.
