sshole Vulnerability Lets Attackers Bypass Alpine SSH Login

A newly disclosed sshole vulnerability lets attackers log into certain Alpine Linux and other musl-based SSH accounts that were meant to block passwords. Alpine Linux published a security advisory on Nov. 5, 2026 after OpenSSH shipped version 10.6p2. No CVE identifier had been assigned when Alpine wrote that advisory.

How Does The sshole Vulnerability Work?

OpenSSH, the software that runs SSH servers, is often built without PAM, a common Linux login framework, on Alpine. When password checks skip PAM, sshd hashes the attempt with the C library crypt() function. On musl, the lightweight C library Alpine uses instead of glibc, crypt() returns the string "*" if the submitted password is longer than 256 bytes.

Accounts with no password set store exactly "*" in /etc/shadow, including many key-only users. If the box also has at least one real $5$ or $6$ password hash, an attacker who can reach SSH can send a 257 to 1,024 byte password and match that "*" field in one try. Researcher Özgün Kültekin documented the issue as present since about 2016 in the sshole project on GitHub.

Which Alpine Linux SSH Setups Are Exposed?

You are exposed only when all of these line up: musl-based OpenSSH without PAM (Alpine's normal openssh-server package), PasswordAuthentication yes, an account whose password field is "*", and another account with a SHA-256 or SHA-512 style hash. Official tiny-cloud images ship an alpine user with passwordless doas, so a successful login can escalate to root once any password hash exists on the machine.

Systems with UsePAM yes, PasswordAuthentication no, locked "!" shadow fields, or no $ style hash are not affected. glibc distros and containers that never run sshd are out of scope. Related SDN coverage includes earlier Linux risk stories such as Linux kernel vulnerabilities.

How Do You Patch sshole On Alpine?

Alpine says to run apk upgrade -U -a, then restart sshd with rc-service sshd restart. Upgrading the package alone does not replace the running daemon. Fixed packages cover edge and branches back through 3.16, including 3.21.10, 3.22.8, 3.23.8, and 3.24.4. If you cannot update yet, set PasswordAuthentication no and restart sshd after confirming key login still works.

Check /var/log/messages for "Accepted password for" lines on accounts that should have no password. If you cannot rule out a login, treat the host as compromised. Defensive AI tooling context is covered in our GPT-6 Cyber report.

Our Take

This is a classic interaction bug: a library error string that matched a "no password" marker. Alpine cloud fleets should treat Nov. 5 as a forced OpenSSH restart day, not a quiet package bump. Key-only accounts were never sealed while PasswordAuthentication stayed on. Adjacent research is in our Claude Linux exploit note.

Item	Detail
Name	sshole vulnerability (OpenSSH + musl)
Password length	257 to 1,024 bytes
Fix	OpenSSH 10.6p2 / Alpine patched packages + sshd restart
Mitigation	PasswordAuthentication no
CVE at advisory time	Not assigned