OpenSSH Patches SSHole Bypass as Attackers Gain Root in Under Nine Hours

OpenSSH underpins encrypted remote administration across Linux fleets, appliances and container images. On November 5, 2026, the OpenSSH Project released Portable OpenSSH 10.6p2 with a critical security workaround for Linux systems using musl without PAM. The flaw, tracked as CVE-2026-123158 and nicknamed SSHole, lets an attacker who can reach an SSH port log into certain passwordless accounts without knowing a password.

Exposure is narrow but severe. It affects musl based systems with PAM disabled and requires an account whose /etc/shadow password field is an asterisk plus another local account with a $5$ or $6$ hash. sshd can then accept a password of 257 to 1024 bytes. Alpine Linux, OpenWrt, Buildroot and Yocto are affected, along with many Alpine based Docker images.

Wakefield researcher Ozgun Kultekin traced the collision to two old decisions. Since 2012 musl's crypt function returns an asterisk on failure. Since 2016 sshd borrows another account's salt and hashes a supplied password when an account has no usable hash. Passwordless accounts also store an asterisk, so an oversized password can produce the same value. Kultekin tried about 17,600 unusual logins on test builds.

The fix came fast. Previdian said its first observed attempt arrived less than nine hours after publication and confirmed root access on a honeypot running real Alpine Linux and OpenSSH. That compresses the patch window from weeks to hours, especially for minimal images rebuilt infrequently and appliances ignored between firmware updates.

Key Facts

SecurityWeek reported on November 6 that OpenSSH shipped emergency patches for a high severity authentication bypass that accepts very long passwords. The flaw carries a CVSS score of 8.1 and stems from a misinterpretation of whether a string is meant to be a password hash. It affects sshd on musl based Linux with PAM disabled. Any password from 257 to 1024 characters can open certain accounts, including root on Alpine, OpenWrt, Buildroot and Yocto.

Alpine Linux stated in an advisory published on November 5 that every version it checked, 3.21 through 3.24 plus edge, was affected, along with unsupported 3.16 through 3.20. Fixed packages include edge 10.6_p2-r0, 3.24 at 10.3_p1-r2, 3.23 at 10.2_p1-r1, 3.22 at 10.0_p1-r11, 3.21 at 9.9_p2-r1 and 3.20 at 9.7_p1-r6. Point releases 3.21.10, 3.22.8, 3.23.8 and 3.24.4 contain the fix. Upgrading does not replace the running daemon, so administrators must run apk upgrade -U -a and then rc-service sshd restart.

Help Net Security reported on November 6 that Previdian counted eight attempts, all from 89.116.89.18 in Japan, and confirmed root access. The attacker used oversized passwords and ran id, uname and hostname over non interactive SSH sessions. Previdian added the bug to its known exploited list, while CISA has not added it to the KEV catalog.

StepSecurity reported on November 6 that a lab reproduced the bypass on Alpine 3.24 and on a Docker container with OpenSSH 10.3_p1-r1. A 256 character password was rejected, while 257, 300 and 1023 characters were accepted and returned uid=1000(alpine). An account with a real SHA-512 hash was immune. A long password sent first was rejected; the bypass succeeds on a second or later attempt, so one shot scanners can report a vulnerable host as safe. PAM was confirmed as a mitigation, and version based checks produced false positives because Alpine backports the fix without changing its version string.

Alpine's advisory said the attacker needs a passwordless account marked with an asterisk and another account with a $5$ or $6$ hash, then sends 257 to 1024 bytes. Tiny-cloud images 3.18.11 through 3.24.3 ship an alpine user with an asterisk and passwordless doas. They are safe on first boot but become exploitable once any $6$ hash exists. To check for compromise, Alpine says to look for sshd lines reading Accepted password for an account with no password, and to review doas use, new users, files and authorized keys. If a login cannot be ruled out, treat the machine as compromised.

Analysis

