"*sshole" Flaw in OpenSSH/musl Lets Attackers Log Into Password-Disabled Linux Accounts
Researcher Ozgun Kultekin disclosed a vulnerability dubbed *"sshole" affecting OpenSSH servers running on musl-based Linux distributions such as Alpine Linux, OpenWrt, Buildroot, and Yocto. The flaw, present since 2016, allows attackers to authenticate into accounts explicitly configured to block password logins (via an asterisk in /etc/shadow) by simply submitting an oversized password. This is especially dangerous on Alpine Linux's official AWS and Azure cloud images, where the default 'alpine' account has passwordless 'doas' privileges, potentially enabling full root compromise. The issue has been fixed in OpenSSH 10.6p2.
Entenda a falha
A vulnerabilidade
"*sshole" is an authentication bypass in OpenSSH servers running on musl-based Linux (Alpine Linux, OpenWrt, Buildroot, Yocto). No CVE is listed for it. An unauthenticated remote attacker who can reach SSH can log into an account whose password is disabled with an asterisk in /etc/shadow by submitting an oversized password. Conditions: PAM disabled (the Alpine default), password authentication enabled, at least one account with * as hash and another with a valid hash. It does not bypass accounts with valid hashes. On Alpine's official AWS and Azure images the default 'alpine' account has passwordless doas, so root is reachable. Fixed in OpenSSH 10.6p2; the bug dates from 2016.
Como funciona
When a password login arrives, OpenSSH looks up the account's hash in /etc/shadow. Since a 2016 change, for accounts with no usable hash it still runs password hashing through crypt(), so response times do not reveal which usernames exist. On musl, crypt() returns * when hashing fails, including when the submitted password exceeds 256 bytes. OpenSSH then compares the returned * with the stored * and sees a match, so the login is accepted although no valid password exists.
Por que é vulnerável
The root cause is a wrong assumption combined with an ambiguous return value. The 2016 patch for the username enumeration flaw CVE-2016-6210 made OpenSSH hash passwords for accounts without a usable hash, assuming crypt() output could never equal the stored disabled marker. On musl, crypt() uses the same * string as an error value, so a failure is indistinguishable from the disabled-account marker. glibc systems and PAM setups are not affected. The articles do not describe the details of the fix beyond it being in OpenSSH 10.6p2.
Como foi descoberta
Researcher Ozgun Kultekin discovered the flaw and published the details on the day of the report, 5 November 2026. He says he found it using AI agents that ran about 17,600 authentication tests with different OpenSSH configurations, malformed password hashes and oversized passwords. The weakness has existed since the 2016 patch. The articles do not describe a prior report or a coordinated disclosure timeline.
Explicação gerada por IA a partir da matéria e dos artigos, em 05/11/2026 15:15.
Detalhes técnicos
The root cause traces back to a 2016 OpenSSH patch for CVE-2016-6210 (a username enumeration flaw) that forced password hashing even for accounts with no usable password hash, to equalize response times. On musl-based systems, the crypt() function returns an asterisk (*) both for the stored "disabled" hash and when hashing fails, including when a submitted password exceeds musl's 256-byte limit. An attacker who submits an oversized password can thus cause OpenSSH to compare * against *, resulting in a successful login. Exploitation requires: OpenSSH on a musl-based system, PAM authentication disabled (default on Alpine), SSH password authentication enabled, at least one account with * as its password hash, and another account with a valid password hash. Systems using glibc (Debian, Ubuntu, Fedora) or PAM authentication are not affected. Kultekin found the bug using AI agents that ran roughly 17,600 authentication tests with varied configurations.
Remediação
Administrators should update OpenSSH to version 10.6p2 or later (on Alpine, via apk upgrade openssh). Where immediate patching isn't possible, disable SSH password authentication (PasswordAuthentication no) and restart the SSH service. Admins can check for exploitation by searching authentication logs for successful password logins (grep "Accepted password" /var/log/messages) against accounts whose /etc/shadow entry shows *, such as the default 'alpine' account.
Linha do tempo
-
"*sshole" Flaw in OpenSSH/musl Lets Attackers Log Into Password-Disabled Linux Accounts
ler a análise desta fonte ocultar
Researcher Ozgun Kultekin disclosed a vulnerability dubbed *"sshole" affecting OpenSSH servers running on musl-based Linux distributions such as Alpine Linux, OpenWrt, Buildroot, and Yocto. The flaw, present since 2016, allows attackers to authenticate into accounts explicitly configured to block password logins (via an asterisk in
/etc/shadow) by simply submitting an oversized password. This is especially dangerous on Alpine Linux's official AWS and Azure cloud images, where the default 'alpine' account has passwordless 'doas' privileges, potentially enabling full root compromise. The issue has been fixed in OpenSSH 10.6p2.Technical Details
The root cause traces back to a 2016 OpenSSH patch for CVE-2016-6210 (a username enumeration flaw) that forced password hashing even for accounts with no usable password hash, to equalize response times. On musl-based systems, the
crypt()function returns an asterisk (*) both for the stored "disabled" hash and when hashing fails, including when a submitted password exceeds musl's 256-byte limit. An attacker who submits an oversized password can thus cause OpenSSH to compare*against*, resulting in a successful login. Exploitation requires: OpenSSH on a musl-based system, PAM authentication disabled (default on Alpine), SSH password authentication enabled, at least one account with*as its password hash, and another account with a valid password hash. Systems using glibc (Debian, Ubuntu, Fedora) or PAM authentication are not affected. Kultekin found the bug using AI agents that ran roughly 17,600 authentication tests with varied configurations.Remediation
Administrators should update OpenSSH to version 10.6p2 or later (on Alpine, via
apk upgrade openssh). Where immediate patching isn't possible, disable SSH password authentication (PasswordAuthentication no) and restart the SSH service. Admins can check for exploitation by searching authentication logs for successful password logins (grep "Accepted password" /var/log/messages) against accounts whose/etc/shadowentry shows*, such as the default 'alpine' account.