SSHole (CVE-2026-123158): A 257-Byte Password Logs Into Alpine Accounts With No Password

Bit4Bit DFIR, practical notes for people who actually run the systems.

On November 5, 2026, OpenSSH shipped version 10.6p2 with a fix for a bug that should not have been possible: send a password between 257 and 1,024 bytes long to an affected server, and sshd lets you in to an account that has no password at all. No key. No valid credential. Just a very long string.

The flaw is CVE-2026-123158, nicknamed SSHole. It is rated CVSS 8.1 (High). Within about four hours of the fix going public, proof-of-concept exploit code was circulating. Within about 40 hours, GreyNoise recorded the first successful break-in on its decoy servers. On November 9, CISA added it to the Known Exploited Vulnerabilities catalog, with a fix deadline of November 12 for US federal civilian agencies.

This one is narrow, and that is exactly why it is dangerous. It only hits a specific configuration, so most servers are safe, but the ones that are exposed tend to be the ones nobody is watching.

What is actually affected

All of these have to be true:

• OpenSSH before 10.6p2
• Running on Linux built with musl libc, not glibc
• sshd built without PAM

In practice, that means Alpine Linux, plus containers and embedded devices built the same way. Alpine's default openssh-server package is built without PAM. Ubuntu, Debian, Fedora, and RHEL build sshd against glibc with PAM, so they are outside the scope of this CVE.

If you run Alpine containers with SSH exposed, you are in scope. That includes Docker images built from Alpine that ship an SSH daemon, and Alpine VMs and cloud images.

How the bypass works

The root cause goes back to 2016. A patch for an older bug (one that let attackers guess valid usernames from response timing) changed how sshd handles a failed password-hashing step. When hashing fails, the function returns a lone asterisk character, *.

Accounts with no password are also stored as * in the password field. That asterisk is supposed to mean "nobody can log in here with a password." But when you send a password of 257 to 1,024 bytes, the hashing step fails, returns *, and the two asterisks compare as equal. sshd concludes you supplied the right password.

The researcher who found it, Ozgur Kultekin of Wakefield, reported it through the oss-security mailing list. The upstream fix is OpenSSH 10.6p2, released the same day the flaw was disclosed.

One detail worth knowing: Alpine's official tiny-cloud images ship an alpine user with no password. On a box where any other account has a password set, this bug can end in root access.

How fast it moved

• Nov 5: Disclosure and OpenSSH 10.6p2 ship. Proof-of-concept code appears about four hours later. Exploitation attempts begin the same day. SANS honeypots logged 232 long-password login attempts on Nov 5.
• Nov 6: SANS honeypots logged 713 attempts. Previdians sensors recorded the first exploitation attempt less than nine hours after the CVE was published.
• Nov 7: GreyNoise recorded the first successful exploitation on its decoy servers, about 40 hours after the fix shipped. GreyNoise has since logged 16 successful attack chains from 6 source IPs.
• Nov 9: CISA added CVE-2026-123158 to the KEV catalog. Federal agencies must fix it by Nov 12.

No real-world victim has been publicly confirmed so far, and the overall volume is still small. But the gap between disclosure and exploitation was measured in hours, not days, which is faster than most scan-and-patch cycles.

What to do

If you run Alpine or musl-based hosts with SSH open:

1. Update to OpenSSH 10.6p2, or install your distribution's patched package. Alpine shipped patched packages for branches 3.16 through 3.24 and edge on Nov 5.
2. Restart sshd after updating. The old daemon keeps accepting the attack until it is restarted. On Alpine: apk update && apk upgrade openssh, then rc-service sshd restart.
3. Rebuild container images. Patching a running container is not enough. Any image built before the patch stays exposed until it is rebuilt and redeployed. Docker Hub's latest Alpine image was still shipping a pre-patch build days after the fix.

If you cannot patch immediately, set PasswordAuthentication no in sshd_config and restart sshd. Check that key-based login still works before you close your session.

If you run Debian, Ubuntu, Fedora, or RHEL, no action is needed for this CVE.

The DFIR angle

If you have exposed Alpine or container hosts, check for signs someone already walked in:

• Look for successful password logins on accounts that have no password set. Those should never exist.
• Check authorized_keys files for keys you do not recognize.
• Review auth logs for long-password login attempts around Nov 5 onward. SANS honeypot numbers suggest the scanning started immediately.
• Treat any container image built before Nov 5 as suspect until rebuilt. A patched host running an old image is still exposed.

The lesson here is an old one, and it keeps repeating: the systems that get hit are not the ones with the biggest attack surface. They are the small, quiet ones, the Alpine container someone spun up two years ago and forgot, running SSH because it was convenient at the time. Find those before someone else does.

Sources: OpenSSH 10.6p2 release notes, Alpine security tracker, CISA Known Exploited Vulnerabilities catalog (added Nov 9, 2026), GreyNoise and SANS honeypot observations, The Hacker News reporting on Previdians sensor data.