Skip to content
NewCybercrime Report 2026 · Eight Chapters · A Post Is Not An Incident → Explore The ChaptersCybercrime Report 2026 → Explore

eMudhra CA Key Compromise (October 2026)

In October 2026 a researcher reported that the private keys of eight eMudhra intermediate certificate authorities were so weak that anyone could recover them.

Published
Updated
Reading Time
8 min read
Dark glass master key with a red cracked bow, cover for the eMudhra CA key compromise incident

In October 2026 a researcher reported that the private keys of eight eMudhra intermediate certificate authorities were so weak that anyone could recover them. Browser makers blocked the intermediates within hours, eMudhra revoked them on 18 October, and Mozilla decided to remove the emSign ECC Root CA - G3. Software with its own CA bundle, such as older pip, uv and certifi, stays exposed until updated.

What happened

eMudhra’s incident statement says that on 17 October 2026 an independent researcher reported that the private keys of eight of its intermediate CAs were weak. Mozilla received a similar report the same day, and Mozilla’s bug record says Mozilla recovered the keys itself that evening.

The keys are P-384 keys. Mozilla’s bug says their private values were tiny integers below 256. Scott Helme lists values from 4 to 237 and says all 16 affected certificates, the eight eMudhra ones and eight Sectigo cross-signs, were recovered in under a second.

eMudhra says a key generation ceremony on 30 April 2025 produced a second, weak key set that was used by mistake. It says the HSMs were FIPS 140-2 Level 3 certified and that the flaw was in one procedural step. Its root cause analysis is not final.

Timeline

  1. 30 Apr 2025

    eMudhra says the intermediates were created in a key generation ceremony where a wrap and unwrap step produced a second, weak key set.

  2. May 2025

    Scott Helme reports that Sectigo's AAA Certificate Services root cross-signed the intermediates.

  3. 17 Oct 2026

    A researcher reports the weak keys. Chrome pushes a CRLSet update that evening and Mozilla blocks the intermediates through OneCRL, per Scott Helme and eMudhra.

  4. 18 Oct 2026

    eMudhra revokes all eight intermediates with reason caCompromise. certifi 2026.10.18 is released and removes all emSign roots.

  5. 19 Oct 2026

    Go 1.26.10 and 1.27.3 are released with crypto/x509 security fixes, per the Go release history. Apple begins blocking the 12 affected TLS certificates, per Apple Support.

  6. 19 to 20 Oct 2026

    Sectigo revokes the affected cross-signed CAs and Mozilla decides to remove the emSign ECC Root CA - G3, per the Mozilla bug.

  7. 20 Oct 2026

    eMudhra publishes its statement and tells the Mozilla bug it has ceased issuance under the emSign ECC Root CA - G3. certifi 2026.10.19, pip 26.2.2 and uv advisory GHSA-hq85-5cpj-mr62 appear. Microsoft publishes a Windows Disallowed Certificate Trust List update that blocks all eight keys, and an emergency CRLSet update for Edge and WebView2.

  8. 21 Oct 2026

    Cisco Talos publishes its advisory and reports no malicious use as of 14:00 UTC. The Go vulnerability entry GO-2026-6809 is published. Oracle publishes Security Alert CVE-2026-91403, whose Java updates distrust the impacted intermediates.

  9. 22 Oct 2026

    eMudhra says Sectigo-issued certificates are available as an alternative for affected customers.

  10. 22 Oct 2026

    eMudhra announces it will withdraw from the global SSL/TLS certificate business and says its G1 RSA roots keep serving customers during the transition.

  11. 23 Oct 2026

    eMudhra writes in the Mozilla bug that its analysis will take time. The Chrome Root Program answers that delayed responses are not acceptable, and Mozilla says eMudhra has not yet answered the questions it sent on 20 October. Apple also begins blocking the emSign ECC Root CA - G3.

  12. 24 Oct 2026

    Oracle publishes Security Alert CVE-2026-114820 with Java updates that remove the impacted eMudhra roots. Python announces CVE-2026-115557, a denylist of known compromised certificates in its ssl module.

  13. 25 Oct 2026

    Python 3.11.18, 3.12.16, 3.13.18, 3.14.10 and 3.15.2 are released with the ssl denylist of CVE-2026-115557, per the Python changelogs.

  14. 26 Oct 2026

    eMudhra leadership writes on its status page that "the flaw was ours" and that a script error resulted in issuing CAs with weak keys. It says it will publish a root cause analysis through the CCADB process and is commissioning an independent expert review. Microsoft releases out-of-band Windows updates (KB5134133 for Windows 11, KB5134125 for Windows 10) that remove six eMudhra G3 roots and an AAA Certificate Services cross-sign from the Windows trust list.

  15. 27 Oct 2026

    Google had said Chrome would remove the emSign ECC Root CA - G3 in Chrome Stable on this date. In the Mozilla bug the Chrome Root Program says its checks found no further weak CA keys. It also says eMudhra's fourth root application has been denied. eMudhra says it answered Mozilla's questions in direct correspondence. Microsoft removes the same seven certificates from the Edge trust list.

  16. 28 Oct 2026

    eMudhra says the roughly 30,800 certificates under the affected G3 hierarchies belong to a client ecosystem in the United States. That ecosystem now uses an alternate pathway through the G1 RSA root. It has asked the browser programs for time to move that ecosystem and says it will stop issuing TLS certificates from G1 once the move is complete.

  17. 29 Oct 2026

    eMudhra attaches to the Mozilla bug its response to the Chrome Root Program's questions, after first sharing it with the browser programs directly.

  18. 30 Oct 2026

    Cloudflare reports about 22,000 attempted handshakes with the weak keys on its own outbound connections and about 160 forged certificates, with no evidence of interception. eMudhra appoints KPMG as its independent external reviewer. GitHub's advisory database lists GHSA-5xjx-3w67-w9x9 for the PyPI publishing action.

