CVE-2026-115557: 
Python Interpreter vulnerability analysis and mitigation

CVE-2026-115557 is a certificate revocation checking vulnerability in Python's ssl module, classified under CWE-299 (Improper Check for Certificate Revocation). The vulnerability arises because Python's ssl module previously accepted known compromised eMudhra intermediate CA certificates when certificate revocation was not explicitly configured, potentially enabling man-in-the-middle (MitM) attacks. It affects CPython versions up to and including 3.16.0 (prior to the fix being backported to 3.11–3.15). The vulnerability was disclosed on October 24, 2026, following the public disclosure of compromised eMudhra intermediate CA keys around October 20–21, 2026. It carries a CVSS v4.0 base score of 9.4 (Critical) (GitHub Advisory, Feedly).

The root cause is CWE-299 (Improper Check for Certificate Revocation): Python's ssl module did not maintain a denylist of known-compromised certificates, meaning that if an application did not explicitly configure CRL or OCSP revocation checking, it would accept TLS connections authenticated by revoked or compromised eMudhra intermediate CA keys. The specific issue involves several eMudhra intermediate CA private keys that were compromised (reportedly due to a weak EC private key, d=4) and subsequently revoked. The fix adds a denylist in Modules/_ssl/distrusted_spki.h that matches certificates by the SHA-256 digest of their DER-encoded SubjectPublicKeyInfo (SPKI), blocking any TLS chain containing one of the affected keys — including cross-signed certificates reusing those keys — regardless of SSLContext policy. This mirrors a parallel fix applied to Go's crypto/x509 package for CVE-2026-111943 (CPython PR #160042, CPython Issue #160040).

An unauthenticated network attacker in possession of a compromised eMudhra intermediate CA key could establish fraudulent TLS connections that vulnerable Python applications would accept, enabling interception or modification of encrypted communications (MitM attacks). This affects confidentiality, integrity, and availability at both the vulnerable system and subsequent system levels (all rated High in CVSS v4.0). Applications particularly at risk include those using ssl.create_default_context() without explicit revocation checking, those loading system trust stores (including on Windows where the Sectigo/Comodo AAA Certificate Service may still be present), and those using packages like certifi or pip that bundle their own CA trust stores containing eMudhra roots (CPython Issue #160040, GitHub Advisory).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation at the time of disclosure (Feedly). However, the underlying precondition — possession of a compromised eMudhra intermediate CA key — is a real-world threat given the public disclosure of the key compromise at https://emudhra.we-have-a-problem.com/. The EPSS score is 0.0, and the vulnerability is not currently listed in the CISA KEV catalog. No threat actor attribution has been reported. The attack requires passive user interaction (a user or application initiating a TLS connection), but no privileges or special configuration on the attacker's side beyond network positioning and access to the compromised key material (GitHub Advisory, Feedly).

1. Obtain compromised eMudhra intermediate CA key material: The attacker must acquire one of the disclosed compromised eMudhra intermediate CA private keys (publicly disclosed as compromised, with d=4 as a weak EC private key parameter).
2. Set up a rogue TLS server or intercept network traffic: Position the attacker-controlled system as a network intermediary (e.g., via ARP spoofing, DNS hijacking, or BGP hijacking) between the target Python application and its intended server.
3. Present a fraudulent certificate: Use the compromised eMudhra intermediate CA key to sign a fraudulent TLS certificate for the target domain, constructing a valid-looking certificate chain rooted in a trusted eMudhra root CA still present in the victim's trust store.
4. Intercept the TLS handshake: When the vulnerable Python application (using ssl without revocation checking) initiates a TLS connection, present the fraudulent certificate chain. Because the Python ssl module does not check revocation status by default and lacks the denylist, it accepts the chain.
5. Decrypt and manipulate traffic: With the MitM position established, intercept, read, or modify the encrypted communications between the Python application and its intended server (CPython Issue #160040, CPython PR #160042).

• Network: Unexpected TLS certificate chains presented to Python applications that include eMudhra intermediate CA certificates (check for issuer CNs referencing eMudhra); TLS handshakes completing with certificates whose SPKI SHA-256 digest matches the denylist in Modules/_ssl/distrusted_spki.h.
• Logs: Application-level SSL errors or unexpected certificate validation failures after patching (indicating previously accepted compromised chains); TLS connection logs showing eMudhra intermediate CA issuers in certificate chains.
• File System: Presence of eMudhra intermediate CA certificates in bundled trust stores (e.g., certifi CA bundle, custom tls_ca_cert files in agent configurations); unpatched Python installations (versions prior to the security backports for 3.11–3.15).
• Process: Python processes making outbound TLS connections that do not raise ssl.SSLCertVerificationError when connecting to servers presenting eMudhra-signed certificates (on unpatched versions) (CPython PR #160042, CPython Issue #160040).

The primary remediation is to upgrade to patched versions of CPython. The fix was merged into main (3.16+) on October 24, 2026, and backported to branches 3.11, 3.12, 3.13, 3.14, and 3.15 (PRs #160568–#160572). Users should upgrade to the patched security releases for their respective Python branch as soon as they are published. As a workaround for older Python versions, explicitly configure certificate revocation checking (CRL or OCSP) in all SSLContext instances used by applications. Additionally, organizations should update their OS trust stores, container base images, and bundled CA bundles (e.g., certifi) to remove the compromised eMudhra intermediate CA certificates, and audit applications that use tls_ca_cert or custom CA bundles for eMudhra root inclusion (CPython PR #160042, GitHub Advisory).

Python core developer Christian Heimes (tiran) proposed and implemented the fix, framing it as a defense-in-depth measure analogous to Go's response to CVE-2026-111943, and emphasized the systemic problem of packages like certifi and pip shipping their own CA bundles containing eMudhra roots. Python Security Manager Seth Larson raised concerns about the precedent of requiring Python runtime upgrades for CA distrust events, preferring mechanisms like CRL integration or OS-level revocation. Developer Steve Dower (zooba) questioned whether users could update Python runtimes faster than OS certificate stores. The Python team ultimately agreed to document a high threshold for adding entries to the denylist, limiting it to globally trusted CA compromises enabling MitM attacks. The fix was labeled a release blocker and backported to all active Python branches (CPython Issue #160040, Python Security Announce).