OpenSSH flaw lets attackers log into password-disabled accounts on musl Linux with a 257-character password

The 257-byte password that unlocks locked accounts

On Linux systems built on the lightweight musl C library, supplying a password containing 257 characters or more can grant an unauthenticated remote attacker instant access to accounts that were configured to accept no passwords at all.

The OpenSSH project published an emergency out-of-band release, OpenSSH 10.6p2, on 5 November 2026 to neutralize the vulnerability. The flaw, nicknamed *sshole by security researcher Ozgun Kultekin of Wakefield who discovered it, arises from an unexpected collision between OpenSSH timing attack mitigations, musl libc error handling routines, and a 46-year-old Unix password convention dating back to 1980.

The vulnerability does not involve memory corruption, buffer overflows, or remote code execution. Instead, it represents a catastrophic semantic failure in password verification logic. When an attacker attempts to log into an account whose shadow password entry is set to an asterisk (denoting that password authentication is disabled), submitting an input string longer than 256 bytes forces the musl crypt function to fail and return an asterisk. OpenSSH then compares the returned asterisk against the stored asterisk, evaluates the strings as identical, and authenticates the attacker.

The flaw directly impacts Alpine Linux, the standard base distribution for millions of Docker containers, as well as embedded operating systems including OpenWrt, Buildroot, and Yocto. Crucially, official Alpine Linux cloud images distributed across Amazon Web Services (AWS) and Microsoft Azure ship with the default alpine user account locked with an asterisk while granting passwordless administrative execution via doas. On exposed cloud instances, an attacker providing an overlong password gains full root privileges in a single step.

Forty-six years of interacting design choices

The root cause of the vulnerability spans nearly half a century of operating system evolution, resulting from four independent, well-intentioned defensive decisions that collided in modern cloud environments.

Chronology of interacting design choices from 1980 to 2026. Source: Research disclosure by Ozgun Kultekin.

Year	Milestone and Actor	Design Choice and Context	Security Consequence
1980	3BSD Unix (Bill Joy)	Places an asterisk (*) in /etc/passwd for the daemon user	Establishes convention that an asterisk denotes an account that cannot accept passwords
1997	Single UNIX Specification	Defines crypt() to return NULL when unable to compute hash	Applications failing to check for NULL pointers crash upon receiving invalid input
August 2012	musl libc (commit b3c4cc12)	Changes crypt() to return single asterisk (*) instead of NULL on error	Prevents application crashes by returning a string assumed to be unmatchable
August 2012	musl libc (commit 88bf5a8a)	Caps SHA-512 crypt passwords at 256 bytes to prevent CPU exhaustion	Any password input exceeding 256 bytes immediately fails and returns single asterisk (*)
July 2016	OpenSSH (CVE-2016-6210)	Introduces dummy hashing borrowing valid salts to stop user enumeration	sshd executes crypt() even for locked and non-existent users, passing attacker input
May 2022	Alpine Linux 3.16 (commit fbe926af)	Switches locked accounts from exclamation mark (!) to asterisk (*)	Intended to restore SSH public key logins without PAM; sets stage for collision
November 2026	OpenSSH 10.6p2	Emergency patch modifies salt selection and rejects asterisk comparisons	Closes the 46-year semantic gap across Alpine and musl Linux environments

In 1980, BSD Unix co-founder Bill Joy placed a single asterisk in the password field of /etc/passwd for system daemon accounts, writing the devil himself in the comment field. Because cryptographic hashes never evaluate to a single asterisk character, this convention ensured that no possible password entered by a user could ever match the file. That convention remained standard across Unix and Linux shadow password databases for 46 years (derived: 2026 minus 1980).

Thirty-two years later, in August 2012, developers of the musl C library sought to prevent programs from crashing when crypt returned NULL upon encountering unexpected inputs. They chose to return a static single asterisk string, reasoning that an asterisk could never match a valid password hash. Three weeks later, musl added SHA-512 password hashing and instituted a strict 256-byte limit to prevent malicious actors from stalling servers with computationally expensive mega-passwords. Consequently, any password longer than 256 bytes was hardcoded to return an asterisk.

