Alpine advisory and OpenSSH 10.6p2 released November 5, 2026; coverage November 5 to 6, 2026
A Password Too Long to Fail: the SSHole Bypass Lets Long Passwords Into Locked Accounts on musl Systems
A password authentication bypass disclosed on November 5 affects OpenSSH servers built against the musl C library and run without PAM, with Alpine Linux as the common case. The finder, Ozgun Kultekin of Wakefield, named it SSHole. The mechanism is an interaction of three individually defensible choices: since 2012, musl's crypt function returns the single character * as its error token instead of failing, and it refuses passwords longer than 256 bytes; since 2016, OpenSSH, fixing a username enumeration flaw, borrows a real account's salt when the target account has none; and a locked account's stored password field is exactly that character, *. Send any password of 257 to 1,024 bytes to such an account and the comparison matches. One connection, no retries, and a short wrong password still fails, which is why the bug survived about a decade. Five conditions must hold together: musl, no PAM, password logins enabled, at least one account stored as *, and at least one other account with a SHA-256 or SHA-512 password hash to borrow a salt from. Alpine's official tiny-cloud images from 3.18.11 through 3.24.3 ship an alpine user stored as * with passwordless doas, so a login there is effectively root once any password hash exists on the machine. Fixed Alpine packages are out for branches 3.16 through 3.24 plus edge, fixed images start at 3.21.10, 3.22.8, 3.23.8, and 3.24.4, and upstream the fix is Portable OpenSSH 10.6p2. Upgrading the package does not restart the running daemon. No CVE identifier appeared in the November 5 Alpine or OpenSSH notes; one later tracker listing associates the flaw with CVE-2026-123158, which the primary notes do not confirm. Detectify said on November 5 that it was not aware of public reports of exploitation.
Executives
This flaw has no CVE in the primary advisories, which means scanner-driven programs may show green across an exposed fleet. The exposure test is a configuration question, not a scan result: Alpine or another musl system, OpenSSH without PAM, password logins on. Alpine is common in cloud images and containers, so the inventory question reaches hosting providers and small virtual machines nobody owns centrally. Ask for the configuration answer per system, and treat any reachable machine whose logs cannot rule out a password login to a locked account as compromised until reviewed, which is Alpine's own guidance.
CIO / CISO
Prioritize internet-reachable SSH on musl systems, starting with Alpine cloud images from 3.18.11 through 3.24.3 that have ever had a password set on any account. Closure requires three pieces of evidence: the fixed package installed, the sshd daemon restarted, since the upgrade alone leaves the old code running, and a log review for Accepted password entries naming accounts that have no password. Where patching must wait, turning password authentication off closes the hole entirely; confirm key logins work first. Extend the question to device and router suppliers building on OpenWrt or Buildroot, which both updated their OpenSSH packages on November 5; OpenWrt's usual Dropbear server is not affected.
Engineers
Check the package version, not the SSH banner: patched Alpine systems can still report an older OpenSSH version string. Restart sshd after upgrading and verify with a login. Then hunt: search authentication logs for Accepted password for root, alpine, or any account whose shadow field is *, and check whether passwordless doas or sudo rights turn that login into root. Remember the negative space when you scope: glibc systems, PAM builds, Dropbear, OpenBSD, and containers that never run sshd are outside this flaw, and a fresh image with no password hash anywhere is not yet exploitable.
Everyone (non-IT)
If you run a small server, a home lab machine, or a cloud instance on Alpine Linux and you can sign in to it over SSH, update OpenSSH and restart the SSH service, or ask whoever set it up to do so. If you do not know what Alpine or SSH are, this story almost certainly does not reach you. The memorable detail is the shape of the bug: a password that was far too long worked better than a correct one, on accounts that were never supposed to accept a password at all.