SSHole: the OpenSSH flaw that opens Alpine with a long password

On November 5 OpenSSH shipped an urgent 10.6p2 release. It fixes a flaw its finder, Özgün Kültekin of Wakefield, named "*sshole": on Alpine and other Linux systems built on the musl library, if the SSH server doesn't use PAM, any password between 257 and 1,024 characters opens the accounts that don't have a password at all. Damien Miller, who maintains OpenSSH, says in the release email that they learned about it the day before. That same evening Italy's cybersecurity agency ACN rated it critical; the CVE-2026-123158 record scores it 8.1 out of 10.

Why an asterisk opens the door

In /etc/shadow, an account with no password has an asterisk where the hash would be. When someone tries a password, sshd passes it to crypt() and compares the result with what's in the file. The asterisk has no salt, so since 2016, with OpenSSH 7.3, sshd borrows one from another account: that way response times don't reveal which users exist.

musl refuses keys longer than 256 bytes, and when it fails it returns an asterisk (source). sshd compares asterisk with asterisk and lets you in. Passwords over 1,024 characters are thrown out by sshd itself, under a limit added in the same 2016 release against a different attack. The glibc used by Debian, Ubuntu and Red Hat returns something else on error, and with PAM that comparison never happens.

The fix is a few lines long: for the comparison to count, the stored field must be at least four characters. OpenSSH says it considers the root cause to be "outside sshd," meaning in musl.

Who is really exposed

Alpine's advisory requires four conditions at once. Any install nobody has touched meets two of them: Alpine's openssh-server package doesn't use PAM, and PasswordAuthentication is yes. Then you need an account with the asterisk, and another with a real password, meaning a hash starting with $5$ or $6$, which is where sshd takes the salt from.

The asterisk is there for users created with adduser -D to log in with a key only, and for the alpine user on cloud images, which becomes root through doas with no password. Root has one too, since about 3.16, but as long as the default PermitRootLogin prohibit-password stays in place it can't log in with a password. Accounts locked with ! are out of scope.

A freshly installed Alpine with no password set anywhere can't be attacked: it becomes vulnerable as soon as someone sets one, even just for the console. The official alpine Docker image doesn't include sshd, and cloud images configured through cloud-init already have passwords switched off. That leaves virtual machines and servers running Alpine, and containers where someone installed sshd to get into them.

Debian marked the CVE as "unimportant". A scanner that only looks at version numbers will still flag it on every Debian, Ubuntu or Red Hat server, where it can't be exploited.

What we know about attacks

Previdian, a company that sells threat data, saw the first attempt on its sensors less than nine hours after the CVE was published; the fix and Alpine's advisory had been public since that morning. Its page counted 13 attempts from 9 addresses as of November 6, and warns that this doesn't show whether the target was vulnerable or whether the attempt worked. Founder Ryan Dewhurst told Help Net Security they had confirmed root access on one of their honeypots running Alpine and OpenSSH. He didn't say how it was configured, and with default settings root can't log in with a password.

As of November 6 CISA hadn't added the flaw to its catalog of exploited vulnerabilities. We wouldn't wait for it to: the proof of concept is public in the researcher's repository, and exploiting the flaw only takes sending a long password to an account name you already know, such as alpine.

What to do on an Alpine server

1. Update and restart: apk upgrade -U -a, then rc-service sshd restart. Upgrading the package doesn't restart the process, and until you restart it the old sshd keeps answering.
2. If you can't update right away, turn passwords off: echo 'PasswordAuthentication no' > /etc/ssh/sshd_config.d/00-no-passwords.conf, then sshd -t && rc-service sshd restart. Alpine reads that folder from 3.19 on; for older releases the advisory gives a sed command. Keep your session open while you test a new login.
3. Check that it took: sshd -T | grep -i passwordauthentication must answer passwordauthentication no.
4. Search the logs for logins that shouldn't be there: grep 'Accepted password for' /var/log/messages. A password login as root, alpine or a key-only user is one of them. Alpine says that if you can't rule it out, treat the machine as compromised; what to do in the first hours is in our piece on the first 24 hours after a hack.

Don't change the asterisk to ! to be on the safe side: ! locks the account for keys too.

The version number misleads

On its stable branches Alpine didn't move to 10.6p2: it backported the fix into the version it already had. On Alpine 3.24 the fixed package is 10.3_p1-r2, and ssh -V still prints OpenSSH_10.3p1. Look at the package version instead, with apk list --installed 'openssh*', and compare it with the advisory's table.

We also read the check script the researcher published. Its other checks are well done: musl, PAM, accounts with the asterisk, a hash to borrow the salt from. On the version, though, it only treats an sshd reporting 10.6p2 or later as fixed, so on an updated Alpine 3.24 with passwords on and both kinds of account it answers "EXPOSED." It's a false alarm, and whoever runs it in a hurry ends up hunting for an update they've already installed.

The embargo lasted one day

Kültekin says he built sshd in every combination, with and without musl, with and without PAM, and threw about 17,600 odd logins at it using swarms of AI agents. In his email Miller explains the rush: they've seen AI agents rediscover a bug within hours more than once, and a long embargo now mostly helps attackers. Between the announcement and the first attempt Previdian saw, half a day went by, less than the 24 hours the Cyber Resilience Act will give software makers to report an exploited flaw.

Do you have an Alpine server reachable from the internet, and can't say in a minute whether it accepts passwords? Write to us and we'll look at it together.