Skip to content

Response, New York. Noah Park: Check Point Patches Actively Exploited Management Server Path Traversal. Detection, Dallas. Ava Okello: Report Finds Nearly Half of Deployed Detections Need Attention Before SOCs Can Trust Them.

SOCtember

Always First. Fast SOC News.

Cloudflare illustration of a magnifying glass over a red key marked with the number 8, beside a stylized certificate, for its post on the eMudhra intermediate certificate compromise.
Illustration: Cloudflare, from "8 eMudhra certificates are compromised. Here's what you need to know," Oct 20, 2026 (fair use).

Response

Mozilla, Google and Cloudflare Say Eight Compromised eMudhra Intermediate CA Keys Could Forge HTTPS Certificates for Any Site, and Trust Stores Outside the Browser Still Need Updates

Browsers blocked the eight intermediate certificates within hours of an Oct. 17 report, but Go, Python, Node.js, Linux distributions, TLS-inspecting proxies and other software that does not check revocation or Certificate Transparency must be patched, rebuilt or reconfigured before they stop trusting certificates forged with the keys.

Noah Park, ResponseNew York6 min read

NEW YORK - Security teams are being told to check certificate trust well beyond the web browser after the private keys behind eight intermediate certificate authorities operated by eMudhra, an India-based certificate authority, turned out to be recoverable by anyone holding the public certificates. Mozilla said in an Oct. 20 post that the keys "could allow attackers to issue fraudulent HTTPS certificates for websites they do not control."

Google's Chrome Root Program said a security researcher reported the problem at 18:05 UTC on Saturday, Oct. 17, and that the private keys "were generated with insufficient randomness (i.e., weak cryptographic entropy), enabling anyone to forge trusted HTTPS certificates to impersonate any website." Mozilla said it received its report at 20:06 UTC the same day. Fenko Security, which reproduced the key recovery, wrote in an analysis updated Oct. 21 that each of the eight P-384 private keys is a whole number below 256, and that one of them is 4.

eMudhra said the intermediates were created in a key generation ceremony on April 30, 2025, on FIPS 140-2 Level 3 hardware security modules. It said a key wrap and unwrap step "produced a second, weak set of keys alongside the original strong keys," and that "the weak keys were the ones published to the browser root stores." The company said the flaw went undetected for about 18 months through two independent audit cycles, that it revoked all eight intermediates on Oct. 19, that seven were never used in production and that the one in production "had not issued a single certificate." It said it has not yet confirmed the exact root cause.

Browsers moved within hours

Chrome said that at 19:45 UTC on Oct. 17 it landed a CRLSet update that blocks the affected intermediates by their Subject Public Key Info hashes, protecting users without a browser update or restart. Android devices received an equivalent update through Google Play Services around 22:00 UTC on Monday, Oct. 19, Google said.

Mozilla said its OneCRL block reached all Firefox users with standard configurations by 22:59 UTC on Oct. 17, "in less than 3 hours after we received the report." It released Firefox 158.0.1 for desktop and Android, Firefox ESR 115.43.1 and Firefox ESR 153.5.1 for users whose settings kept them from the OneCRL update, and it is removing the root that signed the intermediates from NSS 3.131.1. On Oct. 21 it shipped Firefox for Android 158.0.2 to fix clients that were not applying the bundled blocklist immediately after startup.

Screenshot of the Mozilla Security Blog post "Protecting Firefox users following the compromise of eMudhra intermediate certificates," dated October 20, 2026, describing the OneCRL block, the Firefox 158.0.1 and ESR releases and the NSS 3.131.1 root removal.
Screenshot: Mozilla Security Blog, Firefox Security Team, Oct 20, 2026 (fair use).The post was updated on Oct. 21 with the Firefox for Android 158.0.2 release.

A test site run by Mozilla's Dennis Jackson, which Cloudflare cited in its guidance, says the certificates have been blocked in Firefox and Chrome since Oct. 17, on Apple devices since Oct. 19 and on Microsoft platforms since Oct. 20.

