The eMudhra CA Key Compromise: How Eight Weak Keys Broke Trust Across the Internet
Eight eMudhra intermediate CA keys turned out to be small integers, not random 384-bit numbers. Here's the real timeline, the math, and who had to scramble.
- Eight eMudhra intermediate CA private keys weren't stolen, they were weak: P-384 keys that should be random 384-bit numbers turned out to be small integers under 256, recoverable by brute force in under a second.
- A researcher reported it to Mozilla at 20:06 UTC on October 17, 2026; Mozilla had independently recovered the keys and started blocking them within 90 minutes.
- Chrome, Firefox, Apple, and Microsoft all blocked the eight intermediates within three days, and Mozilla took the rare step of emergency-distrusting the entire emSign ECC Root CA - G3 root.
- No fraudulent certificate chaining to the weak intermediates has been found in Certificate Transparency logs, meaning the flaw was caught before (confirmed) abuse, not after.
- The blast radius went beyond browsers: Cloudflare had to patch its own client software, mutual-TLS trust stores, and container images, because the compromised root was trusted infrastructure-wide, not just in websites.
A certificate authority (CA) is a company the whole internet agrees to trust blindly. Your browser ships with a list of them built in. Every padlock icon you see depends on that list being honest. On October 17, 2026, a researcher found eight eMudhra CA keys that were never actually random, meaning anyone could guess them. Not hack them. Guess them. In under a second. On a laptop.
eMudhra is one of India's largest certificate authorities. Its root certificates sit inside billions of devices. So when eight of its keys turned out to be guessable, not stolen, just badly made, every major browser maker had about 72 hours to decide what to cut off, and how fast.
This report is built on Mozilla's Bugzilla incident record (bug 2083449), Mozilla's and Google's own security blog posts, Cloudflare's incident writeup, and independent technical analysis from researcher Scott Helme, each checked directly against the source. Figures reported only by secondary outlets and not confirmed in any primary source (such as a specific certificate migration count) are explicitly flagged as unconfirmed rather than stated as fact.
What eMudhra actually is
eMudhra is a publicly traded Indian company that operates emSign, a certificate authority trusted by every major root program: Mozilla, Google Chrome, Apple, and Microsoft. It issues TLS certificates for websites, code-signing certificates for software, and digital signature certificates used across Indian government and enterprise compliance workflows. Being in all four major root stores is a high bar. It means your root certificates are bundled into billions of devices, and your intermediates are the thing standing between that root and every certificate you issue.
The flaw: keys that were never actually random
Here's the simple version. A private key on the P-384 curve is supposed to be a huge random number, picked from a pool of roughly 2^384 possibilities. That pool is so big that no computer on Earth could ever guess one by trying numbers one at a time. The whole system only works because the number is actually random.
eMudhra's eight keys weren't random. Mozilla's analysis found each one was a tiny number, smaller than 256. Researcher Scott Helme pulled the real values straight from the public certificates. One key was the number 4. The rest were 56, 115, 155, 156, 230, 66, and 237. Instead of picking from 2^384 possibilities, eMudhra had, by accident, picked from 256.
“One of the eight private keys securing part of the internet's trust infrastructure was the number 4.”
Think of it like a combination lock. A real private key is like a lock with 2^384 possible combinations: too many to ever try by hand. But a key under 256 is like a lock with only 256 combinations. You just try them all. Helme recovered all eight keys in under a second on a normal laptop. One detail that's stuck with the security community talking about this incident: a single prompt to an AI coding assistant was reportedly enough to redo that same recovery from scratch.
How it happened, per eMudhra's own account
So how does a huge company with certified hardware end up with a key that's basically the number 4? eMudhra's own explanation, filed with Mozilla, points to a key-generation ceremony on April 30, 2025. That ceremony ran inside a hardware security module (a locked-down device built specifically to generate and protect keys safely). During a side test of that device, meant to check that keys could be safely exported, something went wrong. The device generated a second, much weaker set of keys by mistake. The two sets had similar internal names. Someone grabbed the wrong one. That weak set got signed into real certificates, and those certificates were also cross-signed by another CA, Sectigo, spreading the same weak keys into a second chain that most browsers ignore for websites, but that some platforms, including Apple's, still trust.
Mozilla has explicitly flagged this as preliminary and still under investigation. Its own timeline analysis found that six of the affected CRLs started failing signature verification on May 23, 2025, which doesn't cleanly line up with the May 29 creation date eMudhra gave for a related replacement key set. Mozilla has not resolved that discrepancy as of publication.
The 72-hour response: who blocked what, and when
What makes this incident notable isn't just the cryptographic failure. It's how fast four independent root programs coordinated a response, without a shared playbook, over a weekend.
| When | Event |
|---|---|
| Oct 17, 18:05 | Researcher reports the issue, with proof of key control for all eight certificates, to Apple, Chrome, Microsoft, Mozilla, and eMudhra simultaneously |
| Oct 17, 19:45 | Chrome pushes a CRLSet update blocking the six TLS intermediates by public key hash; no browser restart required |
| Oct 17, 20:06 | Mozilla receives the forwarded report |
| Oct 17, 20:08 | Mozilla acknowledges the report and confirms the proof of key control is valid |
| Oct 17, 21:48 | Mozilla independently recovers the private keys itself, confirming the researcher's claim |
| Oct 17, 22:59 | Firefox's OneCRL distrust list finishes rolling out to standard-configuration users, under 3 hours after the initial report |
| Oct 18, 09:24–09:38 | eMudhra revokes all eight certificates with reason code caCompromise |
| Oct 19 | Apple begins blocking the certificates on iOS and macOS |
| Oct 19, ~17:00 | Cloudflare learns of the compromise and begins assessing impact across its own infrastructure |
| Oct 20 | Microsoft blocks the certificates; Mozilla and Google publish public incident posts; Firefox 158.0.1 and NSS 3.131.1 ship, removing the root entirely; Go, Python's certifi, and Rust's webpki-roots all ship patched releases dropping the root |
| Oct 27 (planned) | Chrome Root Store version 43 is scheduled to fully remove emSign ECC Root CA - G3; any site still chaining to it will break in Chrome |
Why this didn't become a mass phishing event
The scary version of this story: an attacker finds the weak keys first, and quietly forges certificates for real websites. That doesn't seem to be what happened here. Every certificate a trusted CA issues has to show up in a public log called Certificate Transparency. No browser will trust a certificate that isn't logged. Nobody has found a single forged certificate in those logs tracing back to the eight weak keys. That public log is the reason this stayed a contained incident instead of becoming a mass impersonation event.
- CT logging means any certificate issued from a compromised key leaves a public, permanent record, even if the attacker never uses it visibly. No such record exists for these keys.
- eMudhra has stated that only one of the eight weak intermediates was ever deployed in production, and that none of the eight had issued end-entity TLS certificates to real customers.
- Clients that don't enforce Certificate Transparency, things outside the mainstream browser ecosystem, are a genuine blind spot here. Whether anyone exploited the flaw against a non-browser client before disclosure is, honestly, unknown.
The blast radius: this wasn't just a browser problem
It's tempting to read this as "some websites needed new certificates." That undersells it. A root CA removal doesn't just affect the sites using that CA. It affects anything, anywhere, that trusts a shared system root or bundles its own copy of one. Cloudflare's own incident writeup is the clearest evidence of how far this actually reached.
| Layer | What broke or needed patching | Source |
|---|---|---|
| Browsers | Chrome, Firefox, Safari, Edge all needed emergency trust-store updates to block the specific intermediates | Mozilla, Google security blogs |
| Mobile platforms | Apple pushed trust updates to iOS/macOS; Android devices received a block via Google Play Services, independent of OS updates | Google security blog |
| CDN and edge infrastructure | Cloudflare had to patch its own client software (WARP, 1.1.1.1 app), update cloudflared, review mutual-TLS trust stores, and audit origin-server certificates across its Full (strict) TLS customers | Cloudflare incident writeup |
| Container and sandbox environments | Cloudflare Containers and Sandboxes needed image and dependency review, since bundled trust stores don't auto-update the way an OS does | Cloudflare incident writeup |
| Language runtimes and package ecosystems | Go (CVE-2026-111943), Python's certifi, and Rust's webpki-roots all shipped releases dropping the compromised root from their bundled trust stores | Go security advisory, incident tracker |
| Operating system distributions | Debian shipped ca-certificates security updates (DSA-6572-1) removing the root for every Debian and derivative system | Debian security advisory |
| Server software still pending a fix | Node.js and Bun had not shipped a release with the fix at time of the incident tracker's last update, meaning some runtimes stayed exposed longer than browsers did | Community incident tracker |
“The certificates were trusted by browsers, operating systems, and Cloudflare. The issue affects certificate-based authentication, not TLS's encryption algorithms.”
Why scanners and standard SCA tooling wouldn't have caught this
Worth saying plainly: this is a different kind of failure than what shows up in a normal dependency scanner. A software composition analysis tool checks your packages and versions for known bugs. A weak CA key isn't a package. It has no version number. It won't show up in any dependency list you run. The only things that catch a flaw like this are independent math checks against real certificates, which is exactly what the reporting researcher did, or watching Certificate Transparency logs closely, which most engineering teams simply don't do day to day.
If your organization runs its own internal CA, or issues client certificates for mutual TLS, this is a good prompt to check: does your key generation process produce independently auditable randomness, and would you actually catch it if it didn't? eMudhra's own HSMs were FIPS 140-2 Level 3 certified. The hardware wasn't the problem. The process around it was.
What to actually do about it
For most teams, the direct action item here is narrow but real:
- Check whether any of your TLS certificates, client certificates, or code-signing certificates chain to emSign ECC Root CA - G3. If you don't know, check with your certificate management tooling or ask your CA directly.
- If you're on that chain, migrate to a different certificate hierarchy before October 27, 2026, when Chrome Root Store version 43 is scheduled to drop trust in the root entirely.
- If you run software that bundles its own trust store rather than relying on the OS (older Go binaries, containers with vendored CA bundles, Python environments pinned to an old certifi), update explicitly. OS-level trust store fixes won't reach these automatically.
- If you operate your own internal CA or issue client certificates for mutual TLS, treat this as a prompt to audit your own key generation ceremony, specifically whether you'd catch a weak-key failure independently rather than trusting the HSM vendor's certification alone.
# Check whether a given cert chains to the affected eMudhra root
openssl x509 -in your-cert.pem -noout -issuer
# Walk the full chain and look for emSign names
openssl x509 -in your-cert.pem -noout -text | grep -A2 "Issuer:"
# For a live server, inspect the chain it presents
openssl s_client -connect yourdomain.com:443 -showcerts </dev/null 2>/dev/null \
| openssl x509 -noout -issuer -subject
# Check installed Go, Python, and Rust dependency versions against the patched releases
go version
python3 -c "import certifi; print(certifi.__file__)"
pip show certifi | grep -i versionThis isn't a conventional attack, so a MITRE ATT&CK mapping is a stretch, but the closest analog is T1587.001 (Develop Capabilities: Digital Certificates) describing the risk class a compromised CA key creates: the ability to forge certificates that let an attacker impersonate any domain they choose, if the flaw had been found by someone less inclined to report it.
The lasting lesson
Nobody breached eMudhra. Nobody stole a key from a vault. A test step in a key-generation ceremony went slightly wrong, produced a second set of keys nobody meant to use, and those keys ended up on certificates trusted by every major browser on earth. The flaw sat there, unexploited as far as anyone can tell, for a year and a half, until one researcher ran a routine check against keys that were never supposed to be guessable at all. The response, four competing root programs coordinating an emergency distrust within 72 hours, is the system working as designed. The fact that it took a weak key turning out to be the literal number 4 to trigger that response is the part worth sitting with.