The OpenSSH project released 10.6p2 on November 5 to address CVE-2026-123158, nicknamed “sshole”: a password-authentication bypass that lets a remote attacker log in to an account with no password set by submitting an overlong password. Alpine Linux, the base of a large share of container images, is the main affected platform. Scored CVSS 3.1 8.1 (High) by MITRE/NVD, the bug is credited to researcher Özgün Kültekin.

Technical details

The flaw affects OpenSSH builds linked against the musl C library and compiled without PAM, which is how Alpine packages openssh-server by default. In this configuration sshd’s password check ends up in the C library’s crypt() path. Accounts with no password set carry a locked or empty hash field. Reporting indicates that when the submitted password is long enough (reports cite thresholds between roughly 257 and 1,024 bytes), the comparison against that field wrongly succeeds, and authentication completes.

Preconditions for exploitation:

  • sshd is reachable by the attacker.
  • PasswordAuthentication yes is in effect. Alpine’s sshd default permits password auth unless the image hardens it.
  • The target account exists but has no password set. Cloud images often ship such accounts, for example a default alpine user that relies on key-only login.

The OpenSSH maintainers describe 10.6p2 as a workaround: they say the root cause lies outside sshd, in the platform’s crypt handling, so the release hardens sshd against the condition rather than fixing the library. Sources disagree on how deeply this has been root-caused, so follow the Alpine and OpenSSH advisories for the authoritative description.

Exploitation status

Reporting conflicts. The Hacker News reports attackers probing the flaw within hours of disclosure and gaining root on an Alpine honeypot. Other outlets state that no in-the-wild exploitation has been confirmed and that CISA’s SSVC assessment rates exploitation as proof-of-concept. Because the trigger is a single crafted login attempt and the details are public, treat it as exploitable now. Internet-wide scanning for exposed Alpine sshd is a near certainty.

Impact

Any internet-reachable Alpine host, container with sshd, or appliance image built on Alpine and musl without PAM that still allows password logins is at risk. A successful bypass yields a shell as the targeted user. If the account is root and has no password, that means full compromise. Debian, Ubuntu, RHEL and other glibc/PAM distributions are not affected in their default builds. Check minimal images and embedded firmware built on musl (OpenWrt-style builds, custom Buildroot images) that compile OpenSSH without PAM.

Mitigation

  1. Patch. Alpine published fixed packages for all supported branches from 3.16 onward plus edge. Stable branches carry backports, so sshd -V can still report an older version string, for example 10.3p1 on Alpine 3.24, while being fixed. Verify against the Alpine package changelog, not the banner.
  2. Restart sshd after upgrading, since the running daemon keeps the old code.
  3. Disable password authentication now if you cannot patch: set PasswordAuthentication no (and KbdInteractiveAuthentication no) in sshd_config, reload, and rely on keys.
  4. Audit passwordless accounts: awk -F: '($2=="" || $2=="!" || $2=="*"){print $1}' /etc/shadow. Remove or lock unneeded accounts and disable direct root login with PermitRootLogin no.
  5. Restrict exposure of port 22 with firewall rules, security groups or a bastion; do not expose container sshd publicly.
  6. Hunt. Review auth.log/journald for successful password logins on key-only accounts, unusually long authentication payloads, and new SSH keys or users added after logins from unfamiliar addresses. Rebuild any host with an unexplained login rather than cleaning it in place.

References