sshole OpenSSH vulnerability: check Alpine and OpenWrt

The sshole OpenSSH vulnerability lets an account whose password field is just * log in with any password longer than 256 bytes. It hits Alpine and anything else built on musl libc where sshd checks passwords without PAM, as long as one other account has a real hash. Fixing it takes OpenSSH 10.6p2 or your distro’s patched package, plus an sshd restart.

That * is the nasty part, because key-only users, directory users and root on Alpine since about 3.16 all carry it. Root is saved by the default PermitRootLogin prohibit-password, unless another reachable account can doas to it.

What the sshole OpenSSH vulnerability is

Özgün Kültekin of Wakefield reported it, and OpenSSH shipped 10.6p2 on 2026-11-05. Its release notes call it “a critical security workaround” for musl systems with PAM disabled and place the root cause outside sshd.

MITRE published CVE-2026-123158 the same day, scored 8.1 (CVSS 3.1, attack complexity high). Alpine’s advisory of 2026-11-05 says no CVE had been assigned yet.

Who is affected

You’re exposed only when all five hold. That’s the researcher’s list, and Alpine’s advisory carries the last four:

• sshd runs on musl (Alpine, and per sshhole.com also OpenWrt, Buildroot and Yocto)
• sshd does not use PAM (Alpine’s openssh-server is built without it, and openssh-server-pam with UsePAM no counts too)
• PasswordAuthentication yes, which is the OpenSSH default
• some account has exactly * as its password field
• at least one local account has a $5$ or $6$ hash

Alpine lists these as safe:

• UsePAM yes
• PasswordAuthentication no
• locked ! accounts
• boxes with no $ hash
• cloud-init images (they write PasswordAuthentication no)
• containers without sshd

Glibc distros, Dropbear and OpenBSD are safe too, per the researcher.

Why it happens

In August 2012 musl changed crypt() to return an unmatchable hash instead of NULL on failure, which is * in this case. Weeks later its SHA-256 and SHA-512 crypt set a 256-byte key limit, so a longer password fails and gets that * back. And since a 2016 timing fix for CVE-2016-6210, sshd hashes the attempt with another account’s salt when the stored field has none.

So sshd compares * with *, and the login goes through. OpenSSH’s upstream fix refuses any stored field shorter than four characters.

Fixed versions and packages

For the sshole OpenSSH vulnerability, stable branches carry a backported patch under the old version number, so sshd -V on a patched 3.24 box still says 10.3, not 10.6p2. Compare the package release instead (Alpine advisory and package index, 2026-11-06):

Run apk upgrade -U -a, then rc-service sshd restart, since upgrading leaves the old daemon running.

OpenWrt’s default SSH server is Dropbear, per its wiki. If you swapped in the openssh-server package, the packages feed took fixes on 2026-11-05: 10.6p2 on master and openwrt-25.12 (10.6_p2-r1), and a backport on openwrt-24.10 that ships as 9.9_p2-r2, the same version trap as on Alpine. On 2026-11-06 mipsel_24kc on 24.10 still served 9.9_p2-r1, so check your router’s build.

Check your box for sshole

A rough manual check for the sshole OpenSSH vulnerability, run as root. These commands were not run here:

ls /lib/ld-musl-*.so.1                       # a match means musl
sshd -T | grep -E '^(usepam|passwordauthentication) '
awk -F: '$2=="*"{print $1}' /etc/shadow       # accounts with exactly *
awk -F: '$2 ~ /^\$[56]\$/{print $1}' /etc/shadow   # accounts with a real hash
apk info -v openssh-server                   # compare with the table

On musl without PAM, if both awk lines print names and passwordauthentication yes shows up, treat the box as exposed until it’s patched. Directory users from musl-nscd have no shadow line, so awk misses them, but they are targets too.

The researcher’s check.sh tests the same conditions; read it before running it as root. Its version test only counts 10.6p2 and later as fixed, so a patched 3.24 box can still print EXPOSED. Trust the package release.

If you cannot patch yet

Switch password logins off. Alpine and the researcher both say that alone closes the hole.

Tell whether you were broken into

Alpine says to search /var/log/messages for Accepted password for on an account with no password, such as alpine, root or a key-only user.

grep 'Accepted password for' /var/log/messages   # not tested here

Then review doas use, new users, new files and authorized_keys. If you can’t rule out a login, Alpine says to treat the machine as compromised. As of 2026-11-06 the CVE is not in CISA’s Known Exploited Vulnerabilities catalog, and neither Alpine nor OpenSSH reports attacks in the wild.

What this means for proxy and scraping setups

Proxy and scraping setups often include exactly the boxes the sshole OpenSSH vulnerability needs:

• Alpine images that run sshd for SFTP drops or as a jump host
• VPS boxes on the official tiny-cloud images (3.18.11 through 3.24.3), whose alpine user has a * field and passwordless doas, so the first password set on the box opens a path to root
• routers where someone replaced Dropbear with OpenSSH

A server that exists only to give a web scraping architecture a fixed exit is one more sshd to keep patched. Rented datacenter proxies with username and password auth move that box off your list, and the types of proxies guide compares the categories.