An attacker who can reach the SSH port on some Linux servers can log in to an account that has no password at all by typing a password longer than 256 bytes. OpenSSH released version 10.6p2 on Thursday with what its developers call a critical security workaround for the flaw. It hits Linux systems built on the musl C library that check passwords without PAM, and Alpine Linux, a lightweight, security-focused distribution built on musl, is the main one.
According to Alpine's security advisory, one connection is enough, and the attack works every time. The attacker needs only the name of an account with no password set. Any password from 257 to 1,024 bytes works. The flaw is tracked as CVE-2026-123158, rated 8.1 out of 10 (high). CISA's assessment in that record says a public proof of concept exists and the technical impact is total. Neither advisory reports attacks so far.
How a long password gets in
Accounts meant to log in only with an SSH key usually have a single asterisk, *, where a password hash would be. No typed password can produce that, so password logins to the account always fail. When sshd runs without PAM, it checks a password itself: it hashes what the user typed with the C library's crypt() function and compares the result to the stored field. For an account with no real hash, sshd borrows the salt from another account on the machine. That behavior dates from a 2016 fix that stopped attackers from timing logins to learn which usernames exist.
The researcher who found the bug traced the rest to musl's crypt(). Since 2012 it has returned when it fails instead of returning nothing, and it refuses passwords over 256 bytes. Send a long enough password and crypt() fails and returns . That matches the stored *, and sshd lets the attacker in. Özgün Kültekin of Wakefield reported it, and the write-up names the bug "sshole." It describes building sshd with every mix of libraries the researcher could think of and throwing about 17,600 unusual logins at each build with help from AI agents. Only the musl build without PAM accepted logins it should have refused.
OpenSSH says the root cause sits outside sshd. The fix went into sshd anyway, since that is where the bug can be exploited.
Which machines are exposed
Alpine lists these conditions, and all of them must hold:
- The server runs Alpine's openssh-server package, which Alpine compiles without PAM, or the PAM version with
UsePAM no. - Password logins are on, which is the OpenSSH default.
- At least one account has
*as its password field, such as a key-only user, a user from a directory service, or root, which ships that way since Alpine 3.16. - At least one other local account has a real password hash.
Root itself is protected by OpenSSH's default setting that blocks password logins for root unless an admin has changed it, but that protection does not help when another account on the machine can become root, for example through doas. The official Alpine cloud images for AWS, Azure and other platforms, from 3.18.11 through 3.24.3, include an alpine user with no password and passwordless doas. A fresh instance is not exposed, but once any account gets a password, for example a console password set by an admin, an attacker can log in as alpine and become root.
Docker containers that do not run sshd are not affected, and neither are cloud images set up through cloud-init, which turns password logins off. Debian, Ubuntu, Fedora and other systems built on the glibc library are fine, as are servers that check passwords through PAM, according to the researcher.
What to do now
Alpine has published fixed packages for every release back to 3.16, though 3.21 and older no longer get regular updates. Run apk upgrade -U -a. Then restart the SSH service with rc-service sshd restart, because upgrading the package does not replace the copy of sshd that is already running. The new Alpine point releases include the fix.
| Alpine branch | Fixed openssh package |
|---|---|
| edge | 10.6_p2-r0 |
| 3.24 | 10.3_p1-r2 |
| 3.23 | 10.2_p1-r1 |
| 3.22 | 10.0_p1-r11 |
| 3.21 | 9.9_p2-r1 |
| 3.20 | 9.7_p1-r6 |
| 3.19 | 9.6_p1-r3 |
| 3.18 | 9.3_p2-r4 |
| 3.17 | 9.1_p1-r7 |
| 3.16 | 9.0_p1-r6 |
If you cannot update yet, turn password logins off. Setting PasswordAuthentication no in the sshd configuration closes the hole. Confirm that your key login works first, and keep the current session open until a new login succeeds.
To check for a break-in, Alpine says to search /var/log/messages for sshd lines reading "Accepted password for" an account that has no password, such as alpine or root. Review doas use, new users, new files and authorized keys. When a login can't be ruled out, Alpine advises treating the machine as compromised.
Why OpenSSH is shipping fixes faster
The release notes say the project has received a large number of security reports recently, many found by AI models or with AI help. The team has seen bugs found with AI tools later turn up independently from other researchers, which suggests attackers who never report bugs can find them too. For now, OpenSSH says, it will put out releases more often instead of saving fixes for the next planned version.
