“I discovered the vulnerability using AI agents that ran about 17,600 authentication tests,” security researcher Ozgun Kultekin wrote in published details describing a flaw now dubbed “sshole.”
How sshole works: a 2016 change, musl’s crypt(), and an asterisk
The vulnerability traces to a 2016 OpenSSH change made to address username enumeration (CVE-2016-6210). That patch caused OpenSSH to perform password hashing even when an account had no usable password hash. On systems using the musl C library, that behavior meets an unexpected return value from musl’s crypt() implementation: crypt() returns an asterisk (*) when hashing fails, including when a submitted password exceeds musl’s 256‑byte limit. If an account’s password field in /etc/shadow already contains a literal *, an oversized password can make crypt() return * and cause OpenSSH’s comparison to succeed — effectively allowing login to accounts intended to be password‑disabled.
Which systems are affected — Alpine Linux, OpenWrt, Buildroot, Yocto
The bug only affects OpenSSH servers running on Linux distributions that use the musl C library. The source specifically names Alpine Linux, OpenWrt, Buildroot, and Yocto as affected platforms. Systems that use glibc — the report names Debian, Ubuntu, and Fedora — are not vulnerable. Systems that authenticate via PAM (Pluggable Authentication Modules) are also not vulnerable to this particular issue.
The cyber insurance questionnaire just landed. Now what?
SOC 2, HIPAA, insurance renewals - someone has to own security strategy. Nubivance provides fractional CISO leadership without the full-time salary.
Get a security leadPractical exploit conditions and consequences for Alpine cloud images
Kultekin lists explicit conditions required for exploitation:
- OpenSSH running on a musl‑based system;
- PAM authentication disabled (the researcher notes PAM is disabled by default in Alpine Linux’s openssh‑server package);
- SSH password authentication enabled;
- At least one account with an asterisk (*) as its password hash; and
- At least one other account with a valid password hash.
The researcher warns that Alpine Linux’s official AWS and Azure cloud images include an affected default “alpine” account with passwordless “doas” privileges. In that configuration, the report says, a successful sshole login to the alpine account could allow an attacker to gain root access via doas.
Patch, mitigations, and detection steps for administrators
The vulnerability has been fixed in OpenSSH 10.6p2. Alpine administrators are advised to update OpenSSH with the package manager command the report provides: apk upgrade openssh (command reproduced from the source material). For administrators who cannot immediately apply the update, the report recommends disabling SSH password authentication by setting PasswordAuthentication no in the SSH server configuration and restarting the SSH service.
The researcher also suggests monitoring for signs of exploitation by examining SSH authentication logs for password-based logins to accounts that should not permit them. On Alpine Linux, Kultekin provides the following command to reveal successful SSH password logins:
- grep "Accepted password" /var/log/messages
If logs show a successful password login for the alpine account, administrators can check that account’s password field with:
- grep '^alpine:' /etc/shadow
If the shadow file shows a literal * but SSH logs show an “Accepted password” event for that account, Kultekin says it could indicate exploitation via this vulnerability.
How Alpine Linux administrators, cloud operators, and embedded device teams should respond
- Alpine Linux administrators: update OpenSSH to 10.6p2 or run apk upgrade openssh; if immediate patching isn’t possible, disable PasswordAuthentication and scan logs for “Accepted password” entries for accounts that should not accept passwords.
- Cloud operators using Alpine images on AWS or Azure: verify whether default images expose the alpine account with doas permissions, and prioritize patching or disabling password authentication on exposed instances.
- Embedded and IoT device teams (OpenWrt, Buildroot, Yocto): identify devices using musl and OpenSSH, confirm whether PAM is disabled and password authentication is enabled, and apply the OpenSSH update or disable password-based SSH to block the exploit vector.
The sshole case is a tight, deterministic chain of two code decisions — OpenSSH’s 2016 attempt to obscure username validity and musl’s crypt() behavior on failure — that together reintroduced an unexpected login path. The fix is available; the practical defensive steps are straightforward; the remaining task is rapid, disciplined patching and log review on musl‑based systems where password auth remains enabled.
Original reporting: BleepingComputer: OpenSSH flaw lets attackers log into password-disabled Linux accounts