Zoom

The architectural collision: why a long password returns an asterisk

The exploit operates through a tight mechanical sequence when OpenSSH processes an incoming authentication request against an account without a password hash.

In 2016, OpenSSH introduced a timing defense (CVE-2016-6210). Previously, attackers could enumerate valid usernames by measuring how quickly the server rejected login attempts: non-existent accounts returned immediately, while valid accounts took several milliseconds longer because the server executed a cryptographic hash. To equalize response times, OpenSSH began borrowing the salt and algorithm from another valid local account and hashing the attacker's password anyway.

When an attacker connects to an exposed musl system and attempts to log in as root or another account whose shadow password is an asterisk, OpenSSH identifies that the target has no valid hash. To mask this from a timing perspective, OpenSSH executes pick_salt, borrows the SHA-512 salt from another local account, and calls the libc crypt function with the attacker's password.

If the attacker submits a password between 257 and 1,024 bytes in length (spanning 768 valid exploit lengths (derived: 1,024 minus 257 plus 1)), musl libc detects that the string exceeds its 256-byte KEY_MAX threshold. musl terminates hashing and returns its standard error token: a single asterisk (*).

OpenSSH then takes the returned string () and compares it with the stored shadow password (). Because both values are identical single-character asterisks, the comparison evaluates to true. OpenSSH concludes that the password is correct and grants an interactive login shell.

Zoom

Exposure matrix: Alpine Linux, cloud images, and Docker containers

The vulnerability requires four specific conditions to align simultaneously on the target host. If any single condition is absent, the system is immune to the exploit.

Vulnerability exposure criteria and immunity factors. Source: Alpine Linux Security Advisory.

Condition	Vulnerable Configuration	Immune Configuration	Impact and Mechanics
C Library Runtime	musl libc (Alpine, OpenWrt, Yocto)	GNU C Library (glibc - Debian, Ubuntu, RHEL)	glibc crypt does not truncate passwords to an asterisk on length errors
Authentication Architecture	OpenSSH built without PAM (Alpine default)	OpenSSH running with UsePAM yes	PAM bypasses crypt entirely when inspecting accounts marked with an asterisk
Password Authentication	PasswordAuthentication yes (OpenSSH default)	PasswordAuthentication no (keys only)	Disabling password authentication blocks the vulnerable code path completely
Account State in Shadow	Target account marked with asterisk (*)	Account marked with exclamation mark (!)	Exclamation marks do not collide with musl error tokens but block key logins
Local Hash Coexistence	At least one local account has a valid hash	No local accounts have valid password hashes	OpenSSH requires a valid salt from another account to trigger dummy hashing

The exposure across cloud environments is acute. Alpine Linux official tiny-cloud images distributed on AWS and Azure configure the default alpine user with an asterisk in /etc/shadow. Furthermore, this account is granted passwordless execution rights through doas. Even though OpenSSH default configuration (PermitRootLogin prohibit-password) restricts direct root logins, an attacker can authenticate as alpine using a 257-byte password and immediately escalate to root.

Conversely, standard Docker containers running Alpine Linux are generally not affected unless an administrator explicitly installed and launched the openssh-server daemon inside the container. The vast majority of container workloads execute application processes directly without running SSH daemons.

Zoom

Technical details: agent swarms, timing defenses, and OpenSSH's warning

The discovery of the vulnerability highlights the growing impact of automated agent tooling in systems security research. Researcher Ozgun Kultekin uncovered the flaw after constructing a differential testing harness that executed 17,600 automated login permutations across combinations of glibc, musl, PAM configurations, and malformed shadow files. The testing swarms flagged an anomaly exclusively on musl systems without PAM, where accounts rejecting valid credentials suddenly accepted strings exceeding 256 bytes.

In its release notes for OpenSSH 10.6p2, the OpenSSH development team issued an extraordinary commentary addressing the surge of AI-generated vulnerability reports in open-source software.