How the attack worked

This is a key generation failure, not an intrusion. eMudhra says a bug in the ceremony script created a second key pair on the HSM. Similar key names led to the wrong keys being used for the certificate requests.

With a recovered key, an attacker could sign a certificate for any hostname. To use it against a victim, the attacker would also need to intercept the victim’s connection. The client would need to trust the chain and skip revocation and Certificate Transparency checks. Scott Helme says many non-browser clients do skip them.

Who says who was behind it

There is no attacker to attribute. eMudhra attributes the weak keys to human error and a code flaw during an approved test deviation, per its preliminary account in the Mozilla bug.

Impact

eMudhra says none of the eight intermediates issued end-entity certificates, and that impact is limited to TLS certificates chaining to the distrusted root for one US customer ecosystem. eMudhra estimated in the Mozilla bug that about 30,000 certificates need migration, about 97 percent issued through ACME. The Chrome Root Program counted about 30,800 in Certificate Transparency data, 99.9 percent from two subordinate CAs of one operator, which fits eMudhra's "one customer ecosystem" statement. eMudhra says it is not aware of the keys being exploited before disclosure.

Government and regulator response

  • Mozilla blocked the intermediates through OneCRL on 17 October and shipped updated Firefox and ESR releases (eMudhra statement, Mozilla bug).
  • Chrome, Mozilla and Apple blocked the six TLS intermediates (Cisco Talos, 21 October).
  • Microsoft blocked all eight keys in the Windows Disallowed Certificate Trust List on 20 October. It blocked the six TLS keys through an emergency CRLSet for Edge and WebView2 the same day. On 26 October it released out-of-band Windows updates (KB5134133, KB5134125) that remove six eMudhra G3 roots and an AAA Certificate Services cross-sign from the Windows trust list. It removed the same seven from the Edge trust list on 27 October (Microsoft).
  • Apple has blocked the 12 affected TLS certificates since 19 October and the emSign ECC Root CA – G3 since 23 October. Mac command-line tools that read /etc/ssl/cert.pem, such as curl and git, can still accept them until a future macOS update (Apple Support).
  • certifi 2026.10.19, pip 26.2.2, uv 0.13.4 and Go 1.26.10 or 1.27.3 are the fixed versions (project advisories and release notes).
  • pypa/gh-action-pypi-publish 1.14.3, released on 20 October, upgrades certifi and sigstore. GHSA-5xjx-3w67-w9x9 covers 1.14.2 and earlier.
  • Oracle’s Security Alerts CVE-2026-91403 (21 October) and CVE-2026-114820 (24 October) ship Java updates that distrust the impacted eMudhra intermediates and remove the impacted eMudhra root CAs.
  • Python’s CVE-2026-115557 (24 October) adds a denylist of known compromised certificates to the ssl module. The fix ships in Python 3.11.18, 3.12.16, 3.13.18, 3.14.10 and 3.15.2, released on 25 October.
  • eMudhra appointed KPMG as its independent external reviewer on 30 October (eMudhra statement).
  • Cisco Talos published Snort SIDs 67363 to 67374 for coverage.

