OpenSSH 10.6p2 closes a password authentication bypass that only affects Linux builds using musl libc without PAM, and attackers were inside hosts within two days of the patch. CISA added the flaw to its Known Exploited Vulnerabilities catalog on 9 November 2026 and gave federal agencies until 12 November to fix it.
What happened
The bug is tracked as CVE-2026-123158 at CVSS 8.1. Researcher Ozgun Kultekin disclosed it, the community named it SSHole, and OpenSSH maintainers shipped 10.6p2 on 5 November. Public exploit code appeared about four hours later.
The mechanism is narrow but effective. On error, musl's password hashing function returns an asterisk, and sshd read that asterisk as a match for an account whose stored hash is already an asterisk, which is the marker used to block password logins entirely. A password between 256 and 1024 characters therefore opens accounts that were never meant to accept one.
GreyNoise logged its first successful exploitation at 00:46 UTC on 7 November, roughly 40 hours after the fix, and counted 16 successful attack chains from six source addresses. The intruders ran host and container discovery, queried cloud metadata services, tried to read password hashes and root SSH keys, then appended their own keys to authorized_keys. On at least one host they reached root and dropped a Python implant that never managed to reach its command server.
Who is affected
The CVE record is specific: sshd before 10.6p2 on Linux, musl libc, no PAM, password authentication switched on, and at least one account on the box holding a normal password hash.
- Alpine Linux hosts, including container images built from alpine and the sshd sidecars teams run for management access.
- Other musl builds that package sshd and allow password logins, such as OpenWrt, Buildroot and Yocto images.
- Ubuntu, Debian and RHEL are not exposed through this flaw: they use glibc and PAM.
What to do now
Get sshd to OpenSSH 10.6p2 or your distribution's fixed package, restart the service, and then check whether anyone used the gap before you patched. Alpine has backported the fix across its supported branches.
- Inventory every Alpine or musl image that exposes SSH. Container base images are rebuilt far less often than people assume.
- Set PasswordAuthentication to no and move to keys, which removes this path no matter which libc is underneath.
- Rotate SSH keys and anything readable from hosts that accepted password logins from the internet.
- Look for authorized_keys entries added since 5 November, and review cloud metadata calls from container networks.
What this means for South African businesses
Most South African SMEs do not run a public sshd, so their exposure is indirect: it sits in the container images a hosting provider or developer built, and in the management containers an MSP dropped on a VPS and forgot. Our read is that the realistic risk is small but concentrated, because a single Alpine jump host with a thin boundary is enough to reach everything behind it. If nobody in the business can list the hosts answering on port 22, that list is the first job this week.
Source: BleepingComputer - Hackers exploit SSHole OpenSSH flaw to breach Linux systems. The fix is documented in the OpenSSH 10.6p2 release notes.
Also on the blog
Next step: If this is on your network or a client's, ask Matthews Enterprises to check exposure.