Chrome is also removing emSign ECC Root CA - G3, the root that signed the compromised intermediates, from the Chrome Root Store. Google said the removal is expected to reach all devices relying on that store on the morning of Tuesday, Oct. 27, Pacific time, and that website operators with certificates chaining to the root "must immediately acquire and install a new TLS certificate from another PKI hierarchy." eMudhra said the distrust affects one customer ecosystem in the United States and that it is issuing replacement certificates from another publicly trusted hierarchy.

Screenshot of the Google Security blog post "Protecting Chrome and Android Users from Compromised eMudhra Intermediate CA Certificates," dated Oct 20, 2026, by the Chrome and Android Security Teams.
Screenshot: Google Security blog, Chrome and Android Security Teams, Oct 20, 2026 (fair use).

Why the browser fix is not the whole fix

Google said no TLS certificates chaining to the affected TLS intermediates were logged to Certificate Transparency before its block, so no fraudulent certificates from them could have been used against clients that enforce CT, including Chrome. It said CT logs now reject certificates that chain to the compromised CAs.

That protection does not extend to most software outside the browser. "Many clients outside of the browser ecosystem do not enforce Certificate Transparency. We do not know if attackers exploited the flawed key generation to target these clients," the test site says. It adds that many clients "do not consume revocation information and require software updates" to stop trusting the intermediates. eMudhra said it is not aware of any evidence that the weak keys were recovered or exploited before the disclosure.

Cloudflare said it became aware of the compromise at about 17:00 UTC on Oct. 19, patched services that authenticate remote endpoints and updated shared trust stores and base images. It said its review "has not identified active exploitation of this issue on Cloudflare services," and that CDN and server-side Zero Trust mitigations were fully deployed by 19:20 UTC on Oct. 20. It also warned teams that may see new certificate errors after patching: "It's important to not resolve these errors by disabling verification."

Screenshot of the eMudhra Intermediate CA Compromise test site dated 20th October 2026, showing how the reporter proved the compromise and a table of the twelve intermediate CA test hosts chaining to emSign Root TLS CA - G3 and AAA Certificate Services.
Screenshot: eMudhra Intermediate CA Compromise test site (emudhra.we-have-a-problem.com), Oct 20, 2026 (fair use).The results column fills in when a browser runs the check.

What responders should do now

  • Test real TLS paths, not just browsers. The test site suggests running curl against https://dv-g3b-emudhra.we-have-a-problem.com/ and https://dv-g3b-aaa-emudhra.we-have-a-problem.com/; a certificate error means the client no longer trusts the intermediates. Cloudflare noted that a passing browser test does not prove a background service is protected.
  • Patch bundled trust stores. The test site lists fixed versions including Go 1.27.3 and 1.26.10, NSS 3.131.1, Python certifi 2026.10.19, pip 26.2.2, uv 0.13.4, Node.js 22.23.4, 24.22.1 and 26.12.1, rustls-webpki 0.103.16, webpki-roots 1.0.10, Electron 44.9.1, 43.8.1 and 42.11.16, and the Oct. 20 curl CA bundle, plus ca-certificates updates for Ubuntu, Debian, Alpine, Arch and Fedora. It lists FreeBSD ca_root_nss and Bun as pending.
  • Rebuild, not just upgrade. Fenko Security notes that a Go binary is fixed only when it is rebuilt with the patched toolchain, and that the Go fix is tracked as CVE-2026-111943. Rebuild container images and restart services that load trust stores at startup.
  • Check macOS command-line tools. The test site says the built-in curl, git, python3, perl, ruby and openssl on macOS verify against /etc/ssl/cert.pem without checking revocation, and that the file has not been updated.
  • Cover TLS inspection and proxies. Fenko Security recommends blocking the eight public keys by SPKI hash on middleboxes that support it until vendors ship updates. Cloudflare said Gateway users with an up-to-date Cloudflare One client are protected automatically, and told cloudflared users to upgrade to 2026.10.2.
  • Review mutual TLS and origin trust. Cloudflare told customers to review trust stores used to verify client certificates and origin certificate configurations, and Google said certificates chaining to emSign ECC Root CA - G3 need replacing before Oct. 27.
  • Keep verification on. Treat new certificate errors as a signal to fix the trust chain, as Cloudflare advised, not as a reason to turn validation off.

Sources:


Noah Park covers incident response, containment, and blue-team operations for SOCtember from New York.

Related stories

Response desk