Key facts
- Browser makers including Google, Mozilla, Apple, and Microsoft blocked the eight certificates between October 17 and October 20.
- Mozilla's OneCRL block for standard Firefox users was complete by 22:59 UTC on October 17.
- Apple blocked the certificates on October 19 and Microsoft blocked them on October 20.
- Wayne, a researcher identified only by that name, reported the compromise to root programs on the evening of October 17.
Browser makers including Google, Mozilla, Apple and Microsoft blocked eight intermediate TLS (Transport Layer Security) certificates issued by India-based certificate authority eMudhra Limited between Oct. 17 and Oct. 20, 2026.
An intermediate certificate authority signs website certificates, so anyone holding its signing key could create credentials that browsers accept. A researcher known only as Wayne reported the compromise to root programs (the programs that maintain trusted root stores) on the evening of Oct. 17 and demonstrated control of all eight intermediate CA private keys by digitally signing a short message with each key. Mozilla completed its OneCRL block for standard Firefox users by 22:59 UTC on Oct. 17.
Google’s Chrome received the report at 18:05 UTC on Oct. 17 and had a block in place by 19:45 UTC. Apple blocked the certificates on Oct. 19, and Microsoft blocked them on Oct. 20. Go blocked the eight certificates in security releases on Oct. 20 on its URGENT track without naming the certificate authority. The Go project maintainers cited an unspecified operational security concern and did not identify eMudhra by name.

The eight compromised certificates are EM DV TLS CA – G3B, EM DV TLS CA – G3C, EM OV TLS CA – G3B, EM OV TLS CA – G3C, EM EV TLS CA – G3B, EM EV TLS CA – G3C, EM OV CS CA – G3B, and EM OV CS CA – G3C. Six are TLS intermediates that chain to emSign Root TLS CA – G3 and emSign ECC Root CA – G3, while two are code-signing intermediates that chain to emSign Root CS CA – G3. Chrome’s TLS verifier does not build trust paths through code-signing intermediates, so those two did not require a separate block. Each of the eight has a cross-signed copy sharing its public key under Sectigo’s AAA Certificate Services root.
Mozilla took emSign ECC Root CA – G3 out of its NSS trust store on Oct. 20. Chrome plans to remove the same root in root store version 43 and is examining eMudhra’s emSign Root CA – G1. Both Chrome and Firefox dropped trust in Sectigo’s AAA Certificate Services root for websites during April 2025, while Apple’s root list for iOS 26 and macOS 26, published in December 2025, still includes the Sectigo root. Each of the eight compromised certificates has a cross-signed copy sharing its public key under that Sectigo root.
Certificate transparency logs show no evidence of malicious issuance using the compromised keys to date. Investigators do not know how the keys left eMudhra, when they departed, or whether anyone besides the researcher possesses them. Ars Technica and Cloudflare describe them as weak, while Cyber Security News says the disclosures confirm researcher control but do not show how fast a cryptographic attack could recover the keys.
Mozilla says it does not believe the compromise affects other certificate authorities, and Chrome reported finding no further instances of this failure mode across its store. Google’s Chrome Root Program reviewed all other CA certificates in its store and detected no further cases. Mozilla is collaborating with eMudhra and other trust store operators to investigate the root cause and will share more information later.
eMudhra, based in India, sells emSign-branded certificates through firms in India, the United States, and the Netherlands and maintains roots in the Mozilla, Chrome, and Apple stores. Previous certificate authority incidents include the 2011 DigiNotar breach, Symantec’s chronic mis-issuance in 2017, and Google’s 2025 decision to stop trusting Chungwa and Netlock.
The compromise affects embedded and Internet of Things devices and other systems that are difficult and time-consuming to update. Filippo Valsorda, a cryptography engineer and Go cryptography maintainer, said, “This will be a massive cleanup job, bigger than Heartbleed,” and described a long tail involving IoT, Docker, Linux machines, and command-line interface (CLI) tools.
Go issued patched versions 1.27.3 and 1.26.10, while releases 1.25 and older receive no fixes because they are unsupported. A filter in Go’s standard library blocks certificate chains that contain one of the eight compromised keys and cannot be disabled. A program picks up the fix only when rebuilt with the new release.
Software that relies on Go binaries or Python’s certifi bundle does not check revocation data and continues trusting chains until administrators install updated code or root bundles. Mozilla issued Firefox 158.0.1, ESR 115.43.1 and ESR 153.5.1 to reach users who might not receive OneCRL updates. The NSS 3.131.1 update removes the signing root from trusted lists used by applications other than Firefox.
Mozilla says operators should block the eight intermediates now if their software can block individual intermediates, or consider removing trust in the signing roots otherwise. Test endpoints and certificate chains on the disclosure site help administrators check remaining exposure. Mozilla’s OneCRL and Chrome’s CRLSets are revocation lists that browsers fetch automatically without requiring an update or restart. Dennis Jackson said, “However, many other clients do not consume revocation information and require software updates to ensure they no longer trust the compromised intermediates.”
Cloudflare became aware of the compromise on Oct. 19, 2026 at approximately 17:00 UTC and found no active exploitation on its services. The company issued updates for its WARP client, the 1.1.1.1 app, and the cloudflared tunnel tool. Cloudflare deployed mitigations across its CDN (content delivery network), Developer, and Zero Trust products and refreshed shared trust stores, base images, and other shared foundations.
Cloudflare says to apply dependency updates, rebuild affected images, and confirm whether applications need a reload, restart, or redeployment. Developers should look beneath the SDK (software development kit) because an API client may delegate certificate verification to an HTTP library, language runtime, operating system, or custom trust setup.
Linux distributors continue to release patched ca-certificates packages, and system administrators should install them on compute nodes, edge devices, and CI/CD (continuous integration/continuous deployment) runners. Updated certifi, webpki-roots, and Homebrew ca-certificates bundles no longer include emSign ECC Root CA – G3. Homebrew’s ca-certificates also removes the Sectigo AAA Certificate Services root and drops emSign Root TLS CA – G3.
eMudhra revoked all eight compromised intermediate certificates. As of Oct. 20, eMudhra’s trust-services repository contained no notice about the incident. Public reporting offers no method to detect past key misuse other than searching Chrome’s Certificate Transparency logs, which cover only logged certificates.

Join the discussion