An attacker can gain root access by entering a password longer than 256 bytes on certain musl-based Linux systems — a vulnerability researcher Özgün Kültekin has dubbed “*sshole” and traced to interactions between decades-old Unix conventions, musl libc’s behavior, and OpenSSH’s 2016 mitigation for username enumeration.
How the bug works
The flaw arises when several specific conditions line up. On affected systems, musl libc returns an asterisk character when its crypt() implementation fails to compute a hash in some circumstances. Historically, an asterisk in a password field has been used to indicate “no password” — a practice dating back to the BSD Unix era and examples such as a single asterisk in the /etc/passwd entry for the daemon user in 1980.
OpenSSH, beginning in 2016, introduced dummy password hashing for invalid users to make response times for invalid and valid usernames more similar and prevent account-name enumeration. That change performs a hashing operation even for nonexistent accounts. On musl-based systems that do not use PAM, with password authentication enabled, and where at least one account has a valid password hash, supplying a password between 257 and 1,024 characters can cause accounts whose password field contains an asterisk — including root, key-only deployment users, and LDAP users — to be accepted as if a valid password had been provided.
Why musl and Alpine matter
The bug is limited to systems that use musl libc rather than the GNU C library. Musl is widely used in embedded Linux because of its small footprint. Equally significant, musl is the standard C library for Alpine Linux. Alpine provides official cloud images for both AWS and Azure, which means some cloud instances running Alpine could be vulnerable depending on their SSH and authentication configuration.
Musl’s developers also added SHA-512-based password hashing; Kültekin notes that the SHA-512 hashing gets slower as provided passwords grow longer, which can amplify denial-of-service effects if a server is flooded with super-long passwords. Musl additionally enforces a 256-byte cap on passwords — a limitation central to how this flaw can be triggered.
Your scanner finds 4,000 vulns. Which 12 matter?
Nubivance is a Rapid7 Registered Partner delivering vulnerability management as a service - scanning, risk-based prioritization, and remediation follow-through across IT and OT.
Fix the backlogWhich systems and accounts are at risk
The vulnerability can be exploited only in a narrow but nontrivial set of circumstances:
- The system uses musl libc.
- OpenSSH is configured without Pluggable Authentication Modules (PAM).
- Password authentication is enabled in OpenSSH.
- At least one account on the system has a valid password hash.
- Targeted accounts have an asterisk (*) in their password field (the historical marker for “no password”).
Under these conditions, an attacker who supplies a password between 257 and 1,024 characters may gain access to accounts that ordinarily would not accept password logins. Direct root login remains subject to OpenSSH’s configuration settings, so whether root can be reached directly still depends on that configuration.
OpenSSH’s fix and interim mitigations
OpenSSH addressed the problem in build 10.6p2, released Thursday; any OpenSSH build 10.6p2 or newer is protected against this specific issue. For systems where immediate upgrading is not feasible, the practical alternative is to disable password authentication and restart the SSH daemon — that step prevents password-based exploitation.
Kültekin has also published a simple CLI command in his writeup that administrators can run to check whether any “no-password” accounts on a machine recently accepted a password, offering a way to hunt for potential successful attempts on sensitive systems.
What this means for cloud operators, embedded-device maintainers, and site security teams
- Cloud operators using official Alpine images on AWS or Azure should verify their OpenSSH builds and authentication configuration. If SSH runs without PAM and allows password authentication, an upgrade to OpenSSH 10.6p2 or later, or disabling password auth, is the clear step.
- Embedded-device maintainers who ship musl-based firmware need to check whether devices expose SSH with password authentication and whether user entries contain an asterisk; the musl design choices that helped reduce footprint can interact with legacy conventions to create unexpected exposure.
- Site security teams should use Kültekin’s CLI test to look for signs of successful password acceptance on accounts that shouldn’t accept passwords and consider log reviews where possible; the advisory notes no indication yet that vulnerable systems have been exploited, but the risk profile warrants attention.
The vulnerability is a cautionary example of how long-lived design decisions and compatibility changes — an asterisk used as a “no-password” marker from the BSD era, musl’s handling of crypt() failures and input length, and OpenSSH’s dummy-hash defense introduced in 2016 — can combine to create a surprisingly simple path to privilege escalation. Patch or disable password auth, check for evidence of unexpected logins, and account for musl’s footprint-friendly choices when assessing SSH exposure.
