No Password Set, Any Password Worked

On 5 November 2026 the OpenSSH project released Portable OpenSSH 10.6p2, an emergency fix for CVE-2026-123158, nicknamed sshole by the researcher who found it.

On affected systems, a long enough password authenticates an account that has no password at all. The scope is narrow: Linux built on the musl C library with PAM switched off, which in practice means Alpine and the things built on it.

Two things make this worth more than a patch note. The flaw inverts an assumption administrators rely on daily, and the way OpenSSH handled it marks a public break with how the industry has managed vulnerability disclosure for twenty years.

Are you affected?

Run this as root on each host:

sshd -T | grep -i -E 'passwordauthentication|usepam'

If password logins are off, or PAM is on, you are not affected. Stop here.

Everything else requires all four of these at once:

Debian, Ubuntu, Fedora and anything using PAM are out of scope, as are non-Linux systems and Dropbear. The exposure sits with Alpine Linux and the containers, routers and embedded devices built on it, plus Buildroot and Yocto systems.

Alpine's openssh-server package is built without PAM, and password logins are on by default, which is why it is the headline case.

Fix it

1. Update. OpenSSH 10.6p2, or your Alpine branch package: edge 10.6_p2-r0, 3.24 10.3_p1-r2, 3.23 10.2_p1-r1, 3.22 10.0_p1-r11.

2. Restart sshd. rc-service sshd restart on Alpine. Updating the package leaves the old code running until you do.

3. Rebuild container images rather than patching running containers, or the fix disappears on the next deployment.

4. If you cannot update right now, set PasswordAuthentication no and restart. This is OpenSSH maintainer Damien Miller's own instruction: "set PasswordAuthentication=no or disable SSH for these systems IMMEDIATELY."

Alpine releases before 3.16 get no fixed package. If sshd is exposed on one, migrating is the only route.

No attacks had been reported as of 5 November, and the flaw was not in CISA's Known Exploited Vulnerabilities catalogue.

What the bug does

The affected accounts are the ones with a single * in the password field, meaning no password was ever set. These are normally reserved for key-only login, so an administrator would assume password login is impossible.

Two reasonable behaviours collide.

When sshd runs without PAM, it checks passwords itself. For a * account it borrows another account's salt, so a failed login takes the same time as a real one. That was added in 2016 to stop attackers identifying valid usernames by timing.

Separately, musl's crypt() rejects passwords over 256 bytes and returns * as an error marker.

So a login attempt with a 257-character password makes musl return *. sshd compares that against the stored field, which is also *. They match. The length alone produces the match. The password does not need to resemble anything.

Any string between 257 and 1,024 characters works, on every attempt, in a single connection. Rated CVSS 8.1. Researcher Özgün Kültekin of Wakefield found it by running roughly 17,600 unusual logins across twelve sshd builds, using AI agents.

The fix makes sshd refuse a match when the stored field is shorter than four characters. OpenSSH describes this as a workaround for a root cause outside sshd.

The bigger story: OpenSSH has stopped waiting

A security fix is normally held back for weeks. The project tells Linux distributions quietly, they prepare their own packages, and everyone publishes on the same day. The practice is called an embargo, and it exists so that users are not left exposed while distributions scramble.

OpenSSH learned about this flaw on a Wednesday and shipped on a Thursday. Miller explained why: the project has recently seen multiple cases of rapid bug rediscovery by AI agents, sometimes within hours, and now considers "long embargo periods to be a dangerous practice that primarily benefits attackers."

The logic is straightforward once stated. An embargo protects users only while the secret holds. If an automated system can reconstruct a bug from a commit, a patch or a mailing list hint within hours, the secret does not hold, and the delay now protects only whoever moves fastest on the clue.

There is a neat symmetry here: AI agents found this bug, and AI agents are the reason it was not sat on.

Two caveats. Miller cites observed cases without detailing them, so this is an experienced maintainer's judgement rather than published evidence. And shorter embargoes cost something real, which is why Alpine's older branches and downstream image maintainers spent this week catching up.

We saw the same pressure three weeks ago with PHP2Shell, where an embargo broke early and exploitation began before public disclosure. If OpenSSH's judgement holds, the model that has governed vulnerability handling for twenty years is changing shape, and nobody has worked out yet whether that favours defenders or attackers.

The part worth keeping

A password field containing * means no password, and no password should mean no password login. On musl systems without PAM it meant any password over 256 characters. The bug lived in the gap between two components, each behaving sensibly on its own terms, with neither project considering the combination.

Everyone who disabled SSH password authentication years ago, as hardening guides have advised for a decade, was never exposed to this. A control that costs nothing turned a critical authentication bypass into a non-event.

That is worth more than the patch. The patch fixes this bug. Key-only authentication fixes the next one too.