OpenSSH's *sshole Bug Let Any Password Over 256 Characters Into Passwordless Alpine Accounts — and Bots Got There First

A security researcher has disclosed a quietly bizarre authentication bypass in OpenSSH that lets attackers log into accounts which should never accept a password at all — by simply typing a password longer than 256 characters. The flaw, nicknamed "*sshole" by its discoverer Ozgun Kultekin of Wakefield, has existed in some form for roughly a decade and was fixed in OpenSSH 10.6p2 on November 5 as CVE-2026-123158, rated 8.1 on the CVSS scale.

The mechanics are an unlucky collision of two old design choices. Passwordless accounts — root, key-only deployment users, LDAP users — store a single asterisk in place of a password hash. In 2016, OpenSSH changed sshd to hash any submitted password even for accounts without a usable hash, a timing-side-channel fix for CVE-2016-6210 meant to stop attackers from guessing which usernames exist. Meanwhile musl, the lightweight C library behind Alpine Linux, has since 2012 returned an asterisk as its error signal when crypt() is handed a password over 256 bytes. On a musl system without PAM, sshd compares that error asterisk to the stored asterisk, sees a match, and grants access.

The exposure is broad because the vulnerable combination is the default on Alpine Linux, the foundation of countless Docker images and cloud servers. Alpine's official AWS and Azure images ship an "alpine" user with no password and passwordless doas privileges — meaning an attacker who reaches the SSH port can escalate straight to root. OpenWrt, Buildroot, and Yocto-based systems are also worth checking. Systems on glibc — Debian, Ubuntu, Fedora — and any setup using PAM are not affected, nor are OpenBSD and Dropbear.

The discovery process is its own story. Kultekin built sshd in every combination he could think of — glibc, musl, with and without PAM, shadow and no shadow — and threw roughly 17,600 unusual login attempts at the builds, using swarms of AI agents to run the test matrix. "People don't really look at that stuff, they look at the crypto," he wrote, describing how he dug into the boring parts where sshd talks to libc.

Attackers moved faster than most defenders. Threat intelligence firm Previdian reported that its sensors saw the first exploitation attempt less than nine hours after CVE publication, and confirmed successful root access on a honeypot running real Alpine Linux and OpenSSH — eight attempts, all traced to a single Japan-based address, running reconnaissance commands over non-interactive SSH sessions. Proof-of-concept exploits have appeared on GitHub, though Previdian warns some posted exploits may themselves be malicious. CISA has not yet added the flaw to its exploited-vulnerabilities catalog.

The fix in OpenSSH 10.6p2 makes sshd reject stored password hashes too short to be legitimate, and Alpine has published patched packages for every supported branch back to 3.16. Administrators must restart sshd after upgrading — the running process keeps the old behavior until restarted. Until then, the OpenSSH project's advice is blunt: set PasswordAuthentication no on musl-based systems or disable SSH entirely, and audit logs for "Accepted password" entries against accounts that have no password, treating any hit as a compromise.

The wider lesson is about how bugs are found now. A decade-old latent flaw, invisible to manual review and to fuzzers aimed at crypto code, surfaced when AI agents made it cheap to brute-force a huge configuration-and-input matrix. Expect more findings of this shape: old, boring, interface-level bugs that only someone testing at machine scale would notice.