Attackers have started sending the overlong passwords that trigger “sshole”, an OpenSSH login bypass affecting Linux systems built on the musl C library, which includes Alpine Linux and many container images. The fix has been out since 5 November, so anyone running an SSH server on Alpine or a similar system should check that it has been applied and restarted.
The flaw, tracked as CVE-2026-123158, lets an unauthenticated visitor log in to an account that has no password at all, as long as a few conditions line up. Researcher Özgün Kültekin disclosed it on 5 November. The OpenSSH project answered with version 10.6p2 on that date, and Alpine pushed updated packages for all of its releases from 3.16 up, even the end-of-life ones.
SANS Internet Storm Center researcher Johannes Ullrich says his Cowrie honeypots recorded 232 long-password requests on 5 November and 713 on 6 November, many of them passwords made of repeated letter A. Those are counts of suspicious requests, not of confirmed break-ins. Earlier long-password traffic from 1 November looked to him like broken brute-force scripts, and although he suspected some honeypot logins succeeded, that is not confirmed. Cowrie also keeps only the first 255 characters of a password, which hides the length of the longest attempts.
The cause is a collision of three old design choices, which security firm StepSecurity reproduced in a lab on Alpine. Musl’s crypt() function signals failure by returning the string ““, and any password over 256 bytes makes it fail. Many systems store “” in the password field to mean that an account can never log in with a password. OpenSSH, on the path where it checks passwords itself without PAM, compares the two, sees a match, and lets the visitor in. Working attempts need a password between 257 and 1,024 bytes long.
Exposure is narrower than the headline suggests. A server is only vulnerable if it runs musl rather than glibc, has no PAM, allows password logins, has an account whose password field is “*”, and has at least one other local account with a real SHA-crypt hash. Direct root login also needs PermitRootLogin set to yes. StepSecurity found that GitHub-hosted Ubuntu runners and glibc systems are unaffected, and that Alpine’s own tiny-cloud images are safe on first boot.
There are two ways to protect a server that cannot be updated at once. Setting PasswordAuthentication to no in the SSH configuration blocks the route while keeping key-based logins, and StepSecurity confirmed that a PAM build with UsePAM set to yes also stops it. Update the package, then restart sshd: the old process keeps running until you do.
Do not rely on the version number a server reports. Alpine backports the fix without changing it, so a patched 10.3 package still announces itself as OpenSSH 10.3p1; StepSecurity’s tests showed a community check script wrongly flagging such a host. Query the package manager instead (apk info -v openssh-server on Alpine) and compare the revision against the distribution’s advisory.
For logs, the telltale sign is a failed password attempt followed by an accepted one for the same passwordless account in one session, because the bypass only works on the second or later attempt in a connection. Containers built before 5 November and cached in CI layers or internal registries are the likeliest to still carry the old package.
