CISA Adds OpenSSH Flaw CVE-2026-123158 to KEV Catalog

CISA has added an OpenSSH password-authentication bypass, tracked as CVE-2026-123158, to its Known Exploited Vulnerabilities (KEV) catalog, confirming the flaw is being actively exploited in the wild. The bug hits sshd on Linux systems built against musl libc with PAM disabled — the default server configuration on Alpine Linux and many minimal container images — and lets an attacker log in with almost any sufficiently long password on certain accounts. CISA added the flaw on November 9, 2026 alongside three other actively exploited bugs, and set a federal civilian remediation deadline of November 12, 2026, which has now passed. The fix ships in OpenSSH 10.6p2, released November 5, 2026.

What happened

On November 9, 2026, the Cybersecurity and Infrastructure Security Agency (CISA) added four vulnerabilities to its Known Exploited Vulnerabilities catalog in a single batch, each with a November 12, 2026 due date for U.S. federal civilian agencies under Binding Operational Directive 22-01. Three of the four — flaws in GPUStack, SignalWire's FreeSWITCH, and IBM Aspera Faspex — have already been widely reported. The fourth, an OpenSSH flaw cataloged as CVE-2026-123158, has drawn less attention despite affecting one of the most widely deployed pieces of server software on the internet.

CISA's catalog entry lists the vendor as OpenBSD, the product as OpenSSH, and the vulnerability name as an "OpenBSD OpenSSH Unexpected Status Code or Return Value Vulnerability." The required action for federal agencies is to apply the vendor's mitigations, follow BOD 22-01 catalog guidance, and — because this flaw involves authentication — also complete the forensic triage steps CISA requires under BOD 26-04 for authentication-bypass bugs added to KEV.

What CVE-2026-123158 actually is

According to the National Vulnerability Database (NVD) entry for CVE-2026-123158, the flaw lives in Linux builds of OpenSSH's sshd prior to version 10.6p2 that are compiled against musl libc without PAM support. On that specific combination, a workaround for a password-verification edge case is missing, and sshd can misjudge whether a stored credential string is meant to function as a password hash.

The practical effect: for accounts whose shadow password field is set to a disabled or key-only marker, sshd running on an affected build can accept almost any password between roughly 256 and 1,024 characters long, rather than correctly rejecting the login. An attacker who can reach SSH on a vulnerable host and knows (or guesses) a valid, nominally password-disabled username can authenticate without ever knowing a real password.

NVD assigns the bug CWE-394 (Unexpected Status Code or Return Value) and a CVSS 3.1 base score of 8.1, rated High, with the vector AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H — network-exploitable, no privileges or user interaction required, but with high attack complexity, and full impact on confidentiality, integrity and availability if successfully exploited.

Who is affected

The vulnerable combination is narrow but common in practice: Linux systems running OpenSSH's sshd built against musl libc (rather than glibc) with PAM disabled. musl is the default C library on Alpine Linux, which in turn is one of the most popular base images for Docker containers, making the exposure larger than the "one obscure distro" framing might suggest. Alpine Linux's own security advisory, published the same day as the OpenSSH fix, confirms its default sshd configuration on affected releases met the vulnerable criteria and lists patched package versions for the 3.21, 3.22, 3.23 and 3.24 branches.

Standard glibc-based Linux distributions (Ubuntu, Debian, RHEL, Fedora, and most others) and systems with PAM enabled are not affected by this specific flaw, since the issue is tied to how musl's crypt() function behaves without PAM's additional checks in the path. That distinction matters for triage: a fleet inventory sorted by distribution, rather than by OpenSSH version number alone, will find the actual exposure faster, since plenty of hosts can be running a nominally "old" OpenSSH build on glibc and still be unaffected, while a freshly built Alpine container image can be vulnerable even if it looks otherwise up to date.

The exposure also extends beyond traditional long-lived servers. Ephemeral and short-lived containers built from Alpine base images — common in CI/CD runners, Kubernetes sidecars, and lightweight microservices — can carry the vulnerable configuration without anyone treating them as "a server" that needs patch tracking in the usual sense. Several infrastructure projects and container-image maintainers flagged this gap publicly within days of the OpenSSH advisory, filing issues against popular Docker SSH images to confirm whether their builds were affected.

How the bypass works

OpenSSH's own release notes for 10.6p2 describe the change as "a critical security workaround that affects Linux systems that use the musl libc and PAM disabled," with the fix itself framed as a way to "avoid password authentication bypass that is exploitable through sshd(8)." The notes credit security researcher Özgün Kültekin with the discovery, and are notably candid that the underlying root cause sits outside OpenSSH's own code — in how musl's crypt() implementation handles unusually long inputs — but that sshd can still work around it.

In short: when musl's crypt() is given a password string longer than it expects, it can return a fixed placeholder value instead of a real computed hash. If that placeholder happens to match the stored (disabled) password field for a given account, authentication succeeds even though no real password check occurred. Security researchers who published technical write-ups on the bug — building on public proof-of-concept exploit code — nicknamed it "sshole" for how it slips past what should be a hard stop.

Because PAM, when enabled, performs its own independent account and password checks, enabling PAM has been floated by several researchers as an interim mitigation on systems that cannot immediately upgrade. CISA's and OpenSSH's own guidance, however, is to apply the 10.6p2 update directly rather than rely on workarounds.

