ResourcesBlog
Eight CA Keys Compromised: What the eMudhra Incident Teaches About Trust
Private keys for eight eMudhra intermediate certificates were weak enough to recover from public data. Mozilla, Chrome, Apple, and Microsoft rushed to block them. The trust system worked this time. Your certificate inventory may not.
Leonard EsereReading time 5 min
- Private keys for eight eMudhra intermediate certificates could be recovered from public data because the keys were generated with almost no randomness.
- Six of the certificates sign TLS traffic. Two sign code. They were trusted by the Mozilla, Microsoft, Apple, and Chrome root programs.
- Mozilla, Chrome, Apple, and Microsoft blocked the certificates between October 17 and 20, 2026. eMudhra revoked them on October 18.
- Governance lesson: keep a living inventory of the certificates and trust anchors your systems rely on, and a process for removing trust fast.
The lock was weaker than the door
TLS is the encryption behind the padlock in your browser. TLS stands for transport layer security. A certificate authority, or CA, issues the certificates that prove a website is who it claims to be.
On October 17, 2026, a researcher told browser security teams about a fatal problem. Eight intermediate certificates from India's eMudhra were affected. Their private keys could be recovered from public data. The keys were RSA keys with one prime factor under 256. That is a single byte. Real keys need long random factors. These had almost none.
Anyone with those keys could forge certificates for any website. The browser would trust them.
How the trust system responded
Mozilla's Dennis Jackson announced the compromise on the oss-security mailing list on October 20. Six of the certificates sign TLS traffic. Two sign code. All were trusted by the Mozilla, Microsoft, Apple, and Chrome root programs.
The response was fast. Mozilla blocked the certificates for Firefox users on October 17. It used its OneCRL revocation list. The block landed within three hours of the first report. Chrome pushed a block through its CRLSet the same day. Apple blocked them on October 19. Microsoft followed on October 20. eMudhra revoked the certificates on October 18.
Cloudflare called it a serious security incident with implications across the internet. Cloudflare said it found no active exploitation on its own network. The company had already deployed protections.
One detail softened the blow. Certificate Transparency logs show no end entity certificates issued under these intermediates since their creation in April 2025. That means browsers that enforce transparency could not have been attacked. Many other clients do not enforce it. Embedded devices, containers, and old Linux systems often skip the check.
India's CERT-In published an advisory. CERT-In is India's national cybersecurity agency. It said the weak keys came from a flaw in eMudhra's key generation process. A second set of weak keys was published alongside the original, securely generated keys. The weak set ended up in browser root stores.
Why this is a supply chain story
A supply chain compromise does not always mean malware in a package. Here the compromised item is trust itself. Every system that trusted eMudhra's chain inherited the weakness. The fix is not a patch. It is removing trust, updating trust stores, and checking that every client actually got the update.
Google's next step shows the scale. Chrome will remove the emSign ECC Root CA-G3 certificate from the Chrome Root Store starting October 27, 2026. That is the root above the weak intermediates. Removing a root can break legitimate sites that still use it. Trust removal has a blast radius of its own.
The governance lesson
Most teams cannot list the certificates their systems trust. They cannot name the CAs in their trust stores. They have no process for an emergency distrust.
Governance asks for three things here. First, an inventory of certificates and trust anchors across your systems. Second, a review cadence for that inventory. Third, a tested path to push trust store updates when a CA fails.
Three records prove the work. The inventory itself, dated. The review record that shows someone checked it. The incident runbook that names who pushes the trust update and how.
Build those now. The next CA compromise will not come with this much luck attached.
Update, October 22, 2026
Verification of the primary sources corrected two details in this article. The weak keys were RSA keys with one prime factor under 256, not elliptic curve keys. Mozilla's own records confirm the timeline. Mozilla and Chrome blocked on October 17. eMudhra revoked on October 18. Sectigo revoked its cross-signs on October 19.
Mozilla released Firefox 158.0.1 on October 20 with the updated OneCRL block list. It tracks the compromise as CVE-2026-113470. NSS 3.131.1, also released October 20, removes trust in the emSign roots above the weak intermediates. The lesson stands. Trust removal is the fix, and it has a blast radius of its own.
Sources
- eMudhra Intermediates Compromise, Dennis Jackson, Mozilla, oss-security mailing list, October 20, 2026. https://www.openwall.com/lists/oss-security/2026/10/20/1
- India's cybersecurity agency warns of compromise of eMudhra intermediate CA certificates, CERT-In advisory reported October 21, 2026.
- Protecting Firefox users following the compromise of eMudhra intermediate certificates, Mozilla Security Blog, October 20, 2026. https://blog.mozilla.org/security/2026/10/20/protecting-firefox-users-following-the-compromise-of-emudhra-intermediate-certificates/
- CVE-2026-113470 record, CVE Program. https://www.cve.org/CVERecord?id=CVE-2026-113470
Next step
Want control evidence that pulls itself from your live systems? See how PolicyCortex collects it on Azure.
- What happened with eMudhra?
- Private keys for eight eMudhra intermediate certificates were compromised. The keys were generated with dangerously weak randomness, so anyone could recover them from public certificate data.
- Was anyone actually attacked?
- No confirmed attacks have been reported. Certificate Transparency logs show no certificates issued under the weak intermediates since they were created in April 2025. The risk window was still real for clients that do not enforce transparency checks.
- What did browsers do?
- Mozilla and Chrome blocked the certificates on October 17 through their revocation lists. Apple and Microsoft also moved to block the affected certificates. Mozilla released Firefox 158.0.1 with the updated block list on October 20, tracking it as [CVE-2026-113470](https://www.cve.org/CVERecord?id=CVE-2026-113470).
Related records
Guides and articles describe the work. The evidence that work produces is described in three proof pages and one architecture page.
- proof.state
- Proof of State. What the environment was, as of a date someone else picks: point-in-time records, content hashed and chained.
- proof.change
- Proof of Change. Who or what altered the environment, under what authority, with before and after state hashes.
- proof.agency
- Proof of Agency. What a machine was permitted to do before it acted, what it did, and what would have stopped it.
- architecture
- Architecture. How the chain is built and where it lives: inside your tenant, with no egress of evidence.
Further reading in this register
- Stolen Keys, Signed Commands: The UpdraftCentral Supply Chain BackdoorAttackers stole TeamUpdraft's UpdraftCentral keys and pushed backdoors to WordPress sites as properly signed commands. No plugin flaw was needed. Patchstack rates the impact 9.8.
- You Cannot Patch What You Forgot: PHP2Shell, LiteLLM, and GovernanceTwo failures on October 21, 2026 made the same gap public. One hid in a language runtime. One hid in a trusted release. Governance means you can prove what runs, what version, and what you fixed.
Verify the record this entry describes.
- Published
- Last updated
- Unchanged since publication
- Author
- Leonard Esere