Article
eMudhra CA Key Compromise: What Python, uv and Container Teams Must Update Now
Eight eMudhra CA keys were weak enough to recover. See what is true about the pip claim and the exact update and check list…
Read more
Significant cyber incident
eMudhra CA Key Compromise (October 2026)
Also known as eMudhra emSign CA incident, emSign intermediate CA key compromise
In October 2026 a researcher reported that the private keys of eight eMudhra intermediate certificate authorities were so weak that anyone could recover them.
In short
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 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
- 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.
- May 2025
Scott Helme reports that Sectigo's AAA Certificate Services root cross-signed the intermediates.
- 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.
- 18 Oct 2026
eMudhra revokes all eight intermediates with reason caCompromise. certifi 2026.10.18 is released and removes all emSign roots.
- 19 Oct 2026
Go 1.26.10 and 1.27.3 are released with crypto/x509 security fixes, per the Go release history.
- 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.
- 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.
- 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.
- 22 Oct 2026
eMudhra says Sectigo-issued certificates are available as an alternative for affected customers.
- 27 Oct 2026 (expected)
Google says Chrome will remove the emSign ECC Root CA - G3 in Chrome Stable on this date.
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.
No government or security company in the sources we opened reports that the keys were used in an attack.
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 and Microsoft the two code signing ones (Cisco Talos, 21 October).
- 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).
- Cisco Talos published Snort SIDs 67363 to 67374 for coverage.
Lessons
-
Key generation needs an independent check
The flaw went unnoticed for about 18 months across two audit cycles, per eMudhra.
-
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.
-
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.
-
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
-
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.
-
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. 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.
-
Rebuild container images
The certifi advisory says to rebuild images that vendor certifi so their CA stores refresh. Check pip inside the rebuilt image.
-
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.
-
Update the operating system store
Apply the distribution's ca-certificates update. The checker page says the macOS file /etc/ssl/cert.pem had not been updated when it was published.
-
Review package manager TLS paths
Talos advises checking the real dependency path. Lockfile hashes, checksums and signatures may limit the impact.
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.
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.
Are browsers still exposed?
Chrome, Mozilla and Apple blocked the six affected TLS intermediates, according to Cisco Talos. Software that carries its own CA bundle stays exposed until updated.
Is there a CVE?
The certifi and uv advisories list none. The Go vulnerability database lists CVE-2026-111943 (GO-2026-6809) for a Go denylist; Cisco Talos links it to the eight eMudhra intermediates.
In our research
Sources
- certifi bundles emSign root CAs with compromised intermediate CA keys (GHSA-6q48-6c7w-9gw2) GitHub Advisory Database
- Removal of emSign root certificate (GHSA-hq85-5cpj-mr62) Astral (uv)
- eMudhra Private Key Compromise of Intermediate Certificates (Bug 2083449) Mozilla Bugzilla
- eMudhra Certificate Security Incident eMudhra
- Compromised eMudhra intermediate certificates Cisco Talos
- Eight Bits of Trust: eMudhra's CA keys cracked in milliseconds Scott Helme
- Information for Python users regarding the eMudhra emSign CA certificate security incident Python Discourse
- pip changelog, release 26.2.2 Python Packaging Authority
- certifi release history Python Package Index
- GO-2026-6809 (CVE-2026-111943) Go vulnerability database
- Go release history The Go Project
- eMudhra emSign CA incident advisory and client checker Dennis Jackson and contributors
- Protecting Chrome and Android users from compromised eMudhra intermediate CA certificates Google
Browse the threat library
- APT groups State-backed hacking groups, who they go after and how they get in. 51 profiles
- Countries The sectors, groups and national bodies that matter in each country. 32 profiles
- Ransomware groups How each group gets in, how it extorts and what stops it. 26 profiles
- Malware and tools Malware families and abused tools, what they do and how to spot them. 57 profiles
- Techniques Attack techniques in plain words, mapped to MITRE ATT&CK. 41 profiles
- Vulnerabilities Flaws attackers use in real attacks and what to do about them. 58 profiles
- Significant Cyber Incidents Significant incidents since October 2024, with a dated timeline, sources and lessons. 107 profiles
Stay Ahead of
Digital Threats
Take control of your digital security with an exclusive demo of our AI-driven threat intelligence platform.