Why CISA says it's being exploited now

CISA only adds a vulnerability to the KEV catalog when it has evidence of active, in-the-wild exploitation — it is not a general vulnerability-severity list. Its catalog entry for CVE-2026-123158 gives no additional attribution or exploitation detail beyond the listing itself and the required action, which is standard for KEV entries: CISA typically does not disclose who is exploiting a bug or how, both to protect sources and to limit sharing of attack tradecraft. NVD's own record for the CVE notes the KEV addition date and due date as part of its "Status: Analyzed" field, but likewise provides no further detail on the threat actors involved.

What is public is the proof-of-concept exploit code: multiple GitHub repositories reproducing the bypass circulated within days of OpenSSH's November 5 advisory, and the bug picked up the informal nickname "sshole" in community write-ups. That kind of rapid, public weaponization — a working exploit anyone can run against a reachable sshd port — is exactly the pattern that tends to precede or accompany a KEV listing, since it collapses the gap between "a bug exists" and "anyone can use it" to almost nothing. Independent researchers also stood up scanning and tracking efforts aimed at measuring how many internet-facing hosts still expose the vulnerable configuration, underscoring that the exposure window extends well past any single patch-Tuesday-style cycle.

The rest of November 9's four-flaw KEV batch

CVE-2026-123158 was one-quarter of a single CISA KEV update. The other three flaws added the same day, all carrying the same November 12 deadline, were an improper-authentication bug in GPUStack, a code-injection flaw in SignalWire's FreeSWITCH, and an incorrect-authorization vulnerability in IBM's Aspera Faspex file-transfer software — each covered separately as the news broke. The pattern across all four is consistent with how CISA has been operating its KEV catalog through 2026: batching confirmed, actively-exploited bugs together and giving federal agencies a uniform, short remediation window regardless of each product's individual footprint.

How to patch or mitigate

For organizations running affected systems, OpenSSH's and CISA's guidance converges on the same core step:

• Upgrade OpenSSH to 10.6p2 or later on any Linux host where sshd is built against musl libc with PAM disabled. On Alpine Linux, this means applying the patched openssh package for your branch (3.21.10, 3.22.8, 3.23.8, 3.24.4, or later within each release line, per Alpine's advisory) and restarting the sshd service.
• Audit container base images. Because Alpine is a default base image for a large share of Docker containers, teams should check CI/CD pipelines and running container fleets for images that bundle an affected OpenSSH build, not just traditional servers.
• If you cannot patch immediately, disable password authentication in sshd_config (PasswordAuthentication no) and rely on key-based authentication only, or enable PAM, as an interim compensating control — but treat this as a stopgap, not a substitute for upgrading.
• Federal agencies subject to BOD 22-01 should also complete the forensic triage steps CISA specifies under BOD 26-04 for authentication-bypass KEV entries, given the November 12 deadline has already passed.
• Review authentication logs on any host confirmed to have run a vulnerable configuration, looking for unusually long password strings submitted during login attempts, which is a practical indicator of an exploitation attempt against this specific flaw.

OpenSSH 10.6p2 is otherwise a routine maintenance release layered around this one security fix: its release notes list a handful of unrelated bugfixes and portability patches, including support for a post-quantum hybrid signature scheme as an allowed certificate-authority signature algorithm and several minor platform-compatibility corrections. None of the other changes carry a CVE or security designation, which is one reason the password-bypass fix is easy to miss if a team only skims release notes for headline features rather than reading the security section closely.

Why a KEV listing matters beyond government

CISA's KEV catalog is binding only on U.S. federal civilian agencies, but it functions as a widely used signal for the broader security industry. Enterprise vulnerability-management programs, insurers, and compliance frameworks increasingly reference KEV status when prioritizing patch work, precisely because an entry means CISA has confirmed real exploitation rather than theoretical risk. Teams that don't explicitly track OpenSSH news might otherwise miss this update, since CVE-2026-123158 doesn't look like a typical headline OpenSSH story — it only affects a specific build configuration, not every OpenSSH deployment — but its KEV status is a strong indicator that scanning tools and threat actors alike are already treating musl/no-PAM Linux hosts as a live target.

What's next

With the federal deadline already past, expect CISA's usual pattern: continued monitoring for further exploitation, and the possibility this flaw gets referenced in future ransomware or initial-access advisories if attackers are using it to establish footholds in exposed container infrastructure. Alpine Linux and other musl-based distributions may issue follow-up guidance if additional affected configurations surface. Security teams should treat the November 12 deadline less as a missed date than as a signal that remediation — upgrading to OpenSSH 10.6p2 and auditing container images for the vulnerable musl/no-PAM combination — is overdue wherever it hasn't happened. Pandromeda will update this story if CISA or OpenSSH releases further detail on exploitation.

Written bySana Qureshi

Sana Qureshi runs the security and privacy desk. She reports on actively exploited vulnerabilities, vendor patches and data breaches, and covers the password managers, VPNs and authentication tools readers use to protect themselves. Her alerts cite vendor advisories, CISA and the CVE record directly.

More from Sana QureshiAll Security & Privacy coverage