SSHole Is an OpenSSH Flaw That Lets Attackers In With a Password Nobody Set

On November 5, OpenSSH shipped version 10.6p2 with a fix for a bug that should not have existed. The flaw, CVE-2026-123158, nicknamed SSHole by the researcher who found it, lets an attacker log into an account that was deliberately set up to reject every password, just by sending a password nobody set. Proof-of-concept exploit code appeared about four hours after the fix. The first successful break-in followed within two days.

The bug is rated 8.1 High on CVSS, and the reason it matters is not the score. It is the blast radius. Alpine Linux, the lightweight distribution that powers a huge share of containers and cloud images, ships an OpenSSH server built exactly the way this bug needs: musl libc, no PAM. If you run Alpine servers or containers with SSH exposed, this one is yours to patch.

How the SSHole OpenSSH vulnerability works

The mechanics are almost comically small. On Linux, an account that should never accept a password login has its password hash set to an asterisk character. The asterisk is not a password; it is a placeholder that can never match a real hash. SSHole breaks that assumption.

When an attacker sends a password between 257 and 1,024 characters long, the password-hashing process fails in a way that produces the same asterisk value stored for the account. The comparison passes, and the attacker is in. The researcher who found it, Ozgün Kültekin, named it SSHole, and the fix shipped in OpenSSH 10.6p2 on the day the flaw went public.

The hole has been open since 2016. It was created by a fix for a different SSH flaw, one that let attackers guess valid usernames from response times. A decade-old repair introduced a subtle error in how overlong passwords are handled on systems without PAM, and nobody noticed until now. The musl maintainer says the fault is not in musl itself but in a caller using it wrongly, which is the kind of blame-shifting that matters less than the patch.

Exploitation started within hours

Threat intelligence firm Previdian says the first exploitation attempt hit its sensors less than nine hours after the CVE was published, and one of those attempts reached root on a honeypot running real Alpine. GreyNoise, which runs decoy servers built to be attacked, recorded the first successful exploitation in the wild on November 7 at 00:46 UTC, about 40 hours after the fix shipped, and has since logged 16 successful attack chains from 6 source IPs. SANS honeypots logged 232 long-password login attempts on November 5 and 713 on November 6.

Offensive security firm watchTower said on November 6 that it observed SSHole being exploited in attacks associated with botnets and cryptomining activity. Unverified proof-of-concept code is circulating on GitHub, and Previdian warns some of it may contain malware. No real-world victim has been publicly confirmed so far, and GreyNoise's own numbers are a warning rather than a census: 27.5 million port-22 scans and 20.1 million attempted SSH sessions, most of them mass scanning rather than confirmed attacks.

Who is affected and who is not

The affected combination is specific: OpenSSH before 10.6p2, running on Linux built with musl libc, with PAM disabled. Alpine Linux is the best-known example, because its default openssh-server is built exactly that way, and every branch from 3.16 through 3.24 plus edge is affected. Alpine's official tiny-cloud images add a twist: they ship an alpine user with no password and passwordless doas, so on a box where any other account has a password set, this bug can end in root.

Most mainstream servers are safe. Red Hat says none of its products are affected, because they build OpenSSH against glibc with PAM turned on. The same goes for Debian, Ubuntu, and Fedora, for PAM-based setups generally, and for the Dropbear SSH server. If your servers run a glibc distribution, you can stop reading and go back to work.

How to check and patch

Alpine shipped patched openssh packages on November 5 and backported the fix to every branch from 3.16 up, including branches already out of support. The fixed versions are edge 10.6_p2-r0, 3.24 10.3_p1-r2, 3.23 10.2_p1-r1, 3.22 10.0_p1-r11, and 3.21 9.9_p2-r1. Releases older than 3.16 get no fixed package, and security researchers found images on those releases exploitable in the lab. If you are still running one, the time to upgrade was yesterday.

The fix is short: update openssh to 10.6p2 or your distribution's backported package, then restart sshd so the patched version is actually running. As a workaround while you patch, set PasswordAuthentication no in sshd_config, which closes the password path entirely. Then check for signs of compromise: unexpected logins, unfamiliar authorized keys, and new processes or cron jobs you did not create.

The broader lesson is the one Japan learned the hard way this month. Japan declared a cyber emergency after a record breach wave, and the SMBC Consumer Finance breach exposed up to 320,118 borrowers. SSHole is a different kind of incident: a bug in infrastructure software that millions of machines share, disclosed and exploited within the same week. Patch it now, while the fix is easy and the headlines are still about honeypots.