OpenSSH 10.6p2 fixes musl password-auth bypass on Alpine

OpenSSH 10.6p2, released 5 November 2026, fixes an authentication-bypass flaw on musl-based Linux systems. On Alpine, OpenWrt and other musl builds compiled without PAM, an attacker can log into an account whose password login is disabled — the shadow hash set to * — by submitting an oversized password. No CVE was assigned at publication; the primary advisory is CERT-FR's CERTFR-2026-ALE-015, which rates exploitation "trivial" once the conditions hold, alongside the OpenSSH 10.6p2 release.

The researcher who found it, Ozgun Kultekin, nicknamed it "*sshole" and published details at sshhole.com; he says he surfaced it by running roughly 17,600 authentication tests with AI agents, as reported by BleepingComputer.

What's affected

• OpenSSH before 10.6p2, built against the musl C library with PAM disabled or absent, and password authentication enabled.
• Distributions and build systems that default to musl: Alpine Linux, OpenWrt, Buildroot, Yocto.
• Systems using glibc (Debian, Ubuntu, Fedora) or PAM for authentication are not affected, per both CERT-FR and BleepingComputer.

How it works

musl's crypt() returns the literal string * when it fails to hash an input. An account configured to refuse password logins stores * in its shadow field. If an attacker submits a password long enough to make crypt() fail — CERT-FR specifies a second password of more than 256 and fewer than 1024 characters — the returned * matches the stored *, and the comparison succeeds. The flaw does not bypass accounts that hold a valid password hash.

The elevated risk is on cloud images: Kultekin notes Alpine's AWS and Azure images ship a default alpine account with passwordless doas, so a bypass there can lead to root.

Exploitation status

No in-the-wild exploitation has been reported. CERT-FR describes exploitation as trivial once the preconditions hold, and BleepingComputer published administrator log checks rather than indicators of compromise.

Action checklist

1. Upgrade to OpenSSH 10.6p2. On Alpine: apk upgrade openssh, then restart sshd.
2. If you can't patch immediately, set PasswordAuthentication no in sshd_config and restart the service — this closes the vector. If neither is possible, disable the SSH service.
3. Audit accounts whose password is disabled and cross-check against successful logins:

grep '^alpine:' /etc/shadow
grep "Accepted password" /var/log/messages

A successful password login for an account whose shadow field is * is a red flag. 4. On Alpine cloud images, confirm the default alpine account's doas configuration and remove passwordless escalation where it isn't needed.

Context

musl's divergence from glibc has produced SSH edge cases before — the 2024 regreSSHion analysis found musl builds were not exploitable for remote code execution, the opposite direction from this bug. The pattern worth noting: libc behavior that OpenSSH's portable layer doesn't normalize keeps producing platform-specific authentication quirks. Operators who push the same sshd config across glibc and musl fleets shouldn't assume the security properties transfer.