OpenSSH hole let hackers in with a random long password

A decade-old interaction between OpenSSH and the musl C library let attackers log in to passwordless accounts on Alpine Linux’s default SSH server using one over-long password. The headline blames OpenSSH as a whole, but the evidence points to a narrow combination of conditions, a dispute over whose bug it is, and attackers who arrived within days of the fix.

A password bypass in OpenSSH, disclosed on 5 November 2026, lets an attacker log in to accounts that should never accept a password by sending one string between 257 and 1,024 characters long. It is tracked as CVE-2026-123158 and nicknamed SSHole. It reaches only OpenSSH servers on Linux systems that use the musl C library without PAM, which includes the default SSH server package on Alpine Linux, and it needs a second local account that has a real password. Inside that footprint the attack is trivial: Alpine says it takes one connection and works every time. The security firm Previdian says its first observed attempt arrived less than nine hours after the CVE was published, and on 9 November the US agency CISA added the bug to its catalog of exploited vulnerabilities with a federal patch deadline of 12 November.

The 10 November episode of Security Now, a weekly TWiT podcast hosted by Steve Gibson and Leo Laporte, builds a show around the bug under the title “The hole in OpenSSH”. Its listing calls the flaw a ten-year-old authentication bug hiding in plain sight and adds, in a parenthesis, that the bug is rather wonderful. The episode carries advertising from four sponsors, and nothing on the listing ties them to OpenSSH. This article describes the episode only as its listing does and tests the framing against the people who found, fixed and attacked the bug.

A password check that compares an error to an asterisk

When sshd is built without PAM, the Linux login framework, it checks a password itself: it hashes the attempt with the C library’s crypt() function and compares the result with the account’s entry in the shadow file. Accounts with no password store a single asterisk there. Because that entry is too short to hold a salt, sshd borrows the salt from another account’s hash and hashes the attempt anyway, so response times do not reveal which usernames exist. OpenSSH adopted the habit in 2016 after CVE-2016-6210, a timing flaw that a researcher found by sending very long passwords, and iTnews points to the irony that the fix for a long-password flaw produced a long-password bypass.

musl’s crypt() refuses SHA-256 and SHA-512 passwords longer than 256 bytes and, on failure, returns a string instead of an error. The string is an asterisk. An error and a locked account look identical to the comparison, so sshd sees an asterisk on both sides and lets the login through. The attacker needs the name of such an account, one other account whose hash starts with $5$ or $6$ to supply the salt, and password login switched on, which is the OpenSSH default.

A narrow footprint under a broad headline

The episode’s title points at OpenSSH as a whole, and the evidence is far narrower. OpenSSH developer Damien Miller wrote that the problem does not exist on non-Linux systems, on Linux with glibc, or on Linux systems that check passwords through PAM. Help Net Security adds Debian, Ubuntu, Fedora, Dropbear and OpenBSD to the safe list, ThreatDefence cites a Red Hat statement that RHEL is not affected, and iTnews notes that Alpine containers are at risk only if they run sshd, which most do not.

Inside Alpine the risk concentrates in a few places. Root ships with an asterisk, but OpenSSH’s default PermitRootLogin setting blocks password logins for it. The more exposed case is the official tiny-cloud images from 3.18.11 to 3.24.3, whose default alpine user has no password and a passwordless doas, so a login becomes root. Those images are safe on first boot and turn exploitable once any account gets a $6$ hash, for example from a console password. Özgün Kültekin, the Wakefield researcher who reported the bug, also lists OpenWrt, Buildroot and Yocto as musl systems worth checking, though OpenWrt matters only where an administrator replaced the default Dropbear with OpenSSH.

Attackers arrived before the weekend

Previdian founder Ryan Dewhurst told Help Net Security that the company’s sensors logged a first attempt less than nine hours after the CVE was published and that one attacker reached root on a honeypot running real Alpine Linux. ThreatDefence’s reading of GreyNoise data puts the first successful exploitation on 7 November at 00:46 UTC and counts 17 successful chains from six addresses by 9 November. The same listing records attackers reading the shadow file with doas, adding their own SSH keys and, in one case, installing Python and a remote agent.

The counts differ because the sensors and the dates differ. SecurityWeek reported 20 attempts from 13 attacker addresses in 9 countries between 6 and 8 November, while Help Net’s report, three days earlier, counted eight attempts from a single address. The security firm watchTowr said only botnets and crypto miners had picked the bug up so far. CISA listed the flaw as exploited on 9 November, with a deadline of 12 November that binds US federal agencies and nobody else.

The age of the bug depends on which half you count

The listing’s ten-year figure holds for the OpenSSH half. The 2016 timing fix is where the flaw became reachable, and iTnews calls it a decade-old edge case. The musl half is older: according to Kültekin’s account relayed by Help Net, musl’s crypt() has refused long SHA-crypt passwords and returned an asterisk on failure since 2012. musl maintainer Rich Felker explains that the limit exists because SHA-256 and SHA-512 password hashing takes time proportional to the square of the password length, so some cap is needed.

