An attacker who can reach an SSH port can log into an account deliberately set up with no password, simply by sending a password that is too long. That is CVE-2026-123158, nicknamed "*sshole," disclosed on November 5, 2026, and fixed the same day in OpenSSH 10.6p2.
The bug does not affect most Linux servers. It requires a specific combination: a system built on the musl C library, an SSH server that checks passwords without PAM, password authentication left enabled, and at least one account whose password field in /etc/shadow is a single asterisk. That asterisk normally means no password can ever match. At least one other local account must also carry a normal SHA-256 or SHA-512 password hash, whose salt the server borrows during the check.
Alpine Linux is the most widely exposed platform because it fits that combination by default. Alpine is built on musl, its standard openssh-server package is compiled without PAM, and password logins are on by default. Other musl-based systems, including some OpenWrt, Buildroot and Yocto builds, can be exposed the same way. Debian, Ubuntu, Fedora and other glibc distributions are not affected, nor are PAM systems, non-Linux systems, or containers that do not run an SSH server.
The mechanism is a collision between two uses of the same character. When OpenSSH checks a password without PAM, it runs the attempt through the C library function crypt() and compares the result with the stored field. Musl refuses passwords longer than 256 bytes, a limit intended to prevent slow hashing, and returns a single asterisk to signal failure. For a password-disabled account, the stored field is also a single asterisk. OpenSSH therefore sees a match, and any password from 257 to 1,024 bytes long is accepted.
The weakness has been present since 2016, when a fix for an earlier username-enumeration flaw, CVE-2016-6210, changed how OpenSSH handled password verification on musl. Musl's asterisk-on-failure behavior dates to 2012. The flaw was reported by Özgün Kültekin of Wakefield, who said he found it with AI agents running about 17,600 authentication tests across different OpenSSH setups. It carries a CVSS score of 8.1, rated high. OpenSSH describes the root cause as sitting outside sshd itself, but shipped a workaround in sshd because that is where it can be exploited. Version 10.6p2 refuses to compare a password against a stored value shorter than four characters, so an asterisk can never match again.
The practical risk is highest on Alpine's official tiny-cloud images, versions 3.18.11 through 3.24.3, which ship an alpine user with an asterisk password field and passwordless administrative access through doas. On a host where another account has a real password hash, a successful login through that user can lead to root. Default settings still block a direct root password login unless PermitRootLogin was changed.
As of November 6, no confirmed exploitation in the wild had been reported, the flaw was not listed in CISA's Known Exploited Vulnerabilities catalog, and public proof-of-concept material was referenced in the CVE record. That is not a reason to wait. OpenSSH maintainer Damien Miller urged operators of affected systems to set PasswordAuthentication to no or disable SSH immediately until patched.
Administrators should inventory every musl-based host, virtual machine and container image that runs sshd, update the OpenSSH package, and restart the daemon, because a running server keeps serving the old code until it restarts. Alpine has shipped patched packages and point releases 3.21.10, 3.22.8, 3.23.8 and 3.24.4. Where an immediate update is not possible, disabling password authentication and restricting SSH access by network policy are effective interim controls.