A password string between 257 and 1,024 bytes was enough to log in over SSH to certain Linux accounts configured without a password. Disclosed on November 5, 2026, the flaw affects OpenSSH servers that use the musl library and meet a specific combination of settings; OpenSSH released fix 10.6p2.
The vulnerability, dubbed *sshole, was discovered and reported by security researcher Özgün Kültekin of Wakefield. Alpine Linux confirmed that its packages were affected and released updates for current and older branches. No CVE identifier had been assigned to the flaw in the advisories published that day.
A long password could match the asterisk in /etc/shadow
On Linux, an account can be denied password access if its corresponding field in /etc/shadow contains an asterisk (*). For the affected accounts, OpenSSH compared the result of calculating the submitted password with that field. The problem occurred when the server performed this check without PAM and musl's crypt() function encountered an excessively long password.
According to Alpine's advisory, musl returns * as an error indicator when a password exceeds 256 bytes. Since that same character appears in the field for a passwordless account, the result could match and sshd would grant access. For this to happen, the attacker had to know the name of an account with that field and submit a password between 257 and 1,024 bytes long.
Alpine describes the attack as possible with a single connection, without needing to repeat attempts. The distribution also notes that the machine must have at least one other local account with a password hash beginning with $5$ or $6$. A single account with one of these hashes is enough to expose passwordless accounts if the other conditions are met.
The flaw does not allow attackers to bypass authentication for accounts with a valid hash. The problem affects the password-checking path without PAM and accounts whose stored field is *; it is not a general bypass of any SSH password.
Conditions that leave a server exposed
Alpine lists four simultaneous requirements: running its openssh-server package, compiled without PAM, or openssh-server-pam with UsePAM no; having PasswordAuthentication enabled; having an account whose password field is *; and having at least one local account with a $5$ or $6$ hash.
Password authentication is enabled by default in the configuration described for Alpine. The scenario also includes accounts created to authenticate only with an SSH key, accounts using usermod -p '*', and certain users from directory services through musl-nscd, who may not have an entry in /etc/shadow.
The root account appears as root:* in Alpine's base image from approximately version 3.16 onward. OpenSSH's default setting, PermitRootLogin prohibit-password, prevents direct root access using a password. However, this barrier does not prevent an attacker from reaching root if they first access another vulnerable account that allows privilege escalation, for example through doas.
Alpine's advisory includes tested installations from versions 3.21 to 3.24 and edge among those affected, as well as branches 3.16 to 3.20, which no longer receive regular updates. The scope is not limited to Alpine: Kültekin also identified OpenWrt, Buildroot, and Yocto as musl-based systems worth checking. In OpenWrt, the default SSH server is Dropbear, which is not affected; the risk arises if OpenSSH is installed.
Systems using glibc, such as Debian, Ubuntu, and Fedora, are not affected, nor are systems that authenticate through PAM with UsePAM yes, or installations with PasswordAuthentication no. It also does not affect containers that do not run sshd, accounts locked with ! in the password field, or machines without accounts with the specified types of hashes. Alpine adds that its cloud images configured through cloud-init set PasswordAuthentication no.
tiny-cloud images: from first boot to root access
The most serious case described by Alpine affects official tiny-cloud images in qcow2, VHD, and AMI formats, from versions 3.18.11 through 3.24.3. They include a passwordless alpine user who is allowed to use doas without a password. They are not vulnerable through this route on first boot, but become vulnerable once a $6$ hash exists on the system.
This hash can appear when an administrator sets a password for the console or when user data adds an account with hashed_passwd. Once the conditions are met, the attacker can log in as alpine and use doas to become root. Alpine specifies that images built from 3.21.10, 3.22.8, 3.23.8, and 3.24.4 already include the fixed package; images from earlier versions require updating each running instance or disabling password authentication.
The distribution's advisory explains that the fix was also released for older branches: version 3.21 reached end of support on November 1, 2026, but Alpine distributed fixed packages from 3.16 onward. For the listed branches, the fixed OpenSSH versions are 10.3_p1-r2 in 3.24, 10.2_p1-r1 in 3.23, 10.0_p1-r11 in 3.22, 9.9_p2-r1 in 3.21, 9.7_p1-r6 in 3.20, 9.6_p1-r3 in 3.19, 9.3_p2-r4 in 3.18, 9.1_p1-r7 in 3.17, and 9.0_p1-r6 in 3.16. For edge, the listed version is 10.6_p2-r0.
OpenSSH and Alpine release the fix
OpenSSH 10.6p2 prevents sshd from accepting this match. Packages in Alpine's stable branches include a patch for the same issue. Updating the package does not replace the sshd process that is already running: Alpine asks users to restart the service after updating. Its recommendation is to run apk upgrade -U -a and then rc-service sshd restart.
If the patch cannot be installed immediately, Alpine recommends disabling password authentication by setting PasswordAuthentication no and restarting sshd. The distribution warns that users should first verify that SSH key access works and keep the current session open until they have tested a new connection. For installations that cannot update or apply this change, CERT-FR recommends disabling the SSH service.
“set PasswordAuthentication=no or disable SSH for these systems IMMEDIATELY.”
— Damien Miller, OpenSSH project
CERT-FR published its initial alert on November 5, 2026, and classified the risk as a security policy bypass. Its summary considers exploitation trivial when the conditions are met and asks users to check whether systems are configured vulnerably. The organization also lists disabling password authentication as the preferred mitigation until the fix can be installed.
What to check in the logs
Alpine asks users to search /var/log/messages for sshd lines containing the text Accepted password for accounts that should not accept passwords, such as alpine, root, or public-key users. It also recommends reviewing the use of doas, recently created accounts, files, and authorized keys on exposed machines.
CERT-FR suggests first identifying accounts whose field in /etc/shadow is * and checking whether there are records of accepted logins for them. If it cannot be ruled out that one occurred, Alpine says the machine should be treated as compromised. On vulnerable images, a login to alpine followed by the use of doas may imply root access.
Kültekin traces the origin of the problem to a 2016 OpenSSH change intended to fix user enumeration associated with CVE-2016-6210. To prevent timing differences from revealing whether a username was valid, OpenSSH began calculating passwords even for accounts without a usable hash. The flaw persisted in this interaction with musl, whose crypt() function returns an asterisk when the length limit is exceeded.
The researcher says he found the flaw with AI agents that ran around 17,600 authentication tests using different OpenSSH configurations, malformed hashes, and excessively long passwords. Damien Miller said the OpenSSH team learned about the issue earlier that week and quickly released the fix. The Hacker News also quotes his explanation that the project views lengthy embargoes as a risk, because AI agents have independently found similar flaws, sometimes within hours.
On the *sshole page, Kültekin describes several earlier clues that came close to the issue, including a Debian change related to the value returned by glibc and a security review that fixed pick_salt() four days before his discovery. He does not claim that those events had detected the sshd vulnerability. As of the November 5 advisories, the flaw still had no CVE identifier, and no real-world attacks had been reported.
Sources: BleepingComputer, RedesZone, alpinelinux.org, Alpine Linux, Özgün Kültekin / Wakefield, CERT-FR, The Hacker News
