'*sshole' flaw lets attackers SSH into some Alpine Linux systems without a password

Left · 1A vulnerability named *sshole lets attackers log in over SSH without a password on devices running some configurations of Alpine Linux, and possibly other distributions. 1 Mixed · 2The flaw lies in the interaction between OpenSSH and musl, a lightweight alternative to the libc library that Alpine uses, and it applies when OpenSSH is built without PAM (pluggable authentication modules). 1 2 Centre · 1ZDNET explains the mechanism: when a password is longer than 256 bytes, musl's crypt() returns the string "*" as an error indicator, which is also what the password field holds for an account with no password, so the comparison matches and the login succeeds. 2

Mixed · 2Exploitation needs the name of a passwordless account ("*" in /etc/shadow, common for certificate- or key-only accounts) and at least one other active account with a SHA256 or SHA512 password hash. The attacker then sends an oversized password; ZDNET puts the length at 257 to 1,024 bytes. 1 2 Mixed · 2Alpine maintainers said that an attacker who can reach the SSH port can log in without knowing any password, and that it "takes one connection, works every time, and needs no retries." 1 2 Mixed · 2Root accounts are generally protected by OpenSSH's default PermitRootLogin prohibit-password setting, but a reachable account that can become root through doas or sudo still gives an attacker a route to root. 1 2

Left · 1Ars Technica says the exposure could be large: Alpine's Docker Hub base image has more than 1 billion downloads, and Alpine is common in routers, smart TVs, industrial controllers and other embedded devices that are hard to update. It cites Detectify as saying Shodan lists about 22 million systems with SSH open on port 22, only a fraction of which would meet the conditions. 1 Centre · 1Alpine said every release it checked is affected, from 3.16 through 3.24 and edge, and singled out its official tiny-cloud images (3.18.11 through 3.24.3), which ship with a passwordless alpine user with passwordless doas and become exploitable once any SHA-crypt hash exists on the machine. 2 Mixed · 2ZDNET lists other musl-based systems as potentially vulnerable, including Adélie Linux, Void Linux, Sabotage Linux, OpenWrt and the Yocto Project, and says Wind River is assessing the issue. Ars Technica says the discoverer named OpenWrt, buildroot and yocto, but only buildroot and yocto are unconfirmed there, and OpenWrt uses Dropbear rather than OpenSSH by default. Distributions using glibc, such as Debian, Ubuntu and Fedora, are not affected, according to ZDNET. 2 1

Left · 1Responsibility for the bug is unsettled. OpenSSH said it considers the root cause "outside sshd" but that the bug can be avoided there, while musl developer Rich Felker said it is "not a bug in musl just an erroneous use by the caller", though musl planned to change the mechanism in an upcoming release. 1 Mixed · 2Fixes arrived on Thursday: OpenSSH 10.6p2 avoids the problem in sshd, and Alpine released 3.21.10, 3.22.8, 3.23.8 and 3.24.4 plus fixed packages back to 3.16. Administrators are told to run apk upgrade -U -a and restart sshd, because upgrading the package does not replace the running daemon. 2 1 Centre · 1Those who cannot update should set PasswordAuthentication no after confirming key login works, and Alpine advised checking /var/log/messages for "Accepted password for" lines naming a passwordless account, adding: "If you cannot rule out a login, treat the machine as compromised." 2

Mixed · 2The coverage differs on the identifier: Ars Technica says there is no known CVE designation, while ZDNET quotes a LinkedIn post by security engineer Gregory Bryant citing CVE-2026-123158. ZDNET attributes the discovery, dated to 2016, to the *sshole group. 1 2