OpenSSH 10.6p2 is an emergency release that the OpenSSH developers shipped on November 5, 2026. It closes a flaw nicknamed “SSHole” and tracked as CVE-2026-123158: on Linux systems that use the musl C library without PAM, attackers could log in to certain accounts without knowing a password. The OpenSSH release notes call it a “critical security workaround” and say the root cause lies outside sshd but is exploitable through it. The main victim is Alpine Linux, a distribution that is everywhere in containers, cloud images and embedded devices.
The good news first: a classic server running Debian, Ubuntu or Fedora is not affected. The bad news: if you run Alpine hosts with a reachable SSH port, this should not wait until Monday. According to media reports, the first attack attempts were observed only hours after disclosure.
OpenSSH 10.6p2: what the flaw is about
The bug was found by Özgün Kültekin of the security firm Wakefield. It comes from the interaction of two design decisions that each make sense on their own. Without PAM, OpenSSH checks a password by hashing the attempt with the library function crypt() and comparing the result with the stored entry. For accounts without a usable hash, such as key-only accounts whose password field in /etc/shadow holds just a *, sshd has for years borrowed the salt of another account. That was a defence against timing attacks that would otherwise reveal which usernames exist.
musl, in turn, returns exactly the string * as an error indicator in certain crypt() failure cases, for example with overlong input. As the Alpine security advisory explains, that error value then matches the stored field of the passwordless account, and sshd treats the comparison as a success. An account that should never accept a password can thus be opened with a password login.
The NVD entry puts it plainly: sshd in OpenSSH before 10.6p2 on Linux with musl and without PAM lacks a workaround for a password authentication bypass. The CNA, MITRE, rates it CVSS 8.1 (High). NVD had not published its own assessment at the time of writing.
Who is affected, and who is not
According to Alpine, several conditions must all be true:
- The system runs Alpine’s
openssh-serverpackage, which is built without PAM, oropenssh-server-pamwithUsePAM no. PasswordAuthenticationis set toyes, which is the OpenSSH default unless someone changed it.- There is an account with
*in its password field. That includes key-only users, directory-service accounts pulled in via musl-nscd and, since roughly Alpine 3.16,root. - At least one other local account has a classic SHA-256 or SHA-512 password hash.
Root itself is protected by the default PermitRootLogin prohibit-password. That helps little if another reachable passwordless account can become root. That is exactly the case on the official Alpine cloud images (tiny-cloud): versions 3.18.11 through 3.24.3 ship an alpine user with a * password field and passwordless doas. Alpine says these images are safe on first boot, but they become exploitable as soon as any password hash appears on the machine, for instance when an admin sets a console password.
Not affected, according to Alpine and the researcher: glibc-based distributions such as Debian, Ubuntu or Fedora, setups using PAM, systems with PasswordAuthentication no, cloud images configured via cloud-init (which disables password login), and containers that do not run sshd. Locked accounts with ! in the password field cannot be reached either. Beyond Alpine, the researcher lists other musl-based environments such as OpenWrt, Buildroot and Yocto as worth checking.
Already exploited
The speed is what stands out. Help Net Security, citing threat intelligence firm Previdian, reports that the first observed attack attempt arrived less than nine hours after the CVE was published, and that root access succeeded on a honeypot running real Alpine Linux. At the time of the report Previdian had counted eight attempts from a single address. According to the same report, CISA had not yet added the flaw to its KEV catalog. Alleged proof-of-concept exploits are also circulating on GitHub; Previdian explicitly warns they are unverified and could contain malware. We deliberately do not link them.
The release text itself adds notable context. The OpenSSH team writes that it is currently receiving a large number of security reports, many found by AI models or with AI assistance. Because such findings are often rediscovered independently shortly afterwards, the project will for now ship releases more often instead of batching fixes. The researcher said he ran around 17,600 unusual login attempts against different builds using “agent swarms”. We have seen the pattern before with Patch Gap and GLM 5.3: the window between patch and attack keeps shrinking.
What admins should do now
1. Update and restart sshd. Alpine has published patched packages for every branch from 3.16 to edge; the point releases 3.21.10, 3.22.8, 3.23.8 and 3.24.4 include the fix. On edge it is openssh 10.6_p2-r0; older branches get a patched package revision (for example 10.3_p1-r2 on 3.24). Important: a package upgrade does not replace the running daemon. The hole is only closed once sshd has been restarted.
2. If you cannot update: disable password logins. Setting PasswordAuthentication no in the sshd configuration closes the hole as well. Make sure key-based login works first, and keep your current session open until you have tested a new login. OpenSSH developer Damien Miller publicly urged operators of affected systems to do exactly that, immediately.
3. Look for traces. Alpine recommends searching /var/log/messages for sshd lines reading “Accepted password for” that name accounts without a password, such as alpine, root or key-only users. Also review doas usage, recently created users and authorized_keys files. If an unauthorised login cannot be ruled out, treat the machine as compromised.
4. Do not forget container images and appliances. Teams that build their own Alpine-based images with sshd inside need to rebuild and redeploy them. For routers and embedded devices running OpenWrt or Yocto, check the respective vendor’s guidance.
What else is in OpenSSH 10.6p2
Besides the security fix, the release carries a few bugfixes from the stable 10.6 branch. The hybrid post-quantum signature scheme ssh-mldsa44-ed25519 is now allowed as a CA signature algorithm, and a brief CPU spin when the ChannelTimeout option is in use has been fixed. There are also portability fixes, for example for the seccomp sandbox. For most glibc systems, 10.6p2 is therefore a routine maintenance update that will arrive through normal distribution channels.
Putting it in perspective
SSHole is not a bug that endangers “the internet”. The combination of musl, no PAM, password login enabled and a mix of accounts with and without passwords is specific. But that very combination is the default in Alpine-based environments, and Alpine sits inside many images that teams built once and then forgot. Anyone who already allowed SSH by key only was safe all along, and that is the real lesson. As with this week’s Symfony Serializer flaw CVE-2026-118515, patching is mandatory, but secure default configurations limit the damage before a patch exists. And as the tampered Claude Code extension with an SSH backdoor showed, SSH remains a favourite way in.
Note: this article describes cause, exposure and remediation based on vendor information. We deliberately do not reproduce attack details or exploit code.
