Alpine Linux published a security advisory on November 5 for an OpenSSH authentication bypass that lets an attacker log into accounts explicitly configured to reject passwords. The bug, tracked as CVE-2026-123158 and nicknamed *sshole, is rated 8.1 high, and the flaw behind it dates to 2016. A fixed OpenSSH, 10.6p2, shipped the same day, and Alpine backported it to every branch back to 3.16, including releases it no longer supports.

The mechanism is an argument between three components that each behaved reasonably alone. On musl libc — the C library Alpine uses instead of glibc — the crypt() function refuses passwords longer than 256 bytes and returns the string *. Linux stores * in /etc/shadow to mean an account has no usable password hash. In 2016, OpenSSH added behaviour to avoid leaking which usernames exist, which on musl systems without PAM can hash using settings taken from another account, even when the target account has no valid hash. Send a password of 257 to 1,024 bytes to an account whose shadow entry is , and the comparison succeeds: equals *. Authentication passes.

The preconditions are specific but not exotic. The server must run musl without PAM, as Alpine's openssh-server package does by default; password authentication must be enabled; the targeted account must have * rather than ! in shadow; and at least one other account on the box must have a real password. Where those all hold — key-only users, root on Alpine from 3.16 on, and the default alpine user on Alpine's AWS and Azure images, which can run doas without a password — one login attempt is enough, and on those cloud images it amounts to root. The flaw was found by Özgün Kültekin of Wakefield, who according to published research built sshd in every combination of glibc, musl, PAM and no PAM and threw roughly 17,600 unusual login attempts at each; every build behaved until musl-without-PAM said yes.

Debian, Ubuntu and Fedora are not affected on this path, nor are PAM-based servers, hosts with PasswordAuthentication no, accounts using !, containers without an sshd, or Dropbear. That list matters: much of the internet's "is my box at risk" traffic is really about whether the deploy runs an sshd inside an Alpine container image that CI built months ago.

The fix rejects stored hashes too short to be real, so a failed hash can no longer pass as a match. Patching the package is not the same as patching the running process — sshd has to be restarted — and rebuilding images matters more than upgrading a host: a fixed base image is the only thing that stops the flaw from returning with the next deploy. If you cannot update yet, key-only authentication with PasswordAuthentication no closes it. To check history, search logs for "Accepted password" against accounts that should have no password; if you find one, treat the machine as compromised.

Sources