What this really means is that the barrier to exploitation has fallen below the effort needed to patch. SecurityWeek reported on November 6 that Detectify co-founder Fredrik Almroth said Shodan lists around 22 million systems with SSH open on port 22, and because each attempt is a single connection an attacker can afford to try all of them. A flaw that works every time and needs no retries turns a vast population of embedded devices and minimal servers into a tractable target list. The nine hour gap is not only a failure of advisory process. It shows that scanning and weaponization now run at publication speed.

The OpenSSH Project said in release notes issued on November 5 that it has received many security reports, many of them AI findings or made with AI assistance, and has seen an AI identified bug later discovered independently by another researcher. It said adversaries who do not report bugs are likely able to find them too. It will make more frequent releases for now instead of batching fixes. SecurityWeek reported on November 6 that OpenSSH developer Damien Miller said the team learned of the problem the previous day and was releasing as fast as possible because of rapid rediscovery by AI agents, sometimes within hours. Long embargo periods, he argued, mainly benefit attackers.

The defensive lesson is that banners and one shot scans are not proof of safety. StepSecurity reported on November 6 that a host with patched Alpine package 10.3_p1-r2 still reported OpenSSH_10.3p1 and that a community script called it exposed even though the attack was rejected. Administrators should run apk info -v openssh-server and compare the output with the vendor's fixed version list. They must restart sshd after upgrading, because a patched binary on disk does nothing for a process still running old code. For containers, the image is often the unit of exposure, and cached layers can preserve the vulnerable package.

The scope should be stated precisely. Systems using glibc, including Debian, Ubuntu and Fedora, are not affected. PAM enabled setups, Dropbear and OpenBSD are not affected either. That is good news and argues against treating this as a universal OpenSSH catastrophe. The bad news is that the affected pattern is common where patching is hardest to observe: Alpine containers, OpenWrt routers, Buildroot firmware and Yocto products. The bug is a collision between a libc behavior and an account convention, not a cryptographic break, which makes it easy to underestimate during triage.

Why It Matters

Containers are the likeliest exposure for most teams. Images built or pinned before November 5, cached continuous integration layers, internal registry copies and mirrored APK packages keep the bug until rebuilt or upgraded. A team can patch a base image and still deploy a stale derivative if build cache or registry retention preserves the old layer. Tiny-cloud images add a twist: they are safe at first boot but become exploitable once a $6$ hash appears, so a later configuration change can silently activate the flaw.

Detection is concrete but easy to miss. The signature is a failed password for an account followed by an accepted password for the same passwordless account in the same session. That can look like a legitimate key only login if nobody checks the shadow entry. Alpine's guidance to review doas use, new users, files and authorized keys is a reminder that root access on a honeypot is not the end of the story. An attacker who logs in without a password can persist, and an operator who cannot rule out a login should treat the machine as compromised.

The disclosure debate matters beyond this CVE. OpenSSH's shift to more frequent releases acknowledges that AI assisted bug discovery is changing the tempo of research. If independent rediscovery can happen within hours, a long private embargo protects only defenders who already know about the issue, while adversaries searching on their own may find it anyway. That does not make immediate disclosure harmless. It does mean that patch adoption speed, inventory accuracy and restart discipline are now part of the security boundary, not administrative afterthoughts.

Next Up

The immediate priority is to inventory Alpine, OpenWrt, Buildroot and Yocto systems running OpenSSH without PAM and with password authentication enabled, then upgrade to the fixed package for their branch and restart sshd. Its absence from CISA's KEV catalog does not make that optional, because Previdian has confirmed root access in the wild and added the bug to its known exploited list. Organizations should also check for the failed then accepted pattern and review any passwordless account showing a successful password login.

OpenSSH has signaled that more frequent releases are now part of its model, and the 10.6p2 notes begin deprecating scp's -R flag and warn that support for old platforms requiring root privilege for PTY allocation, such as SCO OpenServer 5 and QNX 6, will be removed in a future release. The next update cycle is not a one off cleanup. It is a test of whether patch automation, image rebuilds and daemon restarts can keep pace with disclosures measured in hours.