A vulnerability dating back to 2016, dubbed *sshole, allows attackers to log into certain Linux accounts configured to block password authentication simply by entering a password longer than 256 bytes. The flaw affects OpenSSH running on systems using the musl C library, such as Alpine Linux, OpenWrt, Buildroot, and Yocto, under specific authentication configurations. Security researcher Özgün Kültekin disclosed the vulnerability today and said it was discovered using AI agents that ran about 17,600 authentication tests. A fix has been released in OpenSSH 10.6p2.
The sshole vulnerability stems from an interaction between OpenSSH and the musl C library, a lightweight alternative to glibc commonly used in embedded systems. Linux accounts can be configured to prevent password logins by placing an asterisk () in the password hash field of /etc/shadow. Because that is not a valid hash, no password should grant access.
In 2016, OpenSSH introduced a patch (related to CVE-2016-6210) to prevent username enumeration attacks. That patch made OpenSSH perform dummy password hashing even for accounts with no usable hash, including those with an asterisk. The problem arises because musl's crypt() function also returns an asterisk when password hashing fails, for example, when a submitted password exceeds its 256-byte limit. An attacker can therefore submit an oversized password, causing OpenSSH to compare the returned asterisk against the stored asterisk, resulting in a successful login.
The flaw only works under specific conditions: OpenSSH must be running on a musl-based Linux system, PAM authentication must be disabled (as it is by default in Alpine Linux's openssh-server package), SSH password authentication must be enabled, at least one account must have an asterisk as its password hash, and another account must have a valid password hash. The researcher warned that Alpine Linux's official AWS and Azure cloud images have a default 'alpine' account with passwordless 'doas' privileges, which could allow attackers to gain root access.
Systems using glibc (including Debian, Ubuntu, and Fedora) and those using PAM authentication are not vulnerable.
OpenSSH has fixed the issue in version 10.6p2, released Thursday. Administrators on affected systems are advised to update OpenSSH packages immediately. For those who cannot update, disabling password authentication by setting PasswordAuthentication no in the SSH server configuration and restarting the daemon mitigates the risk.
Administrators can check for signs of exploitation by examining SSH authentication logs for password-based logins on accounts that should not accept passwords. On Alpine Linux, the command grep "Accepted password" /var/log/messages can reveal successful logins; a match for the alpine account combined with an asterisk in its /etc/shadow entry could indicate exploitation.
The origins of the asterisk convention date back to BSD Unix, where it was used in /etc/passwd to disable password login for certain accounts. Tom's Hardware notes that both OpenSSH and musl developers appear to blame the other for the flaw, with the shared responsibility lying in musl's crypt() returning an asterisk on error instead of null, and OpenSSH failing to reject that result when comparing hashes.
There is no indication that vulnerable systems have been exploited, but the vulnerability is trivial to scan and test. Tom's Hardware advises patching systems immediately.
Analysis
Why This Matters
- The vulnerability affects Alpine Linux, which underpins millions of Docker, Kubernetes, and cloud VM deployments on AWS and Azure.
- Attackers inside a network (corporate, cloud, home) can gain access to accounts that should be password-protected, potentially escalating to root.
- The flaw has existed unpatched since 2016, meaning many systems may already be compromised without detection.
Background
The *sshole vulnerability exploits a mismatch between OpenSSH's 2016 username-enumeration fix and musl libc's error-handling behavior. Musl libc is designed for minimal memory footprint, making it popular in embedded systems and lightweight containers. Alpine Linux, which defaults to musl, provides official cloud images for major providers, widening the potential attack surface. The researcher used AI agents to automate 17,600 authentication tests to identify the flaw.
Key Perspectives
What to Watch
- Whether exploitation attempts appear in honeypot or SSH log dumps in coming weeks.
- Likelihood of mass scans for vulnerable OpenSSH instances on public IP ranges.
- Discussion among maintainers of OpenSSH and musl about long-term fixes for the asterisk handling.
Checked
12 claims in this story checked against 2 sources: 12 supported.
Show each claim
- SupportedThe *sshole flaw dates to 2016 and can let attackers log into accounts configured to block password authentication using an oversized password.BleepingComputer: “A newly disclosed flaw involving OpenSSH and musl, dubbed "*sshole," allows attackers to log in to certain Alpine Linux and other musl-based Linux accounts configured to block password authentication simply by entering an oversized password. The flaw has existed since 2016”
- SupportedThe flaw affects OpenSSH systems using musl, including Alpine Linux, OpenWrt, Buildroot and Yocto, under certain configurations.BleepingComputer: “The flaw only affects OpenSSH servers running on Linux distributions that use the musl C library, including Alpine Linux, OpenWrt, Buildroot, and Yocto, under certain authentication configurations.”
- SupportedThe fix is available in OpenSSH 10.6p2.BleepingComputer: “The vulnerability has been fixed in OpenSSH 10.6p2”
- SupportedResearcher Özgün Kültekin disclosed the vulnerability today.BleepingComputer: “Security researcher Ozgun Kultekin, who discovered and released details on the vulnerability today”
- SupportedKültekin said AI agents discovered the flaw by running about 17,600 authentication tests.BleepingComputer: “Kultekin says he discovered the vulnerability using AI agents that ran about 17,600 authentication tests with different OpenSSH configurations, malformed password hashes, and oversized passwords.”
- SupportedA 2016 OpenSSH patch to prevent username enumeration made OpenSSH perform password hashing for accounts without usable password hashes, including accounts marked with an asterisk.BleepingComputer: “To prevent attackers from identifying valid usernames through different response times, OpenSSH was modified to perform password hashing even when an account had no usable password hash, including accounts configured with * to block password logins.”
- SupportedMusl's crypt() returns an asterisk when password hashing fails, including when a submitted password exceeds its 256-byte limit, allowing the result to match an asterisk in the account's stored password field.BleepingComputer: “the musl C library's crypt() function also returns * when password hashing fails, including when a submitted password exceeds its 256-byte limit. This means an attacker can submit an oversized password and cause OpenSSH to compare the returned * against the account's stored *”
- SupportedExploitation requires PAM authentication to be disabled and SSH password authentication to be enabled.BleepingComputer: “PAM authentication is disabled, as it is by default in Alpine Linux's openssh-server package. SSH password authentication is enabled.”
- SupportedExploitation requires a target account with an asterisk as its password hash and another account with a valid password hash.BleepingComputer: “At least one account has an asterisk (*) as its password hash. Another account has a valid password hash.”
- SupportedThe researcher warned that official Alpine Linux AWS and Azure cloud images have a default alpine account with passwordless doas privileges, which could allow attackers to gain root access.BleepingComputer: “The researcher warns that Alpine Linux's official AWS and Azure cloud images have an affected default 'alpine' account with passwordless 'doas' privileges, which could allow attackers to gain root access.”
- SupportedSystems using glibc, including Debian, Ubuntu and Fedora, are not vulnerable to this attack.BleepingComputer: “Systems using glibc, including Debian, Ubuntu, and Fedora, and those using PAM authentication are not vulnerable to this attack.”
- SupportedThere is no indication that vulnerable systems have been exploited.www.theregister.com - Articles: “There’s no indication that vulnerable systems have been exploited”
