OpenSSH 10.6p2 shipped on November 4, 2026 with a fix for a password authentication bypass in sshd. The flaw is tracked as CVE-2026-123158 and, on November 9, CISA added it to the Known Exploited Vulnerabilities catalog, its list of flaws with confirmed exploitation. US federal agencies have until November 12 to fix it.
What the flaw allows
According to the description in Ubuntu's security tracker, sshd before 10.6p2, running on Linux, built against musl libc and without PAM (the authentication module most glibc distributions use), lacked a safeguard against this bypass. Under some account configurations, any password between 256 and 1024 characters is accepted. Alpine Linux is the example given. Ubuntu rates it high priority, with a CVSS 3.1 score of 8.1.
The commit message for the fix, signed by Damien Miller, says the bypass "affects some configurations" and that the root cause is not in OpenSSH, though the project can avoid it. The change rejects stored password hashes shorter than four characters and tidies how memory is freed in the password checks. Another commit, "harden password checking", landed on November 9 and is not yet part of a released version.
Who needs to look now
The risk sits on any machine or container running sshd on musl, without PAM, with password login enabled and reachable over the network. In practice that points to Alpine-based servers and images: bastion hosts, SFTP servers used to exchange files with clients, development or support containers someone left with SSH open.
Ubuntu, Debian and Red Hat use glibc by default. Ubuntu notes that, for that reason, the default install should not be affected, but keeps its packages as "needs evaluation" because musl is available in the archive. Teams that use Alpine only as an application base image, without installing openssh-server, are also out of reach.
The hard part is knowing where those sshd instances live. A container with SSH often starts as a debugging shortcut and ends up with nobody responsible for it. If no one maintains those images after delivery, the question of who looks after the system once the project ends turns into a rushed inventory search.
What to do by November 12
CISA's deadline applies to the US government, but it is a useful reference for any team: exploitation is confirmed, so waiting for the next maintenance window makes little sense.
- List hosts and images running
sshdon Alpine or another musl distribution.ssh -Vshows the version;ldd $(which sshd)shows whether the binary uses musl. - Upgrade to OpenSSH 10.6p2 or to your distribution's fixed package, and rebuild container images that bundle the server.
- Where the upgrade cannot ship today, turn off
PasswordAuthenticationinsshd_configand accept only public keys, or take port 22 off the internet. - Review authentication logs from before November 4 for password logins on accounts that should not use one. CISA flagged this flaw as requiring forensic triage, which suggests patching may not be enough if someone already got in.
What is still unknown
The public description does not say which "account configurations" make the bypass possible, and the fix suggests, without confirming, that accounts with a short or empty password field are the path. There is also no public information on who is exploiting the flaw, or on ransomware use, which CISA lists as unknown. The November 9 commit hints at another release with further hardening; keep an eye on OpenSSH release notes and Alpine advisories before closing the issue.
If your company is weighing something similar, reach me on LinkedIn or WhatsApp.
