OpenSSH's 'sshole' Bug Let Long Passwords Into Password-Disabled Alpine Linux Accounts

On 5 November 2026, Özgün Kültekin, a researcher at the cybersecurity company Wakefield, disclosed a password-authentication bypass in OpenSSH affecting Linux systems that run the musl C library without PAM, most notably Alpine Linux. The flaw, nicknamed *sshole and later tracked as CVE-2026-123158, let an attacker log into an account configured to accept no password at all, simply by submitting an oversized password. OpenSSH shipped a fix the same day, in version 10.6p2, and the first exploitation attempts were recorded within hours.

A decade-old collision between musl and OpenSSH

According to Kültekin's write-up, the bug traces back to two separate design choices that only became dangerous together. In 2012, musl libc's crypt() function was built to return the string * as an error value when it cannot compute a hash, rather than returning NULL. In 2016, OpenSSH added a defense against account-enumeration timing attacks: when checking a password against a non-existent or password-disabled account, sshd borrows a password hash and salt from a real account on the system and hashes the attacker's input against it anyway, so a failed login takes the same time whether the account is real or not.

On a musl system without PAM, that borrowed hash can itself be the literal string *, which is the standard Unix convention for "this account can never log in with a password." Kültekin found that musl's crypt() caps its input at 256 bytes as a guard against CPU-exhaustion attacks, so any password between 257 and 1,024 bytes causes the hashing to fail and return * — which then matches the stored * exactly, and sshd lets the attacker in. The write-up describes testing around 17,600 login combinations across glibc and musl, with and without PAM, and with and without shadow-password variants, to isolate the collision.

Who is actually exposed

The Alpine Linux advisory, published the same day, says every Alpine release it checked is affected — versions 3.21 through 3.24 and the edge branch, plus older releases from 3.16 to 3.20 that no longer receive regular updates. A system is exposed if it runs OpenSSH on musl without PAM authentication and has PasswordAuthentication set to yes, which is Alpine's default openssh-server configuration. Other musl-based systems commonly used in embedded and IoT work, including OpenWrt, Buildroot and Yocto builds, share the same exposure if they are configured the same way. Systems using glibc, or using PAM to check passwords, are not affected.

The Hacker News reported that the flaw carries a CVSS v3.1 score of 8.1 ("high"). Alpine's advisory, published before a CVE identifier had been assigned, thanks Damien Miller and Darren Tucker of the OpenSSH project for the fix and the 10.6p2 release, Timo Teräs for help analyzing the issue, and Natanael Copa, who built and uploaded the corrected packages across every affected branch, including the unsupported ones.

Exploitation began within hours

Threat-intelligence firm Previdian told The Hacker News that it recorded the first exploitation attempt less than nine hours after the CVE was published, and confirmed successful root access on a honeypot running Alpine Linux and OpenSSH. Previdian's founder and chief executive, Ryan Dewhurst, said the attacker used oversized passwords to get past authentication and then ran reconnaissance commands — including id, uname and hostname — through non-interactive SSH sessions, from a single IP address that Previdian geolocated to Japan.

That speed is itself part of the story. OpenSSH's own release notes for 10.6p2 point to a pattern the project says it has observed repeatedly: a security bug found through AI-assisted analysis is often rediscovered independently by a different researcher within a short window, which the project says suggests that adversaries who do not report bugs could discover the same bugs too. The notes say OpenSSH is, for now, making more frequent releases to get fixes to users faster rather than batching them, and that the project continues to welcome AI-assisted vulnerability reports, particularly ones paired with human analysis, test cases and a proposed fix.

Why this matters beyond Alpine's own servers

Alpine Linux's small image size has made it one of the default base images for containers in continuing-integration pipelines, Kubernetes deployments and student coursework alike, so the exposure is not limited to people who think of themselves as running "a Linux server." Anyone building container images with FROM alpine that also run an SSH daemon with password authentication enabled inherited this bug by default, usually without ever choosing a musl libc or a PAM configuration explicitly.

For students and researchers working on systems security, the bug is a concrete example of why cross-library behavioral differences are worth testing directly rather than assuming: a single changed return value, three years before the vulnerable OpenSSH code even existed, combined with a defensive feature added for an unrelated reason, to produce an authentication bypass nobody had to introduce on purpose. For anyone currently running Alpine, OpenWrt, Buildroot or Yocto systems, the practical step is to update to OpenSSH 10.6p2 or the Alpine package versions listed in its advisory, or, failing that, to set PasswordAuthentication no immediately.