A bug let attackers into some home routers with any password over 256 characters long

Any string longer than 256 characters can act as the password on certain OpenSSH servers, and the server accepts it as correct. Security researcher Ozgun Kultekin of Wakefield found the flaw, which carries the name SSHhole, and it reaches home routers because the affected software also runs on OpenWrt. Patched releases began appearing on Nov. 5.

Tech news in one quick read: Get the most interesting stories in startups, tech and programming, each with a short TLDR, in one daily email from TLDR.

Subscribe to TLDR →

We may earn a commission if you sign up.

The exposure depends on how the software was built, not on the router brand. Only OpenSSH compiled against the musl C library, and without PAM, is vulnerable, and the target must be an account with no usable password, such as root or a key-only user. A router that runs a different SSH server, or that never exposes SSH to the network, sits outside the risk.

The musl crypt() return value behind the bypass

Risky Business News reported that the bug “allows attackers to log into accounts with any random string with more than 256 characters,” and its author, Catalin Cimpanu, called the problem very bad. The researcher’s own write-up at sshhole.com traces it to a 2012 decision in musl: when the library added SHA-512 password hashing that year, it capped input at 256 bytes and made crypt() return an asterisk for anything longer, instead of returning a null error.

An asterisk is also what the shadow file stores for an account that has no password. OpenSSH hashes the submitted attempt, compares the result to the stored field, and finds a match, so the login succeeds. The sshhole.com page says the working range is passwords between 257 and 1,024 characters, and it names glibc systems, PAM-based setups, Dropbear and OpenBSD as unaffected.

The Alpine Linux advisory published on Nov. 5 adds the conditions that must line up: sshd built without PAM (or run with UsePAM set to no), PasswordAuthentication left at its default of yes, an account whose password field is an asterisk, and at least one other account holding a SHA-256 or SHA-512 hash. Official Alpine cloud images fit that profile through a default “alpine” user that has passwordless doas, which makes the bypass effectively a root login.

Systems outside that profile are safe from this particular route. The advisory lists PasswordAuthentication set to no, openssh-server-pam running with UsePAM set to yes, accounts locked with an exclamation mark, and machines with no dollar-style password hashes as not affected. Alpine also flagged its official tiny-cloud images from 3.18.11 to 3.24.3, which ship the passwordless-doas user, as the most obvious cloud exposure.

OpenWrt, Buildroot and Yocto: which routers are in play

SSHhole reaches beyond Alpine because several embedded build systems share the same C library. Risky Business News lists Alpine, OpenWrt, Buildroot and Yocto among the musl-based builds, and says every musl OpenSSH release from the past decade is affected. OpenWrt is the firmware many people flash onto consumer routers, which is how a Linux server bug becomes a question about the box in a hallway.

Most routers will not be vulnerable, because the combination is narrow. OpenWrt installations commonly use the lightweight Dropbear server, which the researcher reports as unaffected, and OpenSSH has to be installed deliberately. A router is exposed only if its owner or vendor installed OpenSSH on musl, left password login on, and allows SSH connections from the local network or, worse, the internet. Vendor firmware built on Buildroot or Yocto is harder to judge from outside, since the SSH server choice is rarely documented.

Cimpanu wrote that he expects serious exploitation within weeks and worries that router and internet-of-things patches will lag behind the fix. Security users on Bluesky reacted with disbelief: one, Xe, urged anyone on musl to patch immediately, and another, Jason Kikta, joked that no AI is needed when a keyboard mash will do.

Kultekin reported the issue through Wakefield, and the sshhole.com page dates the discovery to November 2026. The speed of the response is notable: the OpenSSH project shipped a corrected release about a day after learning of it, and Alpine had packages for every branch back to 3.16 on the same day its advisory appeared.

OpenSSH 10.6p2 and the stopgap setting

The fix is OpenSSH 10.6p2, released about a day after the project learned of the problem, according to Risky Business News. Alpine rolled the correction back through its supported branches: edge now carries openssh 10.6_p2-r0, and the older branches received patched builds from 3.16 through 3.24, including releases that no longer get regular updates.

Alpine’s instructions are to run apk upgrade -U -a and then restart sshd with rc-service sshd restart, because upgrading the package does not replace the daemon already running in memory. Anyone who cannot update immediately can set PasswordAuthentication to no in the sshd configuration and restart it, after confirming that key-based login works so the change does not lock out the administrator.

The project page also advises checking logs for signs of earlier abuse, pointing to a detection repository on GitHub. A log line in which root logged in with a password on a box where root has none is the telltale sign. BleepingComputer, which reported that the flaw is dubbed “sshole”, framed it as a way into accounts where password login was supposed to be off.

One thing remains unsettled: neither Risky Business News nor the Alpine advisory gives a CVE identifier, and no vendor has said how many shipped router or embedded firmware images combine OpenSSH, musl and password login. Until firmware makers publish their own statements, the count of exposed home devices is unknown.

This article was produced with the assistance of AI and reviewed by Morning Overview editors prior to publication.

Tech news in one quick read: Subscribe to TLDR →

We may earn a commission if you sign up.