How one asterisk opened a door in OpenSSH: the *sshole bug, explained

Since 1980, a star in a Unix password file has meant one thing: nobody gets in with a password. This week we learned that on some Linux systems it also meant the opposite. Type a password of 257 characters, any 257 characters, and the door opens. The bug is called *sshole, the star is part of the joke, and no single person wrote it. Three sensible fixes built it between them, over ten years.

The bug in one minute

Many people who run servers log in with a key and switch passwords off for the account. The usual way to do that is to put a * in the account's password field in /etc/shadow. A real entry there is a long scrambled hash. A star isn't a hash of anything, so no password can ever match it. That is the whole idea.

Now the four steps that break it, on a system that uses the small C library musl and has no PAM, the login layer that would normally do this work:

1. You try to log in with a very long password. Anything from 257 to 1,024 bytes. Past 1,024, sshd gives up by itself.
2. sshd hashes it anyway. The account has no real hash, so sshd borrows the settings from another account that does.
3. musl refuses. Its SHA-256 and SHA-512 code won't touch a password over 256 bytes, and it reports the failure by returning a string: *.
4. sshd compares the two. The stored field says *. The "hash" says *. They match, so you are in.

We read musl's source to see it with our own eyes. It is all there in crypt_sha512.c: #define KEY_MAX 256, then a line near the end of the file that ends in return "*";. An error message and a locked door happened to be spelled the same way.

Three fixes, one hole

The best part of this story is that every step along the way was somebody doing the right thing. The history comes from the write-up by Özgün Kültekin of Wakefield, who found the bug.

• 1980 BSD puts a * in the password field of the daemon account. It is not a valid hash, so it can never match.
• 2012 Fix one. Programs keep crashing because they don't check whether crypt() failed. musl starts returning "*" on failure instead of nothing. The same year it adds SHA-512 with a 256-byte limit, so that huge passwords can't be used to wear out a server.
• 2016 Fix two. Attackers could work out which usernames exist by timing how fast sshd said no (CVE-2016-6210). To close that, OpenSSH hashes the password even when an account has no real hash. Now the failing crypt() and the star finally meet.
• 2019 Alpine's Docker images turn out to have no root password at all (CVE-2019-5021). Alpine locks root with !, which also stops key logins on systems without PAM.
• 2022 Fix three. Alpine 3.16 changes root to *, so keys work again. Root now has exactly the field the bug needs.
• December 2024 Someone on the musl mailing list notices that BusyBox passwd fails on a 257-character password. The symptom is on the table. Nobody connects it to SSH.
• 30 October 2026 OpenSSH changes the very function that picks the borrowed salt, for another reason. Kültekin points out the bug sat four lines further down.

Kültekin's way in was brute patience. Different builds of sshd (glibc, musl, with and without PAM) got about 17,600 odd login attempts, with AI agents helping to run them. All builds agreed on every login except one: musl without PAM.

Whose bug is it?

Nobody wants it. OpenSSH's release notes say: "We consider the root cause of this bug to be outside sshd, but it is exploitable via sshd and can be avoided there." musl's maintainer Rich Felker wrote on the same day: "It is my position that this is not a bug in musl just an erroneous use by the caller."

Both have a point, and that's why it survived so long. Each side's behaviour makes sense on its own, and the bug lives in the gap between them. OpenSSH fixed it anyway, and the fix is almost funny in how small it is. A real hash is long, so sshd now refuses anything shorter than four characters:

#define MIN_PASSWORD_HASH_LEN  4

ret = encrypted_password != NULL &&
    strlen(pw_password) >= MIN_PASSWORD_HASH_LEN &&
    strcmp(encrypted_password, pw_password) == 0;

Felker also says the way musl does this is something the project has "been wanting to change for a while now", and that it "very likely will be changed in the upcoming release cycle".

Are you affected?

What some reports get wrong

• "Root from one connection on any default Alpine." Root does have the star, but OpenSSH's default PermitRootLogin setting refuses password logins to root. It takes an admin who set that to yes. The more realistic route to root is sideways, through another account.
• "Every Alpine cloud image is open." Official images from 3.18.11 to 3.24.3 do ship an alpine user with a star and passwordless doas, which really is root. But the bug needs a $6$ hash elsewhere on the machine, so a fresh image isn't exploitable. Setting a console password is enough to change that. Images where cloud-init turns password logins off are not exposed.
• "OpenWrt routers are hit." Default OpenWrt runs Dropbear, not OpenSSH. Only people who swapped in openssh-server need to check, which is also true for GL.iNet routers built on it.
• "Critical" or "high"? OpenSSH calls it critical. The CVE record says 8.1, high, with the attack complexity marked high. CISA's assessment of 5 November marks it as not automatable. If your server meets every condition, the score doesn't matter: it is one attempt, and it works every time.

Nobody has published a count of exposed servers, and we didn't find one worth repeating. Any number you see should show its method.

One day, not ninety

Security bugs are usually fixed in private for weeks before anyone is told. This one wasn't, on purpose. Damien Miller of OpenSSH wrote in his release mail that the team "learned of the problem yesterday", and explained why they rushed: "we have recently observed multiple cases of rapid bug rediscovery by AI agents, sometimes within hours, and so now consider long embargo periods to be a dangerous practice that primarily benefits attackers."

