OpenSSH “sshole”: any password over 256 characters opens key-only accounts on Alpine. Check the boxes nobody calls servers.

01 What breaks

Two old decisions broke it. In 2016 OpenSSH started hashing every password attempt, even for accounts with no usable hash, borrowing another account’s salt so that response times would not reveal which usernames exist. That closed CVE-2016-6210. Four years earlier, musl’s crypt() had been changed to return * when it fails. It also refuses SHA-256 and SHA-512 passwords over 256 bytes [ Researcher write-up ] .

Put them together. An attacker sends a 300-character password for root. sshd borrows a $6$ salt from a real user and calls crypt(). musl rejects the length and returns *. sshd compares that with the stored *. They match. The attacker is in.

Özgün Kültekin of Wakefield found it by building sshd in every combination of glibc, musl, PAM and no PAM, then sending about 17,600 odd logins at each. Every build agreed except one: musl without PAM [ Researcher write-up ] . OpenSSH calls its fix a “critical security workaround” and says the root cause sits outside sshd [ OpenSSH 10.6p2 ] . The CVE record scores it 8.1 [ CVE record ] .

02 Who is exposed

Alpine lists four conditions. A box is exposed when all of them hold [ Alpine advisory ] :

Direct root login is still blocked by OpenSSH’s default PermitRootLogin setting, unless someone changed it [ Help Net Security ] . That rarely saves you. Alpine’s official tiny-cloud images for AWS and Azure, from 3.18.11 to 3.24.3, ship an alpine user with a * password and passwordless doas. They are safe on first boot. Once a $6$ hash appears on the machine, they are one long password away from root [ Alpine advisory ] .

The boxes nobody counts as servers

Your Ubuntu and Debian estate is fine. glibc systems, anything that goes through PAM, Dropbear and OpenBSD are not affected [ Researcher write-up ] . The exposure sits in places an asset register tends to miss:

• The Alpine container with sshd in it. Most Alpine containers never run sshd, and those are safe. The ones that do were usually set up by a developer who wanted a shell for debugging, then published on a port that nobody closed.
• The cloud VM from a tiny-cloud image. Launched once for a job, still running, still on its first-boot config.
• The router or gateway. OpenWrt ships Dropbear, which is safe. A router where someone installed the OpenSSH package instead is a musl box running sshd.
• The appliance. NAS boxes, building controllers, industrial gateways, anything a vendor built with Buildroot or Yocto. You cannot run apk upgrade on it. You wait for the vendor’s firmware, and you need to know the box exists to chase it.

03 Exploitation so far

The CVE was published at 15:46 UTC on 5 November. Proof-of-concept code appeared on GitHub the same day [ Previdian ] . Previdian, a threat intelligence firm, says its sensors caught the first attempt less than nine hours later. On an Alpine honeypot the attacker got root, then ran id, uname and hostname over non-interactive SSH sessions [ Help Net Security ] [ The Hacker News ] .

The counts depend on the date you read them:

Twenty attempts is a small number. Previdian notes that an attempt does not prove the target was vulnerable [ Previdian ] . The speed is the point. Previdian founder Ryan Dewhurst called the flaw “particularly trivial to exploit”, and warned that the public exploits on GitHub are unverified and may carry malware [ Help Net Security ] . The attack is one long password, so any SSH brute-force tool can carry it. CISA had not added CVE-2026-123158 to its Known Exploited Vulnerabilities catalogue as of 9 November [ Previdian ] . Do not wait for it.

04 The ten-minute check

Run this as root on any Linux box that answers on SSH and that you cannot place as Debian, Ubuntu, RHEL or similar. Start with step one. If the box is not musl, stop there.

# 1. Is it musl? "musl libc" in the output means yes
ldd --version 2>&1 | head -1
ls /lib/ld-musl-* 2>/dev/null

# 2. Does sshd take passwords? Is the PAM build even installed? (Alpine)
sshd -T | grep -i -E '^(passwordauthentication|usepam)'
apk info -e openssh-server-pam

# 3. Which accounts are "*", and is there a real hash to borrow a salt from?
awk -F: '$2=="*"{print "no password: "$1} $2 ~ /^\$[56]\$/{print "hash: "$1}' /etc/shadow

# 4. Has an account with no password logged in with one?
grep "Accepted password for" /var/log/messages

Any line in step four that names root, alpine or a key-only user is a break-in. Alpine’s advice is to treat the machine as compromised: check doas use, new users, new files and every authorized_keys [ Alpine advisory ] . Rebuild it. Do not clean it.

Then close it:

# Fix: update, then restart. The upgrade alone leaves the old sshd running
apk upgrade -U -a
rc-service sshd restart

# Cannot update today? Turn passwords off. Confirm key login first,
# and keep a session open while you restart
echo "PasswordAuthentication no" > /etc/ssh/sshd_config.d/00-no-passwords.conf
sshd -t && rc-service sshd restart

sshole will not hit your main servers. It hits the machine you forgot was a server: the debug container, the tiny-cloud VM from a proof of concept, the gateway a contractor installed. An attacker scanning port 22 finds those first, because nobody patches what nobody listed. An external penetration test gives you that list, with proof of what each box exposes and the order to fix them in. Start with your free external exposure audit. Your red team. Within reach.