Lessons

  1. Key generation needs an independent check

    The flaw went unnoticed for about 18 months across two audit cycles, per eMudhra.

  2. Removing a root from the operating system is not enough

    The Python forum thread says pip loads its own certifi in addition to the system store, so an old pip kept trusting the root. Microsoft says some software does not check revocation or its disallowed list. Such software could still accept certificates from the compromised intermediates if trust in the removed roots is kept or restored locally.

  3. Revocation and transparency are not enforced everywhere

    Scott Helme says most non-browser clients trust a CA bundle on disk and do not check revocation or Certificate Transparency by default. Cloudflare's late-October probes found more than half of probes on large networks still accepting the compromised chain.

  4. Frozen trust stores age badly

    Talos flags VPNs, proxies, embedded devices and package manager TLS paths with stale CA stores as the places that stay exposed.

What to check in your own organization

  1. Inventory clients with their own CA bundle

    List build hosts, CI runners, container images and appliances, and record the pip, certifi, uv and Go version in each.

  2. Check the fixed versions

    pip 26.2.2 or later, certifi 2026.10.19 or later, uv 0.13.4 or later, Go 1.26.10 or 1.27.3 or later. In GitHub Actions, use pypa/gh-action-pypi-publish 1.14.3 or later. pip and certifi are checked with pip --version and python -c "import certifi; print(certifi.__version__)". The post Python, uv and Docker update steps for the eMudhra CA keys walks through these checks one by one.

  3. Rebuild container images

    The certifi advisory says to rebuild images that vendor certifi so their CA stores refresh. Check pip inside the rebuilt image.

  4. Test the client

    The checker on emudhra.we-have-a-problem.com has hosts that chain through the affected intermediates. A client that connects without an error still trusts them.

  5. Update the operating system store

    Apply the distribution's ca-certificates update. On Windows, install KB5134133 (Windows 11) or KB5134125 (Windows 10) on disconnected devices, and replace certificates that chain to the seven removed roots, as Microsoft advises. On a Mac, curl, git and other tools that read /etc/ssl/cert.pem can still accept the certificates until a future update, says Apple. Its support page shows how to remove the roots.

  6. Review package manager TLS paths

    Talos advises checking the real dependency path. Lockfile hashes, checksums and signatures may limit the impact.

Frequently Asked Questions

What did eMudhra get wrong?

eMudhra says a key generation ceremony on 30 April 2025 created a second, weak set of P-384 keys by mistake, and those keys were used for eight intermediate CAs.

Were the weak keys used in an attack?

eMudhra says it is not aware of evidence that the keys were recovered or exploited before disclosure. Cisco Talos saw no malicious use as of 21 October 2026, 14:00 UTC. Cloudflare later logged about 160 handshakes with forged certificates made after the keys leaked. It says they looked like servers' default certificates and found no evidence of interception.

Which root is being removed?

Mozilla decided to remove the emSign ECC Root CA - G3, and Google says Chrome will too. eMudhra says its G1 roots remain active. Google says it is still reviewing eMudhra's remaining CA certificates. Microsoft removed six eMudhra G3 roots and an AAA Certificate Services cross-sign from the Windows trust list on 26 October and from Edge on 27 October. Apple has blocked the emSign ECC Root CA - G3 since 23 October.

Are browsers still exposed?

Chrome, Mozilla and Apple blocked the six affected TLS intermediates, according to Cisco Talos. Microsoft says its Windows Disallowed list has blocked all eight keys since 20 October. Apple says curl, git and other Mac tools that read /etc/ssl/cert.pem can still accept them until a future macOS update. Software that carries its own CA bundle stays exposed until updated.

Is there a CVE?

Yes, four CVEs now relate to it. Oracle's Java alerts are CVE-2026-91403 (21 October) and CVE-2026-114820 (24 October), and Python's ssl denylist is CVE-2026-115557. The Go database lists CVE-2026-111943 (GO-2026-6809); Cisco Talos links it to the eight eMudhra intermediates. The certifi and uv advisories list none.

Sources

  1. certifi bundles emSign root CAs with compromised intermediate CA keys (GHSA-6q48-6c7w-9gw2)GitHub Advisory Database
  2. eMudhra Private Key Compromise of Intermediate Certificates (Bug 2083449)Mozilla Bugzilla
  3. eMudhra Certificate Security IncidenteMudhra
  4. Compromised eMudhra intermediate certificatesCisco Talos
  5. Information for Python users regarding the eMudhra emSign CA certificate security incidentPython Discourse
  6. Protecting Chrome and Android users from compromised eMudhra intermediate CA certificatesGoogle
  7. Microsoft, response to compromised eMudhra certificate authority keysMicrosoft Security Response Center
  8. 4 real? Tracking exploitation and patching of eMudhra's weak keysCloudflare
ShareLinkedInX
Brandefense logo

Stay Ahead of Digital Threats.

Take control of your digital security with an exclusive demo of our AI-driven threat intelligence platform.

Open The Full Demo Form →