The OpenSSH flaw dubbed “*sshole” can let attackers log in to some Alpine Linux and other musl-based Linux accounts that are supposed to block password authentication, including key-only accounts, by sending an oversized password. OpenSSH released version 10.6p2 to block the issue, which the project rates as critical, and Alpine Linux told users to update openssh and restart sshd immediately.
Key Points
- The bug affects some OpenSSH servers on Linux systems that use the musl C library, including Alpine Linux, under specific login settings.
- An attacker who can reach the SSH service and knows a username can log in to some no-password or key-only accounts with a very long password.
- Some official Alpine tiny-cloud images can become vulnerable after a normal password hash is added to the machine, according to Alpine Linux.
- Systems that use glibc, non-Linux platforms, and servers that use PAM for password checks are not affected, according to the OpenSSH project.
- OpenSSH 10.6p2 and Alpine package updates are available, but administrators must restart sshd after updating.
Who is affected
The issue affects OpenSSH servers on Linux distributions that use the musl C library, including OpenWrt, Buildroot, and Yocto, when they use certain authentication settings.
Damien Miller of the OpenSSH project said non-Linux systems, Linux systems built on glibc, and systems that check passwords through PAM are not affected.
The Alpine Linux advisory said a server is affected when all of these conditions are true: it runs the Alpine openssh-server package built without PAM, or it runs openssh-server-pam with UsePAM no; PasswordAuthentication is yes, which is the OpenSSH default unless it was changed; the machine has an account whose password field is *; and at least one local account has a $5$ or $6$ password hash. The advisory said openssh-server-pam with UsePAM yes is not affected.
How the bug works
Security researcher Özgün Kültekin said the flaw has existed since 2016. It stems from how OpenSSH handles password verification errors on systems that use musl.
For $5$ and $6$ password hash types, musl’s crypt() function refuses passwords longer than 256 bytes and returns a single * to signal the error. If the target account’s stored field is also *, sshd can compare * to * and accept the login.
An attacker needs network access to the server, a valid account name, and a password between 257 and 1,024 bytes long. A password made of 300 repeated A characters could bypass authentication on a vulnerable system. The attack takes one connection, works every time, and needs no retries. It requires no exploit code.
Kültekin said he discovered the bug using AI agents that ran about 17,600 authentication tests across different OpenSSH configurations, malformed password hashes, and oversized passwords. His research was published on sshhole.com. The vulnerability is tracked as CVE-2026-123158 and lists a CVSS 3.1 base score of 8.1.
Risk on Alpine images
The Alpine Linux advisory said the official tiny-cloud qcow2, VHD, and AMI images from 3.18.11 through 3.24.3 ship an alpine user with a * password field and passwordless doas. The advisory said those images are safe on first boot, but they become exploitable as soon as any $6$ hash exists on the machine, such as when an administrator sets a console password or user-data adds a user with hashed_passwd.
In that state, the advisory said an attacker can get a shell as alpine and use doas to become root. That means a login bypass on a low-privilege account can become full system compromise on exposed machines.
Fix and checks
OpenSSH fixed the problem in version 10.6p2. The code change makes sshd refuse a match when the stored field is shorter than four characters, and the OpenSSH project described that as a workaround because the root cause is outside sshd.
Alpine Linux said users should update openssh now and restart sshd, because upgrading the package alone does not replace the running daemon. Alpine’s remediation steps are apk upgrade -U -a and then rc-service sshd restart; administrators can also update OpenSSH packages with apk upgrade openssh. The Alpine advisory said its stable-branch packages carry a patch for the same problem.
If an update cannot be installed yet, the Alpine Linux advisory said administrators should set PasswordAuthentication no in sshd configuration and restart sshd. The advisory said either updating to a fixed package or disabling password logins closes the hole.
For signs of compromise, Alpine Linux said administrators should check /var/log/messages for sshd entries showing Accepted password for an account that has no password, including alpine, root, or other key-only users.
The advisory said exposed systems should also be checked for doas use, new users, changed files, and new authorized keys, and any machine where a suspicious login cannot be ruled out should be treated as compromised.
About the Author
