OpenSSH has released version 10.6p2 to close a critical authentication bypass, nicknamed “*sshole,” that lets remote attackers log in to accounts without a password on Linux systems built on the musl C library, including Alpine Linux. Damien Miller of the OpenSSH project rated the flaw critical and told affected users to set PasswordAuthentication=no or disable SSH on these systems immediately.
How an Overlong Password Opens Passwordless Accounts
Researcher Ozgun Kultekin of Wakefield disclosed the flaw and gave it the “*sshole” name. The weakness affects accounts that carry no usable password, shown by an asterisk in the shadow password field. Typical examples are key-only deployment users, LDAP or directory users and root.
An attacker sends a password between 257 and 1,024 bytes long. Reporting on the research says the technique works on a single connection every time.
The 2016 Username-Enumeration Fix Behind the Bug
The cause traces to a 2016 OpenSSH change made to address a username-enumeration bug tracked as CVE-2016-6210. After that change, sshd hashes a submitted password even for accounts that have no usable hash, so that response timing does not reveal which usernames exist.
On musl, the crypt() function returns an asterisk as an error value when the password exceeds 256 bytes. Sshd then compares that returned asterisk with the asterisk stored for the passwordless account, finds a match and logs the attacker in. The OpenSSH change that introduced the latent problem therefore sat unnoticed on musl systems for roughly a decade.
The Four Conditions Alpine Lists
Alpine’s advisory sets out four conditions for exposure. The openssh-server package must be built without PAM, which is Alpine’s default, or UsePAM must be set to no. PasswordAuthentication must be enabled, which is the OpenSSH default. The system must have an account with an asterisk in its password field. And at least one other account must have a $5$ or $6$ password hash.
The last condition means a single account with a real password is enough to expose every passwordless account on the machine.
Why Alpine Cloud Images Face the Clearest Path to Root
Alpine’s official cloud images, which use tiny-cloud, ship with an “alpine” user that has passwordless doas. An attacker who logs in as that user through the bypass can therefore escalate to root. Direct root login remains subject to the PermitRootLogin setting, whose default is prohibit-password.
Which Systems Are Not Affected
Systems that use glibc, PAM-based configurations, Dropbear, OpenBSD and non-Linux operating systems are not affected. Containers that do not run sshd are also safe. Distributions named as using musl and potentially exposed include Alpine Linux, OpenWrt, Buildroot and Yocto. Docker and cloud images built on Alpine that run sshd form the main exposure.
Patches, Workarounds and an Unresolved CVE Question
OpenSSH shipped 10.6p2 on Nov. 5. Alpine published fixed packages for all supported releases back to 3.16, running through to edge. The stopgap measure recommended by the project is to turn off password authentication or disable SSH on affected hosts.
Conflicting Reports on CVE Assignment and Exploitation
One security news summary lists a CVE-2026-123158 identifier, a CVSS score of 8.1 and a status of exploited in the wild. That same outlet’s own text, along with other reporting on the flaw, says no exploitation or public exploit code has been reported and that no CVE had been assigned when the fix was released. The CVE identifier and any in-the-wild exploitation should therefore be treated as unconfirmed.
What the “*sshole” Flaw Shows About Long-Lived Defensive Changes
The bug is notable because it arises from an interaction between a defensive fix and a third-party library’s error handling, not from a coding mistake in a single component. The 2016 change worked as intended on glibc and PAM systems, and the failure appeared only where musl’s crypt() reports an overlong input by returning the same asterisk used as a placeholder in shadow files.
For operators, the exposure is limited to a specific combination of build options and account layouts, but that combination is the default on Alpine. The release of 10.6p2 and the matching Alpine packages ends the window for those systems that apply them.