The OpenSSH team noted that they have received a large volume of bug reports generated with AI assistance. Crucially, the maintainers observed multiple instances where a vulnerability identified by automated AI tools was subsequently independently rediscovered by human researchers. The developers warned that this pattern indicates that malicious adversaries who do not disclose bugs to open-source maintainers are equally capable of discovering latent flaws. As a result, OpenSSH announced that it will abandon its traditional batched release schedule and transition to more frequent out-of-band releases to deliver fixes immediately.

Historical review reveals that multiple researchers previously approached the edge of the bug without realizing its full security implications. In July 2013, a Debian discussion (bug #714219) debated adopting musl's asterisk error convention for glibc, before Debian migrated to libxcrypt, which adopted *0 instead, missing the collision by one character. In December 2024, a thread on the musl mailing list examined why BusyBox passwd failed on 257-character passwords, but did not test OpenSSH. And on 30 October 2026, an OpenSSH code commit refactored the pick_salt function, modifying logic exactly four lines above the vulnerable code path four days before Kultekin reported the exploit.

What the advisory states versus what remains unstated

Security teams assessing their risk posture must separate the verified facts documented in vendor advisories from unanswered operational questions.

Comparison of verified vendor disclosures against operational omissions. Source: Analysis of OpenSSH and Alpine advisories.

Dimension	What the Advisories Explicitly State	What the Record Leaves Unstated
Vulnerability Identity	Addressed in OpenSSH 10.6p2 and Alpine package updates	No CVE identifier was assigned at the time of public disclosure
Root Cause Attribution	OpenSSH states the root cause resides outside sshd in musl libc	Whether musl libc will alter its crypt error return value in future releases
Exploitation History	No public indication that the vulnerability has been exploited in the wild	Whether threat actors or automated scanners weaponized the flaw prior to disclosure
Cloud Fleet Scale	Alpine confirms official AWS and Azure tiny-cloud images are vulnerable	The total population of active cloud instances running exposed configurations
Enterprise Scope	Affects 9 Alpine release branches from 3.16 to 3.24 plus edge	How many embedded network devices and appliances run musl OpenSSH without PAM

The absence of a CVE identifier at disclosure time complicates automated vulnerability scanning. Enterprise vulnerability management platforms that rely strictly on CVE feeds will not flag vulnerable hosts until a formal CVE entry is published and indexed.

Furthermore, while Alpine Linux moved rapidly to release backported packages across nine distinct release branches (Alpine 3.16 through 3.24, plus edge), administrators must recognize that upgrading packages does not terminate or restart running sshd processes. A server that receives the package update remains fully vulnerable until the daemon service is restarted.

Defensive imperative and remediation hierarchy

For organizations operating Alpine Linux servers, cloud virtual machines, or musl-based embedded devices, remediation must be executed in a strict operational sequence:

1. Update the OpenSSH package immediately. Execute apk upgrade -U -a on Alpine hosts to install OpenSSH 10.6_p2-r0 (on edge) or the corresponding backported release for Alpine 3.16 through 3.24.

2. Restart the SSH daemon immediately. Package upgrades in Alpine Linux do not restart running services. Administrators must run rc-service sshd restart (or restart the container/system) to reload the patched binary into memory.

3. Disable password authentication globally. If an immediate package upgrade is not feasible, edit /etc/ssh/sshd_config to ensure PasswordAuthentication no is enforced, verify that public key access functions correctly, and restart the daemon.

4. Audit historical authentication logs. Inspect system logs for accepted password authentications against accounts that should not possess passwords (such as root or alpine), searching for instances where passwords were accepted for locked accounts.

OpenSSH is developed by the OpenBSD Project, and Alpine Linux is an independent community Linux distribution.

When a four-decade-old convention intended to disable passwords transforms into an open master key due to libc error handling, how does your infrastructure baseline verify that disabled accounts cannot accept authentication?

Key facts at a glance