In this article
  1. What happened
  2. Who needs to act
  3. What to do now
  4. What we’ll watch

TL;DR: The private keys behind eight eMudhra intermediate certificates have been compromised. Six of them are for TLS and chain to roots trusted by Chrome, Mozilla, Microsoft and Apple, so anyone holding a key could forge a certificate for any website. Firefox and Chrome have blocked them since October 17, and the disclosure site says Apple devices have since October 19. Servers, containers, command-line tools and app runtimes that don’t check revocation may still trust them until you update. Update your OS certificate packages and runtimes, rebuild your container images, and upgrade cloudflared if you use Cloudflare Tunnel. Don’t “fix” new certificate errors by turning verification off.

What happened

Mozilla says it received a report on October 17 at 20:06 UTC (October 18, 4:06 a.m. Manila time), forwarded by the Chrome root program, that the private keys of eight eMudhra intermediate certificates had been compromised. The report came with proof of control of all eight keys. Mozilla then recovered the keys on its own, “confirming the key generation process was flawed and is trivial to exploit,” according to its incident report on Mozilla’s bug tracker.

  • Which certificates: Mozilla’s report says six of the eight are for TLS and are “trusted by the Chrome, Mozilla, Microsoft and Apple root programs.” The other two are for code signing and are trusted by Microsoft. All eight were also cross-signed by Sectigo, according to the disclosure site’s list of affected certificates, and Sectigo said on October 19 that it had finished revoking those cross-signed certificates.
  • What an attacker could do: in Cloudflare’s words, “an attacker can create a forged certificate for any domain and use it to impersonate servers to intercept or modify traffic.”
  • How it happened: the disclosure site published by Mozilla’s Dennis Jackson says the CA generated the keys incorrectly, so “anyone can recover them from the certificates.” It says this has been possible since the certificates were created in April 2025. It also says there are no Certificate Transparency log entries for these intermediates in that period, so browsers that enforce CT, such as Firefox, Chrome, Edge and Safari, “could not have been attacked.” Many clients outside browsers don’t enforce CT, and “We do not know if attackers exploited the flawed key generation to target these clients.”
  • What eMudhra says: in a statement posted to Mozilla’s bug on October 19 (comment 10), eMudhra said the eight were created in one key ceremony on April 30, 2025, and that the G3B and G3C TLS CAs “were not put into production except” EM DV TLS CA - G3C, “but no end entity certificates were issued from these.” It said the code-signing CAs were not put into production and did not issue any certificates. On October 20, after Mozilla said it would remove the root, eMudhra said it had ceased issuance from all intermediates chaining to its G3 ECC root.
  • What’s been done: Firefox blocked the certificates on October 17 through OneCRL, finishing at 22:59 UTC (October 18, 6:59 a.m. Manila). The Chrome Root Program says it landed a CRLSet update on October 17 at 19:45 UTC that blocks the keys of all six TLS intermediates, which also covers Sectigo’s cross-signed copies. The disclosure site says Apple devices have blocked them since October 19; we haven’t seen a statement from Apple itself. Microsoft’s status was unconfirmed as of 7:40 a.m. Manila on October 21: we found no Microsoft statement, and an open issue on the disclosure site’s tracker is titled “Microsoft fix state is uncertain.” eMudhra marked the eight certificates as revoked on October 18 at 09:38 UTC, per Mozilla’s report. On October 20, Mozilla said it is releasing an update to NSS, its trusted certificate list, that removes the root used to sign these intermediates. Chrome said the same day that it “will soon release” Chrome Root Store version 43 without that root; as of our check, that removal was still pending.
  • Cloudflare’s response: Cloudflare published its post on October 20 at 22:20 UTC (October 21, 6:20 a.m. Manila). It says it learned of the issue on October 19 at about 17:00 UTC, has found no active exploitation on its own services, and finished its CDN and server-side Zero Trust mitigations on October 20 at 19:20 UTC. “There’s much work still to be done,” it says.

Who needs to act