The bug survived because neither component looked wrong alone. Kültekin found it by building sshd in every combination of glibc, musl, PAM and no PAM and throwing about 17,600 unusual logins at each build. Only the musl build without PAM accepted a login it should have refused. He did not work alone: he says he had swarms of AI agents running the tests.

Two projects, two answers on whose bug this is

OpenSSH’s release notes call the fix a workaround, say the root cause lies outside sshd, and ship it anyway because sshd is where the bug can be exploited. Felker goes further on the musl mailing list: he calls the case “an erroneous use by the caller”, because nothing guarantees that crypt()’s output for a hash taken from a different account will differ from the failure string. Any failure string that lands in the shadow file will match, and the convention for locked accounts is the same asterisk musl uses for failure.

Both sides changed something. OpenSSH 10.6p2 now fails the login whenever the target account’s stored hash is shorter than four characters, which no real hash is. Felker proposed switching musl’s failure string to the more common two-character convention, which would no longer collide with a bare asterisk, and called a switch to returning an error an open question for the next release cycle. The sshd fix closes this bypass without settling the design question, and Felker himself says the token change does not prevent misuse. For an administrator the dispute changes nothing today, since the sshd patch or a single configuration line is what protects the host.

OpenSSH drops long embargoes after a one-day turnaround

The episode listing frames its stories as showing AI as both weapon and shield, and OpenSSH’s own statements give that line unusual support. Miller said the project learned of the problem the day before release and shipped as fast as possible because it had recently seen several cases of AI agents rediscovering bugs, sometimes within hours. He called long embargo periods a dangerous practice that mainly benefits attackers. The release notes add that the team now receives many AI-assisted security reports, many of them without security impact in a realistic threat model, and that OpenSSH will for now make more frequent releases instead of batching fixes.

Two limits apply. The attack-side link to AI rests on one firm’s judgement: Dewhurst said attackers are getting faster with AI and that the bug was trivial to exploit, but nothing in the sources shows how the first attackers worked. The discovery side is better documented, because the researcher described his own method. The embargo policy is the lasting change, and it is stated as a response to a pattern, not to this bug alone.

Checks that decide whether an Alpine host is exposed

The first fix is an update followed by a restart. Alpine’s advisory says upgrading the openssh package does not replace a running daemon, so sshd must be restarted before the patch takes effect, and Alpine has published fixed packages for every branch from 3.16 to edge. Hosts that cannot update yet can set PasswordAuthentication to no once key logins are confirmed to work, which both Alpine and Miller advise.

The second check is for a break-in. Alpine tells administrators to search the system log for lines reading “Accepted password for” an account that has no password, such as alpine, root or a key-only user, and to treat a machine as compromised if a login cannot be ruled out. A password login to a key-only account is the signal. Cloud instances from the affected tiny-cloud images need an update or password login turned off, and container images that run sshd need a rebuild and redeploy, because pulling a new base image does not change running containers, according to ThreatDefence. Debian, Ubuntu and RHEL users have nothing to patch for this bug. Anyone running Buildroot or Yocto images should ask whether sshd was built with PAM. No source reviewed counts how many internet-facing systems meet every condition, and that number is the biggest open question.

Author:
Jan Bielik
CEO & Founder of Webiano Digital & Marketing Agency

This article is an original analysis supported by the sources cited below

Security Now 1104: The hole in OpenSSH
The video under examination, published by TWiT on 10 November 2026, whose title and subtitle frame the bug as a hole in OpenSSH.

Security Now: The hole in OpenSSH
TWiT’s episode page, which supplied the date, hosts, description, the ten-year-old claim and the sponsor list.

Security advisory: openssh-server password authentication bypass
Alpine’s own advisory with the conditions, affected branches, fixed packages, tiny-cloud exposure and detection advice.

OpenSSH 10.6p2 released
Reproduces Damien Miller’s announcement and the full 10.6p2 release notes, including the embargo and AI statements.

OpenSSH password auth bypass analysis
musl maintainer Rich Felker’s step-by-step analysis, his view that the caller erred and the planned musl changes.

OpenSSH flaw exploited in the wild just hours after disclosure (CVE-2026-123158)
Previdian’s nine-hour observation, the researcher’s account of 17,600 test logins and the list of unaffected systems.

Hackers Exploiting ‘SSHole’ Authentication Bypass in OpenSSH
Exploitation counts from Previdian, the watchTowr observation about botnets and the mechanism in brief.

Lightweight Linux distros vulnerable to *sshole password bypass
Independent explanation of the 2016 CVE-2016-6210 origin, the cloud image risk and the container caveat.

Hackers log in to Linux systems using any long password: CISA confirms active exploitation of SSHole
Corroborates the CISA listing and the 12 November federal deadline.

OpenSSH Password Auth Bypass: CVE-2026-123158
Vendor advisory confirming affected versions, the CVSS 8.1 rating, the CISA listing and the mitigation.

Alpine OpenSSH CVE-2026-123158: Patching and Hunting
Timeline, GreyNoise counts, attacker behaviour, the Red Hat statement and remediation steps for containers and cloud images.

This article was prepared with the assistance of artificial intelligence tools. The content underwent expert human review, and Webiano Digital & Marketing Agency assumes editorial responsibility for its final version and publication.