SSHole: OpenSSH Authentication Bypass on musl Linux

SSHole is an authentication-bypass vulnerability disclosed on 2026-11-05. On affected musl-based Linux systems, OpenSSH accepts an oversized password for an account whose /etc/shadow password field is *, a marker intended to prevent password login. The flaw does not reveal or bypass a valid account password; it turns a library error return into a match against the no-password marker. ¹

Mechanism

The bypass requires three components to line up:

1. musl’s crypt() returns * when hashing fails. One failure case is a password longer than its 256-byte limit; the error string was chosen to be unmatchable with a real password hash. ²
2. OpenSSH’s mitigation for the CVE-2016-6210 username-enumeration timing leak performs password hashing even when an account has no usable salt. For a stored field too short to contain a salt, sshd borrows another account’s salt, making the invalid-user path take a realistic amount of time. ³
3. When sshd is built without PAM, it compares that crypt() result directly with the stored field. A 257–1024-byte attempt makes musl return *, which exactly matches a no-password account’s stored *; the comparison succeeds and sshd accepts the login. ⁴

The target machine must also have another local account with a $5$ or $6$ password hash for sshd to borrow. One such account makes every otherwise reachable * account exploitable. The incident is therefore a sentinel collision: an error value and a deliberately invalid password hash became identical in a comparison path that assumed they could never meet. ⁵

Exposure

All of these conditions must hold:

• sshd runs on musl libc, as on Alpine, OpenWrt, Buildroot, or Yocto.
• Authentication does not use PAM. Alpine’s openssh-server package is built without it; openssh-server-pam is also affected with UsePAM no.
• PasswordAuthentication yes is active.
• At least one account has * as its password field and another local account has a $5$ or $6$ hash.

Systems using glibc, PAM-enabled authentication, or PasswordAuthentication no are outside this path. Accounts locked with ! are also outside it. Ordinary containers that never run sshd do not expose the vulnerability merely by using a musl-based image. ⁶

Alpine’s official tiny-cloud images from 3.18.11 through 3.24.3 deserve particular attention. Their alpine user has a * password field and passwordless doas; once another $6$ hash exists on the machine, a remote attacker can obtain that user’s shell and elevate to root. OpenSSH’s default PermitRootLogin prohibit-password separately protects the root account unless it has been changed, but it does not protect the alpine account. ⁷

Repair and detection

OpenSSH 10.6p2, released 2026-11-05, works around the bug in sshd. The maintainers place the root cause outside OpenSSH while accepting that sshd exposes it and can block it there. Alpine shipped the same repair in stable-branch packages back to 3.16. ^{8 9}

Alpine’s fixed point releases are 3.21.10, 3.22.8, 3.23.8, and 3.24.4. Its advisory directs administrators to run apk upgrade -U -a and then rc-service sshd restart; upgrading the package alone leaves the old daemon running. Where an immediate update is impossible, setting PasswordAuthentication no and restarting sshd closes the path. Key login should be tested before making that change. ¹⁰

For detection, Alpine recommends inspecting /var/log/messages for Accepted password for an account that has no password, then reviewing doas use, new users, files, and authorized keys on exposed machines. A successful password login for such an account is anomalous. If that login cannot be ruled out, the advisory says to treat the machine as compromised. ¹¹

Discovery method

Özgün Kültekin reported building twelve sshd variants across libc, PAM, and shadow configurations and running roughly 17,600 malformed or oversized login attempts with agent assistance. The musl-without-PAM configuration was the divergent case. The OpenSSH release notes also note a broader pattern: AI-assisted reports are increasingly finding bugs that another researcher later discovers independently, which strengthens the case for rapid human triage and proposed fixes rather than dismissing the reports by origin. ^{12 13}

Related

• ssh — the OpenSSH client and transport hub
• unix-password-hash-formats — valid modular-crypt fields and the special */! markers
• etc-shadow-weak-permissions — exposure of the password database itself, a separate failure mode
• negative-controls — comparison conditions used to isolate an unexpected result

Sources

• Alpine Linux 2026 — Security advisory: openssh-server password authentication bypass
• 2026 — Portable OpenSSH 10.6p2 release notes
• Özgün Kültekin 2026 — *sshole

Footnotes

1. Alpine Linux 2026 — Security advisory: openssh-server password authentication bypass ↩

2. Özgün Kültekin 2026 — *sshole ↩

3. Özgün Kültekin 2026 — *sshole ↩

4. Alpine Linux 2026 — Security advisory: openssh-server password authentication bypass ↩

5. Alpine Linux 2026 — Security advisory: openssh-server password authentication bypass ↩

6. Alpine Linux 2026 — Security advisory: openssh-server password authentication bypass ↩

7. Alpine Linux 2026 — Security advisory: openssh-server password authentication bypass ↩

8. 2026 — Portable OpenSSH 10.6p2 release notes ↩

9. Alpine Linux 2026 — Security advisory: openssh-server password authentication bypass ↩

10. Alpine Linux 2026 — Security advisory: openssh-server password authentication bypass ↩

11. Alpine Linux 2026 — Security advisory: openssh-server password authentication bypass ↩

12. Özgün Kültekin 2026 — *sshole ↩

13. 2026 — Portable OpenSSH 10.6p2 release notes ↩