Firefox and Chrome block these certificates through their revocation lists, and the disclosure site says Apple devices do too. The risk is everything else: software that checks certificates against its own list and doesn’t consume revocation updates. The disclosure site says “many other clients do not consume revocation information and require software updates.” That includes:

  • Your servers and containers, which use the operating system’s ca-certificates package. A Docker image built last week still carries last week’s list until you rebuild it.
  • Your code’s HTTP clients. Cloudflare’s advice for developers is to “look beneath the SDK”: an API client may hand certificate checks to an HTTP library, the language runtime, the operating system or a custom trust store, so “updating the SDK alone may not change the underlying policy.”
  • Cloudflare customers running Cloudflare Tunnel, the Cloudflare One (WARP) client, mutual TLS, or origin servers in Full (strict) mode.

What to do now

  1. Update the certificate packages on every server and in every image. As of 7:40 a.m. Manila on October 21, the disclosure site lists patched ca-certificates versions for Ubuntu, Debian, Arch Linux, Gentoo, Alpine, Chainguard and Homebrew, plus the curl CA bundle dated 2026-10-20. At that time, Fedora and FreeBSD were still listed as “pending.” Then rebuild and redeploy your container images, and restart services so they load the new list.
  2. Update your runtimes and package tools. As of 7:40 a.m. Manila on October 21, patched versions on the disclosure site’s list include Python’s certifi 2026.10.19, pip 26.2.2, uv 0.13.4, Go 1.27.3 and 1.26.10, Rust’s rustls-webpki 0.103.16 and webpki-roots 1.0.10, Electron 44.9.1, 43.8.1 and 42.11.16, NSS 3.131.1, Composer’s ca-bundle 1.4.16 and 1.6.0, and Elixir’s castore 1.0.22. At that time, Node.js and Bun were still listed as “pending.” Some of these sit deep in your dependency tree, so check your lockfiles, not just your top-level packages.
  3. If you use Cloudflare Tunnel, upgrade cloudflared to 2026.10.2. For container deployments, Cloudflare says to “update and redeploy the fixed image.” Cloudflare One (WARP) users should update to the client versions listed in Cloudflare’s post.
  4. Test the real connection path. The disclosure site has test addresses: a certificate error means your client no longer trusts the bad intermediates. Cloudflare warns that a passing browser test “does not prove that a background service is protected,” and neither does a curl test “if the application uses a different verifier.” Run the check from the service itself.
  5. Don’t switch off verification. Cloudflare says you may see new certificate errors after patching, and that you shouldn’t fix them “by disabling verification.” If an AI coding agent suggests verify=False or a similar flag to make an error go away, reject that change. We’ve covered why agents shouldn’t blindly trust tool output in our guide to stopping AI agents from trusting the wrong tool outputs.
  6. Check your own site’s certificate. Mozilla says removing the root “will impact the availability of some servers for those non-Firefox users until those servers move to new certificate chains.” Our advice: if your site’s certificate chains to emSign ECC Root CA - G3, the root Mozilla is removing (look for emSign ECC Root CA - G3 in the certificate chain), get a new one from another CA now rather than wait for the removal to break connections. eMudhra says it will move its affected customers to chains under its RSA root, emSign Root CA - G1, which Mozilla says it isn’t removing at this time. Cloudflare says it is updating Automatic SSL/TLS to notify you if you still use these distrusted certificates.

The disclosure site also gives commands to distrust the affected roots by hand on Linux, macOS and BSD. It says this is for expert users and “NOT recommended for ordinary users,” so we’d wait for your distribution’s package unless you know exactly what depends on those roots.

What we’ll watch

Mozilla says it “will provide more information in this thread as soon as circumstances allow,” and the list of patched packages is still growing. We’ll update this story if the cause, the scope or the list of affected software changes. For another recent case where a trusted connection turned out to be the weak point, see our story on ConnectWise suspending Cloud Backup.

Sources & method

Sources

Method. Last checked October 21, 2026, at 7:40 a.m. Manila time (October 20, 23:40 UTC). The timeline, the certificate counts, the cause, eMudhra’s and Sectigo’s statements, and Mozilla’s and Chrome’s actions come from Mozilla’s bug report and forum post (including the Chrome Root Program’s post there) and from the disclosure site; Apple’s status comes only from the disclosure site; Cloudflare’s actions and advice come from its post; patched versions come from the disclosure site’s table at the time we checked. We haven’t tested any of the packages ourselves. The advice to replace certificates that chain to the removed root, to wait for distribution packages, and to reject agent changes that turn off verification, is our own judgment. No affiliate links on this page. How we work.

Spotted an error? See our corrections policy and tell us.