*sshole Flaw Lets Attackers Gain Root on musl-Based Linux via Overlong SSH Passwords
A vulnerability dubbed sshole, discovered by researcher Özgün Kültekin, allows attackers to bypass password-disabled account protections on Linux systems using musl libc (notably Alpine Linux) instead of glibc. By submitting an SSH password between 257 and 1,024 characters, an attacker can authenticate as accounts marked with an asterisk in their password field—such as root, key-only, or LDAP accounts—provided OpenSSH is configured without PAM, password authentication is enabled, and at least one other account has a valid password hash. The root cause traces back to a 2016 OpenSSH anti-enumeration timing fix combined with musl's choice to return an asterisk character on certain crypt() hashing failures, plus musl's 256-byte password cap triggering a quirky fallback path. Alpine Linux's prevalence in embedded systems and as the base for official AWS/Azure cloud images broadens the potential exposure, though exploitation requires a specific, non-default configuration.
Entenda a falha
A vulnerabilidade
*sshole (no CVE listed) is an authentication bypass in OpenSSH's sshd on Linux systems that use musl libc, such as Alpine Linux, instead of glibc. An attacker with network access to SSH can log in as accounts that should refuse passwords (root, key-only deployment users, LDAP users) by sending a password of 257 to 1,024 characters. Those accounts must have an asterisk in the password field. Exploitation also requires sshd built without PAM, password authentication enabled, and at least one other account with a valid password hash. Direct root login still depends on OpenSSH's configuration. Versions 10.6p2 and newer are fixed; the flaw dates to 2016.
Como funciona
When someone logs in over SSH with a password, sshd hashes the supplied password with crypt() and compares it with the stored value. Since 2016, sshd also hashes passwords for invalid users with a dummy hash so that response times do not reveal which accounts exist. On musl, crypt() returns a literal asterisk instead of NULL on certain failures, and musl caps passwords at 256 bytes. According to the story, a password over that cap sends the check down this odd fallback path. There the asterisk placeholder interacts with accounts whose password field is an asterisk, and the login is accepted.
Por que é vulnerável
The root cause is a combination of design choices that were safe on their own. musl's crypt() returns an asterisk, the old BSD marker for a disabled password, on some hashing failures instead of returning NULL. musl also limits passwords to 256 bytes. OpenSSH's 2016 anti-enumeration workaround then added dummy hashing for invalid users. Together they let an overlong password produce a value that matches the disabled-account marker. The fix is in OpenSSH 10.6p2; the articles do not describe the code change.
Como foi descoberta
The flaw was discovered by researcher Özgün Kültekin, who named it *sshole and published a writeup. The articles do not say how he found it or when he reported it. OpenSSH shipped the fix in 10.6p2, released the Thursday before The Register's 5 November 2026 article. No exploitation in the wild has been reported. The writeup includes a CLI command to check whether no-password accounts recently accepted a password login.
Explicação gerada por IA a partir da matéria e dos artigos, em 05/11/2026 16:15.
Detalhes técnicos
The flaw stems from musl libc's crypt() function returning a literal asterisk character instead of NULL on certain hashing failures—a convention tracing back to BSD Unix's 1980 use of an asterisk to disable password logins for the daemon user. OpenSSH's 2016 workaround for user-enumeration timing attacks performs dummy password hashing for invalid users; on musl, this interacts with the asterisk placeholder and the 256-byte password cap in a way that lets an overlong password (257–1024 bytes) authenticate against asterisk-marked accounts. The attack requires OpenSSH without PAM, password authentication enabled, a target account with an asterisk password field, and at least one other account with a valid password hash. No evidence of in-the-wild exploitation has been reported.
Remediação
Upgrade to OpenSSH 10.6p2 or newer, released the week of disclosure, which fixes the issue. If patching is not immediately possible, disable password authentication and restart the SSH daemon. Kültekin's writeup includes a CLI command administrators can use to check whether no-password accounts have recently accepted a password login.
Linha do tempo
-
*sshole Flaw Lets Attackers Gain Root on musl-Based Linux via Overlong SSH Passwords
ler a análise desta fonte ocultar
A vulnerability dubbed sshole, discovered by researcher Özgün Kültekin, allows attackers to bypass password-disabled account protections on Linux systems using musl libc (notably Alpine Linux) instead of glibc. By submitting an SSH password between 257 and 1,024 characters, an attacker can authenticate as accounts marked with an asterisk in their password field—such as root, key-only, or LDAP accounts—provided OpenSSH is configured without PAM, password authentication is enabled, and at least one other account has a valid password hash. The root cause traces back to a 2016 OpenSSH anti-enumeration timing fix combined with musl's choice to return an asterisk character on certain crypt() hashing failures, plus musl's 256-byte password cap triggering a quirky fallback path. Alpine Linux's prevalence in embedded systems and as the base for official AWS/Azure cloud images broadens the potential exposure, though exploitation requires a specific, non-default configuration.
Technical Details
The flaw stems from musl libc's crypt() function returning a literal asterisk character instead of NULL on certain hashing failures—a convention tracing back to BSD Unix's 1980 use of an asterisk to disable password logins for the daemon user. OpenSSH's 2016 workaround for user-enumeration timing attacks performs dummy password hashing for invalid users; on musl, this interacts with the asterisk placeholder and the 256-byte password cap in a way that lets an overlong password (257–1024 bytes) authenticate against asterisk-marked accounts. The attack requires OpenSSH without PAM, password authentication enabled, a target account with an asterisk password field, and at least one other account with a valid password hash. No evidence of in-the-wild exploitation has been reported.
Remediation
Upgrade to OpenSSH 10.6p2 or newer, released the week of disclosure, which fixes the issue. If patching is not immediately possible, disable password authentication and restart the SSH daemon. Kültekin's writeup includes a CLI command administrators can use to check whether no-password accounts have recently accepted a password login.