That sentence may outlast the bug. The release notes add that the team has "received a large number of security bug reports, many of which are findings from AI models or made with AI assistance". Here's how the clock ran, in UTC:

• 4 Nov The OpenSSH team hears about the bug. Miller commits the fix at 21:18.
• 5 Nov OpenSSH 10.6p2 is out, with a warning to musl users to "stop reading and set PasswordAuthentication=no or disable SSH for these systems IMMEDIATELY". Alpine ships packages and its advisory the same day.
• 5 Nov, 14:14 The details go to the oss-security mailing list.
• 5 Nov, 15:07 Felker's advisory reaches musl users.
• 5 Nov, 15:46 The CVE is published.
• 5 Nov, 17:30 First public proof of concept (Previdian's timeline).
• 6 Nov, 00:05 Previdian's sensors see the first attempts: 8 hours and 19 minutes after the CVE.

Are attacks really happening?

Yes, probably, on a small scale so far, but the evidence comes from one place. Previdian's founder Ryan Dewhurst told Help Net Security that the first attempt came within nine hours and that an attacker got root on a honeypot running real Alpine and OpenSSH, then ran id, uname and hostname to look around. "This vulnerability was particularly trivial to exploit, which significantly shrunk that timeline," Dewhurst said.

That evidence is thin, though. Help Net reported eight attempts from one address in Japan. Previdian's public page now shows six attempts from four addresses in Switzerland, Iran, Japan and Singapore, and says these are attempts, without showing which succeeded. It doesn't say how the honeypot was set up, and root can only be reached directly if PermitRootLogin allows it. Orca, Ethiack and Safe Security said no attacks had been reported when they wrote, and at the time of writing the flaw is not on CISA's list. Its EPSS score, which estimates the chance of attacks over the next 30 days, is about 1%.

We also looked at SSH scanning across the internet. SANS ISC's sensors logged 962,097 records on port 22 on 5 November, below the median of about 1.5 million a day since the end of September. So no surge, but that proves little. Port 22 is hammered all day every day, and a few dozen targeted logins would vanish in that noise.

What to do

1. Find out if you run it. ldd $(command -v sshd) | grep -i musl shows musl builds, and sshd -T | grep -E 'usepam|passwordauthentication' shows the two settings that matter. Don't forget appliances and images that someone built years ago.
2. Update and restart. On Alpine: apk update && apk upgrade, then rc-service sshd restart. Rebuild container images that run sshd.
3. Don't trust the version number. Alpine patched older versions without moving to 10.6: the fixed packages are 10.6_p2-r0 (edge), 10.3_p1-r2 (3.24), 10.2_p1-r1 (3.23), 10.0_p1-r11 (3.22), 9.9_p2-r1 (3.21), 9.7_p1-r6 (3.20), 9.6_p1-r3 (3.19), 9.3_p2-r4 (3.18), 9.1_p1-r7 (3.17) and 9.0_p1-r6 (3.16). A scanner that only looks for 10.6p2 will flag patched machines.
4. Can't update today? Set PasswordAuthentication no, run sshd -t, restart, and keep your current session open until you've tested a key login. This is worth doing anyway.
5. Look for a visit. Search /var/log/messages for Accepted password for on accounts that have no password. The logs don't record how long a password was, so a password login to a key-only account is your signal. Then check doas use, new users and authorized_keys files.
6. If you can't rule out a login, treat the machine as compromised. That is Alpine's advice, and it means rebuilding, not cleaning.

Don't run the proof-of-concept or "checker" scripts going around GitHub. Previdian marks them all as unverified and warns that they could contain malware.

Why this is on Blackout Map

This is a software flaw, not an outage, and it won't show on our map. It stays small because the conditions are narrow. But it is worth your time for what it shows: the bug was hiding in the space between two projects that each did their job, and the time from public fix to first attack is now measured in hours. Our Security watch tracks the flaws that are really being used. Read also Can a software flaw take the internet down?

Sources

• OpenSSH: release notes for 10.6p2
• Damien Miller: urgent security release: 10.6p2 (openssh-unix-dev)
• OpenSSH: the fix ("avoid password authn bypass")
• Alpine Linux: OpenSSH password authentication bypass (conditions, fixed versions, cloud images)
• Rich Felker: Advisory for OpenSSH+musl users and Rob Landley's reply on Dropbear
• oss-security: "sshole": password authentication bypass
• Özgün Kültekin: write-up (history, testing)
• musl: crypt_sha512.c
• CVE-2026-123158 (description, CVSS 8.1, CISA's assessment)
• Previdian: CVE-2026-123158 and Help Net Security: OpenSSH flaw exploited in the wild just hours after disclosure
• Safe Security, Orca Security and Ethiack (exploitation status when they wrote)
• The Cyber Sec Guru (OpenWrt and Dropbear) and GL.iNet forum (a user's test)
• SANS ISC DShield: port 22 (CC BY-NC-SA 4.0)