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 Microsoft platforms have since October 20 and Apple products since October 22. 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

Update, Oct 28, 2026, 7:18 a.m. Manila: Microsoft is removing six eMudhra roots and a related cross-sign from Windows and Edge. In a Microsoft Security Response Center post dated October 26 and updated October 27, Microsoft says it blocked the compromised intermediates through the Windows Disallowed Certificate Trust List on October 20 and through a CRLSet update for Edge and WebView2. It has now gone further. An out-of-band Windows update on October 26 removes seven certificates, “six eMudhra G3 roots and an AAA Certificate Services cross-sign,” from the Windows trust list, and on October 27 Microsoft removed the same seven from Edge’s trust list. The Windows update is aimed at machines that don’t get automatic certificate trust list updates, such as disconnected devices or those with automatic updates turned off; for Windows 10 21H2 and 22H2 it’s KB5134125, and for Windows 11 24H2, 25H2 and 26H2 it’s the October 26 out-of-band update KB5134133. Microsoft’s advice: keep automatic Windows certificate and Edge component updates flowing, make sure disconnected Windows devices and Azure VMs get the update, and if any of your certificates chain to one of the seven removed certificates, get a replacement “before the changes reach your devices.” It warns against restoring trust locally without understanding the risk. This replaces our earlier note that we hadn’t seen a statement from Microsoft itself.

Update, Oct 24, 2026, 9:18 a.m. Manila: The disclosure site again lists Composer’s ca-bundle as patched and now lists Erlang’s certifi 2.18.0 and Red Hat Enterprise Linux 8 to 10 as patched; we’ve updated the lists.

Update, Oct 23, 2026, 10:40 a.m. Manila: The disclosure site now says Apple products have blocked the certificates since October 22, not October 19, and lists Composer’s ca-bundle as pending again; it also lists Bun, Python and more tools as patched and adds test hosts that show whether a client enforces Certificate Transparency. We’ve updated the dates and package lists.

Update, Oct 22, 2026, 10:11 a.m. Manila: The disclosure site now lists patched Node.js, Java and FreeBSD packages and a Windows script for machines without automatic updates; we’ve updated the package lists.

Update, Oct 21, 2026, 9:39 a.m. Manila: The disclosure site now says Microsoft platforms have blocked the certificates since October 20, and lists patched Fedora, Perl Mozilla::CA and Cloudflare CFSSL packages; we’ve updated the browser status, Chrome’s root store status and the package lists.

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 now says Apple products have blocked them since October 22 (it earlier said October 19); we haven’t seen a statement from Apple itself. The disclosure site says Microsoft platforms have blocked them since October 20; its maintainer updated that on October 21 after users reported that Windows had received the update. Microsoft has since confirmed it blocked them on October 20 (see the October 28 update above). 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; Chromium’s public root store file listed version 43 without that root when we checked at 9:36 a.m. Manila, but Chrome hasn’t said whether that update has reached users.
  • 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 and Microsoft platforms 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 9:18 a.m. Manila on October 24, the disclosure site lists patched ca-certificates versions for Ubuntu, Debian, Devuan, Arch Linux, Gentoo, Fedora, Red Hat Enterprise Linux 8, 9 and 10 (RHEL 7 is pending), Oracle Linux, FreeBSD, Alpine, Chainguard and Homebrew, plus the curl CA bundle dated 2026-10-20. Fedora’s own update system shows its ca-certificates 2026.2.92 update as stable for Fedora 43, 44 and 46 and in testing for Fedora 45. 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 9:18 a.m. Manila on October 24, patched versions on the disclosure site’s list include Node.js 22.23.4, 24.22.1 and 26.12.1; Java 27.0.1.0.2, 25.0.5.0.2, 21.0.13.0.2, 17.0.21.0.2, 11.0.33.0.2 and 8u511 (OpenJDK and Oracle JDK); Python’s certifi 2026.10.19, pip 26.2.2 and uv 0.13.5; Go 1.27.3 and 1.26.10; Deno 2.9.8; 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; Elixir’s castore 1.0.22; Perl’s Mozilla::CA 20261020; and Cloudflare’s CFSSL trust store 2026.10.1. Bun 1.4.4, Python 3.15.1, 3.14.9 and 3.13.17, and Erlang’s certifi 2.18.0 are listed too. Bottlerocket and Godot are still marked “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. For Windows machines that don’t get Microsoft’s automatic certificate updates, such as offline ones, it offers a PowerShell script, which it says “is not recommended for enterprise-managed devices.”

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 28, 2026, at 7:18 a.m. Manila time (October 27, 23:18 UTC). Microsoft’s root removals and advice in the October 28 note come from Microsoft’s own MSRC post and KB5134125 and KB5134133 release notes. Earlier checks: October 24, 2026, at 9:18 a.m. Manila time (October 24, 01:18 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, and Microsoft’s status before October 28, come only from the disclosure site; Chrome’s root store version comes from Chromium’s public root store file; 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.