EPSS 0.98 Percent — and Nine Hours to Exploitation

On 5 November, OpenSSH released emergency version 10.6p2. It fixes CVE-2026-123158, named *sshole by its discoverer, Özgün Kültekin. The attack consists of sending a long password. That is all.

More precisely: a password between 257 and 1,024 characters. On an affected system that logs you into an account for which password authentication is disabled at system level — without knowing the password, because there is none.

The numbers, and why they contradict each other again

This is the third case in quick succession where the prioritisation signals point the wrong way — and the clearest. In the N-able case the score was zero with no exploitation observed. For the WeChat worm there was no catalogue entry at all. Here the score sits at one percent while the flaw is being exploited.

The automatable: no assessment is hard to follow. The attack is a connection with a long string. Any brute-force bot already hammering SSH ports around the clock needs to add exactly one entry to its password list.

And the sources disagree. Several advisories, as reviewed on 7 November, state that no exploitation has been confirmed. Previdian, by contrast, reports a first attempt within nine hours and confirmed root access on an Alpine honeypot, across eight attempts from a source geolocated to Japan. Both can be true at once — one is vendor telemetry, the other an advisory with a cut-off date. For practical purposes the distinction is moot: a public PoC plus a trivial attack produces scanning, whether anyone reports it or not.

How three sensible decisions became an auth bypass

The bug is in none of the components involved. It emerges from three changes made across fourteen years, each correct on its own terms.

2012, musl. The developers cap password length at 256 bytes so attackers cannot tie up the server hashing oversized passwords. At the same time, the hashing function returns an asterisk on failure. The same asterisk Unix has used since the 1980s to mark accounts no password should ever match.

2016, OpenSSH. For accounts whose password field offers no salt, another account's salt is borrowed — so attackers cannot infer which usernames exist from response timing.

2022, Alpine. The password field for root is set to an asterisk so SSH key logins keep working.

Now send an oversized password to a passwordless account: the hash attempt fails and returns an asterisk. sshd compares that with the asterisk in the account's password field. They match. The login succeeds.

The CWE classification captures it: CWE-394, Unexpected Status Code or Return Value. An error value that happens to look like a valid one.

Who is affected — and who is not

Every condition has to hold at once:

• sshd is linked against musl, not glibc
• it is OpenSSH, not Dropbear
• OpenSSH runs without PAM — or as openssh-server-pam with UsePAM no
• password authentication is enabled
• the attacker knows the name of a passwordless account
• and at least one account with a real SHA-crypt hash exists, to borrow the salt from

Not affected, therefore: Debian, Ubuntu, Fedora and RHEL — they use glibc and build OpenSSH against PAM. Dropbear is not affected either, according to musl's maintainer. Accounts locked with ! are also out of scope.

Affected: Alpine Linux 3.16 through 3.24 and edge, OpenWrt installations where OpenSSH was installed instead of the default Dropbear, and Buildroot or Yocto systems with TCLIBC=musl.

On the official Alpine cloud images for versions 3.18.11 to 3.24.3, the default alpine account is passwordless and holds passwordless doas. Those images are still safe on first boot — they become exposed the moment an administrator sets a password on any other account, because only then does the salt exist that the chain requires.

The container point, with the necessary caveat

Alpine is the most widely used base image for containers. The obvious panic follows — and it is overdone.

A typical application container runs no sshd. No SSH service, no attack path. What is affected are containers where someone deliberately installed an SSH server and published port 22. That is not the normal case, but nor is it rare: build agents, jump containers, development environments, prebuilt marketplace images, and anything created under the heading of "so we can get in quickly".

The honest framing is therefore not "every Alpine container is vulnerable" but: every Alpine-based host or container running sshd needs checking. The rest is an inventory question.

What to do

1. Patch — and restart sshd.

apk upgrade -U -a && rc-service sshd restart

The restart is not optional. A package update does not replace the running process. Update without restarting and you remain vulnerable while holding a patch level that says otherwise.

Alpine has shipped packages for every branch back to 3.16, including unsupported ones.

2. If patching cannot happen immediately: disable password authentication and move to keys. Alpine, OpenSSH and musl all recommend it, and it closes the hole completely.

3. Hunt retrospectively. Search /var/log/messages for Accepted password for against accounts that have no password: alpine, root, any key-only user. Such an entry is a strong indication of compromise.

Also review doas usage, recently created users and new files on exposed machines. The Alpine advisory is explicit — any server where a login cannot be ruled out should be treated as compromised.

4. Verify rather than assume. On Alpine it is not the OpenSSH banner version that decides but the apk package revision. Kültekin published a check script that identifies exposed servers and lists the accounts at risk.

What this case says about prioritisation

Three pieces in a row, the same pattern three times, each one sharper.

An EPSS value of 0.98 percent is not a miscalculation. The model measures publicly observable exploitation signals, and those arrive with a delay. For a flaw attacked nine hours after publication, that delay is longer than the window in which the decision gets made.

What was available in time sits not in a score but in the text of the advisory: a trivial attack requiring no exploit development, a publicly known default configuration, a public PoC. Three characteristics any person reads in two minutes and no external model captures quickly enough.

Scores prioritise the normal case. The exception is visible only to whoever reads the advisory.