Key takeaways
- OpenSSH 10.6p2, released on 5 November 2026, fixes CVE-2026-123158 ("sshole") — a flaw that lets an attacker log in with a password to an account that has no password, on Linux systems built with musl libc and without PAM (Help Net Security, SOCRadar).
- Alpine Linux is the main target, because its default
openssh-serverpackage uses musl and no PAM. Debian, Ubuntu, RHEL, Fedora and other glibc distributions are not affected, and neither is Dropbear. - Exploitation attempts were reported within nine hours of disclosure — one honeypot operator says an attacker got root on an Alpine sensor. Another report the same day said no attacks were known yet, so treat the risk as live but early.
- Fix: upgrade the openssh package and restart sshd. Installing the package alone does not restart the running daemon.
- Fastest safe workaround:
PasswordAuthentication no. If you only use SSH keys (as you should), this closes the hole in two minutes.
1. What actually breaks
When sshd checks a password without PAM, it hashes what you typed with the C library's crypt() function and compares it to the stored hash in /etc/shadow.
Two old, separately reasonable decisions collide here, as SOCRadar explains:
- Since 2016, to stop attackers guessing which usernames exist, sshd borrows another account's salt when the target account has no real hash — for example when its password field is just
*. - musl's
crypt()refuses SHA-256/SHA-512 passwords longer than 256 bytes, and on that failure it returns the string*.
So: send a very long password for an account whose stored field is *, and the "hash" of your attempt comes out as *. That matches. sshd lets you in.
On Alpine, root has shipped with * for years, and many key-only service accounts look the same. The researcher who found it, Özgün Kültekin, says he used AI agent swarms to run roughly 17,600 login attempts across sshd builds before spotting the pattern (Help Net Security).
2. Are you exposed? The four conditions
All four must be true, per Alpine's advisory as summarised by SOCRadar:
| Condition | How to check | Typical Alpine default |
|---|---|---|
| sshd runs without PAM | apk info openssh-server-pam (not installed) or UsePAM no |
Yes — no PAM |
| Password auth is on | sshd -T \| grep -i passwordauthentication |
Yes — OpenSSH default |
An account has * as its password |
awk -F: '$2=="*"{print $1}' /etc/shadow |
Yes — root, key-only users |
Another local account has a $5$ or $6$ hash |
awk -F: '$2 ~ /^\$[56]\$/{print $1}' /etc/shadow |
Common if anyone set a password |
Accounts locked with ! are not exploitable. PermitRootLogin prohibit-password normally stops a direct root login — but on Alpine's cloud images (tiny-cloud, AWS/Azure, versions 3.18.11 to 3.24.3) there is a default alpine user with passwordless doas, which is a short hop to root.
Not affected: Ubuntu, Debian, RHEL/Rocky/Alma, Amazon Linux, Fedora, macOS, OpenBSD, Windows OpenSSH, and anything using Dropbear. Most Docker containers also do not run sshd at all, so an Alpine base image is only a problem if you added an SSH server to it.
3. Where Indian teams usually have Alpine with sshd
Alpine is popular here because it is tiny and cheap to run. The places it tends to hide:
- "SSH into the container" debug images that a developer built years ago and nobody removed — often on a ₹500–₹1,500/month VPS.
- Bastion or jump hosts built on Alpine to keep them small.
- Alpine VMs on AWS Mumbai/Hyderabad or Azure Central India started from the official cloud images, which include the
alpineuser. - Routers, gateways and IoT boxes built with Buildroot, Yocto or OpenWrt variants that ship OpenSSH on musl (stock OpenWrt uses Dropbear, which is safe).
- CI runners and Git servers (Gitea/Forgejo in containers with built-in sshd) — check how your image provides SSH.
A quick external sweep helps: list every public IP your company owns, scan port 22 (and any custom SSH port), and grab the banner. An SSH-2.0-OpenSSH_9.x or 10.x banner does not tell you the libc, so log in and run cat /etc/os-release on anything you are unsure of.
4. The fix, step by step
Upgrade and restart (preferred):
apk upgrade -U -a
rc-service sshd restart # OpenRC; the package upgrade does not restart sshd
ssh -V # confirm the new build
Alpine published fixed packages for 3.16 through edge on 5 November. Reported fixed versions include 10.3_p1-r2 (3.24), 10.2_p1-r1 (3.23), 10.0_p1-r11 (3.22) and 9.9_p2-r1 (3.21) — confirm against the Alpine security tracker before you rely on them. Fresh images from 3.21.10, 3.22.8, 3.23.8 and 3.24.4 onward are reported to include the fix. For containers, rebuild from a fresh base and redeploy; do not patch running containers by hand.
Workaround if you cannot upgrade today:
echo "PasswordAuthentication no" > /etc/ssh/sshd_config.d/00-no-passwords.conf
sshd -t && rc-service sshd restart
sshd -T | grep -i passwordauthentication # must say "no"
Check Match blocks too — a PasswordAuthentication yes inside one overrides your global setting. Keep your current session open until you have confirmed a fresh key-based login works.
| Option | Time | Closes the hole | Side effects |
|---|---|---|---|
| Upgrade + restart sshd | 5–10 min per host | Yes | None expected |
PasswordAuthentication no |
2 min | Yes | Breaks anyone still logging in with a password |
Lock * accounts with passwd -l |
2 min | Partly | Easy to miss an account |
| Firewall port 22 to office/VPN IPs | 10 min | Reduces exposure | Remote staff need VPN |
Do the first two together. There is no reason in 2026 for internet-facing SSH to accept passwords.
5. Hunt for signs someone already got in
Previdian, the honeypot firm that reported the attempts, saw oversized passwords followed by quick recon commands (id, uname, hostname) from a single IP (Help Net Security). On every Alpine host that had password auth on:
grep "Accepted password for" /var/log/messages* | grep -E "root|alpine"
Any password login for an account that has no password is a red flag. Then review recent doas use, new users in /etc/passwd, changes to every authorized_keys file, and unexpected cron jobs. If you cannot rule out a login, treat the host as compromised: rebuild it from a clean image and rotate any secrets it held (API keys, database passwords, cloud credentials).
Be careful with "proof of concept" scripts on GitHub — Previdian warns they are unverified and may contain malware. Use the checks above instead.
6. The India angle: reporting and patch timelines
Under CERT-In's 2022 directions, a cyber incident such as unauthorised access to a server must be reported to CERT-In within six hours of noticing it. If your hunt in section 5 finds a suspicious login, that clock starts. CERT-In has also been reported to recommend patching critical, internet-facing, exploited flaws within 12 hours where feasible (NewsBytes) — sshole fits that description.
For small teams, the cost argument is simple: an hour of an engineer's time (₹1,000–₹3,000) to sweep and patch every Alpine host is far cheaper than rebuilding a compromised server, rotating every credential on it and filing an incident report. The same hour is a good time to switch every server — Alpine or not — to key-only SSH.
7. Bottom line
sshole is narrow: Alpine or another musl system, sshd without PAM, password auth on. But that combination is the default on Alpine, attacks started within hours, and the fix is a package upgrade plus a restart. Patch today, turn off password authentication everywhere, and check your logs.
Running a mix of Alpine containers, VPSes and jump hosts and not sure what is exposed? Our managed IT services team can inventory, patch and harden SSH across your fleet, and our incident monitoring service watches for suspicious logins after the fix.