IT and platform teams can use this patch SSHole checklist to find Alpine, container, and edge SSH hosts that match the bypass, then update and restart sshd before the next scan pass. OpenSSH 10.6p2, released on 2026-11-05, closes a password-authentication bypass on musl systems built with PAM disabled. Help Net Security reported that Ryan Dewhurst said the first observed attempt arrived less than nine hours after CVE-2026-123158 was published, and that Previdian confirmed successful root access on an Alpine honeypot.
Updated November 6, 2026
Key Takeaways
- One SSH connection can bypass passwords on musl systems built without PAM.
- Restart sshd after upgrading; the update does not replace the running daemon.
- Previdian confirmed root access on an Alpine honeypot.
- Fixed Alpine packages were published for branches back to 3.16.
What makes an SSH host exploitable?
The Alpine Linux advisory states: “An attacker who can reach your SSH port can log in without knowing any password. It takes one connection, works every time, and needs no retries.” The password is 257 to 1024 bytes. SecurityWeek reports CVE-2026-123158, dubbed SSHole, at a CVSS score of 8.1. OpenSSH says the root cause sits outside sshd, but the bypass is exploitable through it.
Every condition must hold: musl with PAM disabled (Alpine’s default openssh-server, or openssh-server-pam with UsePAM no), PasswordAuthentication yes, a * password field, and another local account with a $5$ or $6$ hash. One passworded account makes every * account reachable. PermitRootLogin prohibit-password blocks root, shipped as root:* since about Alpine 3.16, unless set to yes. A non-root * account that can use doas is still a path to root.
| Check | Exploitable | Not exploitable |
|---|---|---|
| Build | musl, PAM disabled | glibc, PAM enabled, Dropbear, OpenBSD |
| PasswordAuthentication | yes, the default | no, including cloud-init |
| Target account | password field is * | locked as user:! in /etc/shadow |
| Other account | $5$ or $6$ hash present | no $-style hash on the host |
How do you find Alpine, container, and edge targets?
Look past hosts named Alpine. Özgün Kültekin also names OpenWrt, Buildroot, and Yocto, plus many container images already pulled. Skip containers that do not run sshd, and include edge appliances from those trees. Key-only users and musl-nscd accounts (nslcd, winbind, sssd) also match a * field.
Tiny-cloud qcow2, VHD, and AMI images from 3.18.11 through 3.24.3 ship alpine with a * field and passwordless doas. They are safe on first boot, then exploitable once any $6$ hash exists, such as a console password or hashed_passwd in user-data.
Every checked branch is affected, from 3.16 through 3.24 and edge. Fixed packages go back to 3.16, though 3.21 ended support on 2026-11-01. Images built from 3.21.10, 3.22.8, 3.23.8, and 3.24.4 and later include the fix; earlier point releases do not.
How do you patch SSHole and restart sshd?
Update plus restart, or PasswordAuthentication no plus restart, each closes the hole. The package upgrade alone does not replace the running daemon. Help Net Security reported that Damien Miller urged anyone running musl-based Linux without PAM to “stop reading and set PasswordAuthentication=no or disable SSH for these systems IMMEDIATELY.”
- Run apk upgrade -U -a. Fixed packages are in Alpine 3.21.10, 3.22.8, 3.23.8, and 3.24.4.
- Restart sshd with rc-service sshd restart.
- If you cannot update, test key login first and keep the current session open. Set PasswordAuthentication no and restart sshd. From 3.19 onward a drop-in in /etc/ssh/sshd_config.d is read; older releases ignore it, so also edit /etc/ssh/sshd_config.
- Run sshd -T | grep -i passwordauthentication and confirm it prints passwordauthentication no.
- Rebuild images from the fixed point releases. On instances already running earlier images, update openssh or disable password authentication.
How do you tell whether a login already landed?
Ryan Dewhurst told Help Net Security the first observed attempt arrived less than nine hours after CVE publication, and that Previdian confirmed successful root access on a honeypot running Alpine Linux and OpenSSH. Source 89.116.89[.]18 used oversized passwords and ran commands including id, uname, and hostname. Previdian counted eight attempts from that Japan-based address on one sensor and added the bug to its own exploited list. CISA has not added CVE-2026-123158 to the KEV catalog, unlike other flaws already listed there.
Search /var/log/messages for Accepted password for an account with no password, such as alpine, root, or a key-only user. Review doas use, new users, files, and authorized keys. If a login cannot be ruled out, treat the machine as compromised. Skip unverified GitHub proofs of concept; Previdian warns they could contain malware.
Frequently asked questions
Which hosts are affected by SSHole?
OpenSSH before 10.6p2 on musl with PAM disabled, PasswordAuthentication yes, a * password field, and a $5$ or $6$ hash. glibc systems, UsePAM yes, Dropbear, and OpenBSD are not affected.
Is a package upgrade enough?
No. Alpine says upgrading does not replace the running sshd, so restart with rc-service sshd restart.
Are Alpine cloud images safe on first boot?
Tiny-cloud images from 3.18.11 through 3.24.3 are safe until a $6$ hash appears. The alpine user has a * field and passwordless doas.
Has SSHole already been used to log in?
Previdian confirmed successful root access on an Alpine honeypot. Dewhurst said the first observed attempt arrived less than nine hours after CVE publication, and CISA has not added CVE-2026-123158 to the KEV catalog.
