Repository navigation
gh-160040: Distrust compromised eMudhra intermediate CA keys (CVE-2026-115557) - #160042
Merged
Merged
Conversation
tiran
requested review from
AA-Turner,
emmatyping,
erlend-aasland,
gpshead,
itamaro and
picnixz
as code owners
October 21, 2026 15:03
Several eMudhra intermediate CA keys were compromised and revoked. As defense in depth, reject any chain containing one of the affected public keys, so connections are blocked even when the root store (OS, container) has not yet dropped the issuing roots or certifi/pip are not updated. The denylist in `Modules/_ssl/distrusted_spki.h` matches the DER-encoded SPKI, so cross-signed certificates that reuse a key are blocked too. Mirrors Golang's [crypto/x509](https://go.dev/cl/851047) change. See https://emudhra.we-have-a-problem.com/. Signed-off-by: Christian Heimes <[email protected]>
tiran
force-pushed
the
ssl-distrust-emudhra-keys
branch
from
October 21, 2026 15:03
a2f652f to
6275d65
Compare
Name the SPKI table struct type and list the const table in the c-analyzer "should be const" ignore list, so check-c-globals passes. Document the new verification behavior in What's New for 3.16. Signed-off-by: Christian Heimes <[email protected]> Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
tiran
added
type-security
Closed
Documentation build overview
48 files changed ·
|
tomato42
reviewed
Oct 21, 2026
Signed-off-by: Christian Heimes <[email protected]>
gpshead
reviewed
Oct 21, 2026
Signed-off-by: Christian Heimes <[email protected]>
sethmlarson
reviewed
Oct 21, 2026
gpshead
reviewed
Oct 21, 2026
gpshead
added
needs backport to 3.11
github-project-automation
Bot
moved this from In Progress
to Done
in Release and Deferred blockers 🚫
|
Sorry, @tiran and @gpshead, I could not cleanly backport this to Please backport manually with cherry_picker, see the devguide for more information. |
|
Sorry, @tiran and @gpshead, I could not cleanly backport this to Please backport manually with cherry_picker, see the devguide for more information. |
|
Sorry, @tiran and @gpshead, I could not cleanly backport this to Please backport manually with cherry_picker, see the devguide for more information. |
|
Sorry, @tiran and @gpshead, I could not cleanly backport this to Please backport manually with cherry_picker, see the devguide for more information. |
|
Sorry, @tiran and @gpshead, I could not cleanly backport this to Please backport manually with cherry_picker, see the devguide for more information. |
Member
|
backports coming |
|
GH-160568 is a backport of this pull request to the 3.15 branch. |
|
GH-160569 is a backport of this pull request to the 3.14 branch. |
|
GH-160570 is a backport of this pull request to the 3.13 branch. |
|
GH-160571 is a backport of this pull request to the 3.12 branch. |
|
GH-160572 is a backport of this pull request to the 3.11 branch. |
gpshead
added a commit
that referenced
this pull request
Oct 24, 2026
…CVE-2026-115557) (GH-160042) (#160568) The ssl module now rejects TLS certificate chains that contain any of a set of compromised eMudhra intermediate CA keys. This is an extraordinary measure and a last line of defense: removing trust is primarily the job of the platform root store, and the built-in denylist only blocks connections while that update has not yet reached the OS, a container image, or a bundled trust store in various Python packages. Entries are added to the denylist only under a very high threshold. The denylist matches on the public key (the SHA-256 digest of the RFC-5280 SubjectPublicKeyInfo), so it also covers the cross-signed certificates that reuse one of the distrusted keys. --------- (cherry picked from commit 7dd8b47) Co-authored-by: Christian Heimes <[email protected]>
gpshead
added a commit
that referenced
this pull request
Oct 24, 2026
…CVE-2026-115557) (GH-160042) (#160569) The ssl module now rejects TLS certificate chains that contain any of a set of compromised eMudhra intermediate CA keys. This is an extraordinary measure and a last line of defense: removing trust is primarily the job of the platform root store, and the built-in denylist only blocks connections while that update has not yet reached the OS, a container image, or a bundled trust store in various Python packages. Entries are added to the denylist only under a very high threshold. The denylist matches on the public key (the SHA-256 digest of the RFC-5280 SubjectPublicKeyInfo), so it also covers the cross-signed certificates that reuse one of the distrusted keys. --------- (cherry picked from commit 7dd8b47) Co-authored-by: Christian Heimes <[email protected]>
Yhg1s
pushed a commit
that referenced
this pull request
Oct 24, 2026
…VE-2026-115557) (GH-160042) (#160570) The ssl module now rejects TLS certificate chains that contain any of a set of compromised eMudhra intermediate CA keys. This is an extraordinary measure and a last line of defense: removing trust is primarily the job of the platform root store, and the built-in denylist only blocks connections while that update has not yet reached the OS, a container image, or a bundled trust store in various Python packages. Entries are added to the denylist only under a very high threshold. The denylist matches on the public key (the SHA-256 digest of the RFC-5280 SubjectPublicKeyInfo), so it also covers the cross-signed certificates that reuse one of the distrusted keys. (cherry picked from commit 7dd8b47) Co-authored-by: Christian Heimes <[email protected]>
Yhg1s
pushed a commit
that referenced
this pull request
Oct 24, 2026
…VE-2026-115557) (GH-160042) (#160571) The ssl module now rejects TLS certificate chains that contain any of a set of compromised eMudhra intermediate CA keys. This is an extraordinary measure and a last line of defense: removing trust is primarily the job of the platform root store, and the built-in denylist only blocks connections while that update has not yet reached the OS, a container image, or a bundled trust store in various Python packages. Entries are added to the denylist only under a very high threshold. The denylist matches on the public key (the SHA-256 digest of the RFC-5280 SubjectPublicKeyInfo), so it also covers the cross-signed certificates that reuse one of the distrusted keys. (cherry picked from commit 7dd8b47) Co-authored-by: Christian Heimes <[email protected]>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Several eMudhra intermediate CA keys were compromised and revoked. As defense in depth, reject any chain containing one of the affected public keys, so connections are blocked even when the root store (OS, container) has not yet dropped the issuing roots or certifi/pip are not updated.
The denylist in
Modules/_ssl/distrusted_spki.hmatches the DER-encoded SPKI, so cross-signed certificates that reuse a key are blocked too. Mirrors Golang's crypto/x509 change. See https://emudhra.we-have-a-problem.com/.