The Star Came Back: How a 1980 Unix Marker Became a 2026 SSH Bypass

On 5 November the OpenSSH team shipped 10.6p2, rated critical, for a login bypass that needs no exploit code, no memory corruption and no clever payload. You send a password longer than 256 characters to an account that has no password at all. You get in.

The flaw does not live in a forgotten corner of the internet. It lives in Alpine Linux, and therefore in a very large share of the container images your team pulls every week. If you have a key-only deploy user on an Alpine host with password auth left at its default, that account is not key-only any more.

Here is the part that should hold your attention: the accounts at risk are the ones you hardened.

What actually happens on the wire

Without PAM, sshd checks passwords itself. It takes the attempt, hashes it with crypt(), and compares the result to the stored field in /etc/shadow. A normal account stores something like $6$abc$k2P9...: an algorithm marker, a salt, a hash.

An account with no password stores a single *. That marker is not a hash and no password can ever match it. It has been that way since 1980, when Bill Joy put a * in the password field of the daemon account in 3BSD. Fifteen words of intent, still respected by every Unix on earth.

But a * is too short to hold a salt. So sshd borrows one: it takes the salt from another local account that has a real hash, hashes your attempt anyway, and compares. That borrow arrived in July 2016 as the fix for CVE-2016-6210, a timing oracle that let attackers enumerate valid usernames. Wasting the same amount of time on a nonexistent user was the whole point.

Now add 2012. musl, the C library Alpine is built on, changed crypt() so a failed call returns a single * instead of NULL, because too many programs never checked for NULL and simply crashed. Twenty days later musl capped sha256 and sha512 hashing at 256 bytes to stop denial-of-service attacks that feed the hasher enormous inputs.

Put those decisions in one process and the logic inverts:

1. The stored field is *.
2. Your password is 257 bytes or more, so crypt() refuses it and returns *.
3. sshd compares * with *.
4. It matches.

The error path is the door. Not a bug in the sense of a stray memory write, but a chain of four individually reasonable decisions, made decades apart, that now agree on the wrong answer.

Who is actually exposed

Alpine's advisory lists four conditions that must all be true:

• The server runs openssh-server, which is built without PAM, or runs openssh-server-pam with UsePAM no.
• PasswordAuthentication is yes, which is the OpenSSH default.
• An account has * in its password field, meaning no password is set.
• At least one other local account has a $5$ or $6$ hash.

That last condition is the quiet one. One account anywhere on the box with a modern password hash is enough to expose every account without one. On Alpine, accounts with no password include key-only users created with adduser, directory users arriving through musl-nscd, and root, which has shipped as root:* since Alpine 3.16.

Root is still shielded by PermitRootLogin prohibit-password unless you changed it. That shield means less than it sounds if an exposed account can escalate: the tiny-cloud images from 3.18.11 through 3.24.3 give the alpine user passwordless doas. Those images are safe at first boot and become open the moment any $6$ hash exists on the machine, which happens the first time an admin sets a console password.

The attacker needs network access, an account name, and a password between 257 and 1,024 bytes. The advisory says it succeeds on every attempt, over a single connection. No attacks using it had been reported when the fix shipped.

Not affected: non-Linux systems, glibc-based Linux, anything checking passwords through PAM, systems with PasswordAuthentication no, accounts locked with ! rather than *, containers that do not run sshd, and machines where no account carries a $-style hash. OpenWrt is largely fine because it defaults to Dropbear. Buildroot and Yocto deserve a look.

What to do today

The researcher who found it, Özgün Kültekin of Wakefield, published a full write-up at sshhole.com, and the nickname that stuck is not printable in a client deck. The remediation is boring and fast:

1. Update. Run apk upgrade -U -a, then rc-service sshd restart. Upgrading the package does not restart the running daemon, so the restart is not optional. Fixed point releases: 3.21.10, 3.22.8, 3.23.8 and 3.24.4. Branches back to 3.16 are past end of support but got packages too.
2. If you cannot patch immediately, turn password logins off. Confirm your key login works in a second session before you close the first. Set PasswordAuthentication no, run sshd -t, restart sshd. Verify with sshd -T | grep -i passwordauthentication.
3. Hunt. Grep /var/log/messages for Accepted password for against an account with no password: alpine, root, a key-only deploy user. Review doas usage, recently created users, modified authorized keys and file changes.
4. If you cannot rule out a login, treat the machine as compromised. The advisory is that direct, and it is right.

If you build OpenSSH yourself, 10.6p2 contains the change: sshd now refuses a match when the stored field is shorter than four characters. OpenSSH calls that a workaround and points at musl for the root cause.

Why the fix arrived in one day

No CVE identifier had been assigned when the advisory went out. Damien Miller was explicit about why his team moved at this speed: long embargoes are dangerous now, and mainly helpful to attackers, because the project has recently watched AI agents rediscover the same bugs, sometimes within hours.

Read that sentence twice, because it is the real story. The vulnerability is a 2016 design choice colliding with a 2012 library change. The response time is set by machines that read code all night and can re-derive a finding from a partially public trail in a working day. Embargo windows used to be measured against human attention. They are now measured against inference throughput.

What this means for your team

Three things, and only the first is about OpenSSH.

Audit the base image, not just the application. Most teams we meet can name their framework version and cannot name their libc. Alpine's ubiquity in containers means musl's defaults are your defaults, and musl made a defensible choice in 2012 that became an authentication bypass in 2026.

Write down your assumptions so they can be falsified. "Key-only accounts cannot be logged into with a password" was true, widely believed, and copied into a hundred internal runbooks. It stopped being true without anyone editing the runbooks.

Assume your quietest account is the one that matters. The account with no password, no shell history, no owner on the org chart. In this flaw it was the target, and one stray $6$ hash anywhere on the box turned it into the front door.

Patch, reboot, verify. Then ask the question that actually pays: which of our assumptions has not been re-tested since the machines got faster than us?