Repository navigation
ssl: distrust compromised eMudhra intermediate CA keys #160040
Description
Feature or enhancement
I propose to add a small denylist to _ssl that rejects any TLS certificate chain containing one of the recently compromised eMudhra intermediate CA keys. The check runs during certificate verification and matches the DER-encoded SubjectPublicKeyInfo, so cross-signed certs that reuse a key are blocked, too.
Yesterday a set of eMudhra intermediate keys were disclosed as compromised and revoked, see https://emudhra.we-have-a-problem.com/. d=4 isn't a secure EC private key. Removing trust is the root store's job, but the update lags in practice, and there is no reliable way to propagate an intermediate revocation to applications. Until the roots are gone, Python still completes handshakes through a known-bad key.
As a defense in depth Python should blocks those connections in the meantime. With a simple callback, this can be enforced on every SSLContext when verification is enabled (CERT_OPTIONAL / CERT_REQUIRED); CERT_NONE is unaffected.
Has this already been discussed elsewhere?
No response given
Links to previous discussion of this feature:
Golang has implemented filtering to address CVE-2026-111943.
- Go issue: crypto/x509: mitigation for security concerns with a specific Certificate Authority golang/go#82345
- Go fix (crypto/x509): https://go.dev/cl/851047
- eMudhra disclosure and affected intermediates: https://emudhra.we-have-a-problem.com/
Linked PRs
- gh-160040: Distrust compromised eMudhra intermediate CA keys (CVE-2026-115557) #160042
- [3.15] gh-160040: Distrust compromised eMudhra intermediate CA keys (CVE-2026-115557) (GH-160042) #160568
- [3.14] gh-160040: Distrust compromised eMudhra intermediate CA keys (CVE-2026-115557) (GH-160042) #160569
- [3.13] gh-160040: Distrust compromised eMudhra intermediate CA keys (CVE-2026-115557) (GH-160042) #160570
- [3.12] gh-160040: Distrust compromised eMudhra intermediate CA keys (CVE-2026-115557) (GH-160042) #160571
- [3.11] gh-160040: Distrust compromised eMudhra intermediate CA keys (CVE-2026-115557) (GH-160042) #160572
- gh-160040: Add ssl eMudhra distrust entry to whatsnew #160583
- [3.15] gh-160040: Add ssl eMudhra distrust entry to whatsnew #160584
- [3.11] gh-160040: Add ssl eMudhra distrust entry to whatsnew #160591
- [3.12] gh-160040: Add ssl eMudhra distrust entry to whatsnew #160592
- [3.13] gh-160040: Add ssl eMudhra distrust entry to whatsnew #160593
- [3.14] gh-160040: Add ssl eMudhra distrust entry to whatsnew #160594
Activity
pythongh-160040: Distrust compromised eMudhra intermediate CA keys
pythongh-160040: Distrust compromised eMudhra intermediate CA keys
tiran commentedon Oct 21, 2026
CC RMs @hugovk @Yhg1s @pablogsal and security @sethmlarson
pythongh-160040: Fix c-analyzer check and add What's New entry
pythongh-160040: Add tests for distrusted eMudhra intermediate CA keys
zooba commentedon Oct 21, 2026
I don't see why we should assume that users can update their entire application runtime faster than their OS certificates.
Certificate bundles are intended to be updated efficiently and without breaking unrelated parts of the applications relying on them. Updating a Python release is nowhere near as safe.
pythongh-160040: Match distrusted SPKI by SHA-256 digest
sethmlarson commentedon Oct 21, 2026
Thanks for suggesting this and submitting a patch @tiran. My biggest concern is the precedence that this sets, would we reach for this functionality for future compromises and tell users to upgrade their Python? I know you're putting this forward as defense-in-depth so it's not either-or, but I am cautious about signing us up for more expedited releases and asking users to mitigate by updating the Python runtime.
My preference is providing users and distributions mechanisms to resolve these issues themselves without requiring a series of expedited Python releases and upgrades. Maybe this would take the form of a defined pattern for integrating a CRL for Python distributions? (upki?) And maybe leaning more on Windows and macOS certificate APIs?
tiran commentedon Oct 21, 2026
The situation would be far less messy if packages would stop shipping their own trust store and solely rely on system trust store. Then users would only need to update or reconfigure their OS and everything would be fine. I'm looking forward to a world where every Linux OS has something like upki or a PKCS#11 provider with OS-wide revocation lists and policies.
It's 2026 and
certifiis still a thing... On top of that, packages likepipalso vendorcertifi. And that's just the tip of the ice berg! I know of at least one more packages with almost 14 million downloads per day that ships a custom root CA bundle with eMudhra certs (the maintainers are aware). Let's not forget about packages with upper version caps that prevent security updates.I don't have to explain to you how serious a compromise root or intermediate CA is. Thankfully it does not happen that often. The last major compromises happened in 2011. DigiNotar got owned and TurkTrust accidently issued two CAs. I strongly believe that this event requires special care and defense-in-depth. Google felt the same way.
tiran commentedon Oct 21, 2026
Sorry, I forgot to address your biggest concern:
I agree, it's a valid concern. Let's document when and why Python is blocking certificates:
23 remaining items
[3.14] gh-160040: Distrust compromised eMudhra intermediate CA keys (…
tiran commentedon Oct 24, 2026
@sethmlarson @gpshead @Yhg1s @hugovk You may have to release security updates of Python 3.13-3.15 with my fix ASAP.
Please take a look at @JSGette comment on DataDog/datadog-agent#58679
It looks like Windows still ships the Sectigo / Comodo AAA Certificate Service in Windows' trust store.
ssl.create_default_context()loads the trust anchor. I do not have access to a Windows machine at the moment. Can somebody test and confirm the issue?tiran commentedon Oct 24, 2026
I have created and backported whatsnew entries for the CVE fix. 3.16 and 3.15 PRs are ready. I'm hitting the open pull request limit for 3.14 to 3.14:
hugovk commentedon Oct 24, 2026
@tiran I've added you to the bypass list so you can open more PRs.
[3.13] gh-160040: Distrust compromised eMudhra intermediate CA keys (C…
[3.12] gh-160040: Distrust compromised eMudhra intermediate CA keys (C…
[3.13] gh-160040: Add ssl eMudhra distrust entry to whatsnew (#160593)
[3.12] gh-160040: Add ssl eMudhra distrust entry to whatsnew (#160592)
gh-160040: Add ssl eMudhra distrust entry to whatsnew (#160583)
[3.15] gh-160040: Add ssl eMudhra distrust entry to whatsnew (#160584)
[3.11] gh-160040: Add ssl eMudhra distrust entry to whatsnew (#160591)
[3.14] gh-160040: Add ssl eMudhra distrust entry to whatsnew (#160594)