sshole: The OpenSSH Bug Attackers Exploited Before Lunch
A password that’s too long should fail. On Alpine Linux, it can log an attacker straight in. OpenSSH rushed out an emergency fix this week, and attackers started using the flaw less than nine hours after it went public.
What Happened?
OpenSSH released version 10.6p2 on November 5. Its own release notes call it a critical security workaround. The flaw is tracked as CVE-2026-123158 (CVSS 8.1) and nicknamed “sshole.” It hits sshd on Linux systems built on the musl C library that check passwords without PAM. That’s exactly how Alpine ships its default openssh-server package. OpenWrt, Buildroot and Yocto builds may also be exposed, along with plenty of container images built on Alpine.
How a Long Password Opens the Door
When musl’s crypt() gets a password longer than 256 bytes, it fails and returns a single asterisk. Locked accounts, and accounts meant for SSH keys only, store that same asterisk in /etc/shadow. sshd compares the two, sees a match, and waves the attacker through. Any password between 257 and 1,024 bytes works. The attack also needs password logins switched on and at least one other account with a real password hash. On a default Alpine box, both are common.
One asterisk, two meanings.
On Alpine and other musl systems running sshd without PAM, an error code and a locked account look exactly the same. sshd can’t tell them apart.
** tooOpenSSH 10.6p2 now rejects any stored password field shorter than four characters, so the lone asterisk can never match again.
Already Under Attack
A threat intelligence firm logged its first exploit attempt less than nine hours after the CVE went public. All eight attempts so far came from one IP address. Once inside, the attacker ran basic reconnaissance commands and got confirmed root on a honeypot running real Alpine Linux. Proof-of-concept code is already public on GitHub. CISA hasn’t added the flaw to its KEV catalog yet.
Patch day became attack day.
The fix and the first attacks landed inside the same working day. Teams waiting for the weekly patch window were already behind.
What’s the Impact?
Anyone who can reach port 22 and knows a valid account name can walk in. On official Alpine cloud images, the default alpine user can often jump to root through doas without a password. From there, attackers can steal data, plant backdoors, and move sideways across your network.
How to Avoid This
- Patch now. Upgrade to OpenSSH 10.6p2, or to Alpine 3.21.10, 3.22.8, 3.23.8 or 3.24.4. Fixed packages exist for every branch from 3.16 onward, even ones past end of support.
- Restart sshd. The update doesn’t restart it for you, so the old code keeps running.
- Can’t patch today? Set
PasswordAuthentication noonce you’ve confirmed key logins work. Then check Match blocks, which can switch password logins back on. - Lock down SSH to office and corporate VPN IP ranges.
- Hunt for “Accepted password for” log lines tied to root, alpine or accounts that should only use keys. Then review doas use, new users and authorized_keys files. If you can’t rule out access, treat the host as compromised.
Five boxes ticked means one open door.
The bypass only works when every condition on the left lines up. Default Alpine images tick most of them out of the box.
- 1OpenSSH older than 10.6p2 on musl
- 2
UsePAM noor no PAM package - 3
PasswordAuthentication yes - 4An account with
*as its password - 5Another account with a real hash
- ✓
apk upgrade -U -ato the fixed package - ✓Restart sshd so the new code runs
- ✓
PasswordAuthentication noas a stopgap - ✓Allow port 22 from VPN and office IPs only
- ✓Grep logs for
Accepted password for
Not affected: glibc distros, sshd with PAM, Dropbear and OpenBSD.
Patching Is the Easy Part. Finding Every Box That Needs It Isn’t.
Bugs like this rarely win because the fix is hard. They win because nobody can say which containers, routers and forgotten cloud images still run Alpine with password logins on.
- See every internet facing SSH service and the base image behind it, including the ones nobody remembers spinning up
- Test exposure the way an attacker would, so you know which hosts can actually be reached and exploited
- Flag risky settings like PasswordAuthentication yes on hosts that should never accept passwords
- Catch the first password login on an account that has only ever used keys, with full context attached
- Run patch and restart workflows with human approval built in.
Governed Defense, Powered by Offense. No More Grunt Work. No More Burnout.