Security Operations

eMudhra CA key compromise: what to patch beyond the browser

Browsers blocked eight compromised eMudhra CA keys in hours. Go binaries, Python bundles, Linux trust stores and appliances still need fixing.

Padlock graphic with the headline Compromised CA keys: fix your trust stores

Private keys for eight eMudhra intermediate certificate authorities have been exposed, and the major browsers blocked them within hours. The harder work is outside the browser: Go binaries, Python bundles, Linux trust stores and TLS inspection kit that often do not check revocation.

What happened

On the evening of Saturday 17 October 2026, a researcher credited only as “Wayne” told the browser root programmes that they held the private keys for eight intermediate CA certificates run by eMudhra, the Indian certificate authority that trades as emSign. Wayne proved it by signing a message with each key. Six of the intermediates issue TLS certificates (domain, organisation and extended validation) and two issue code-signing certificates.

Google’s Chrome Root Program had the report at 18:05 UTC and a CRLSet block covering the six TLS intermediates live 100 minutes later. Mozilla, notified at 20:06 UTC, finished distributing its OneCRL block to default Firefox configurations by 22:59 UTC. According to a disclosure page published by Mozilla cryptography engineer Dennis Jackson, Apple blocked the certificates on 19 October and Microsoft followed on 20 October. eMudhra has revoked all eight.

The incident became public on 20 October. Mozilla shipped Firefox 158.0.1 and two ESR builds, and removed the emSign ECC Root CA – G3 root from NSS 3.131.1. Google said Chrome Root Store version 43 will drop the same root, and that it is reviewing eMudhra’s remaining root, citing “the seriousness of this incident”. The same day, Go 1.27.3 and 1.26.10 (CVE-2026-111943) arrived, hard-coding a block on the eight keys without naming the CA.

The technical picture

Whoever holds an intermediate CA’s private key can mint a certificate for any domain that clients trusting the parent root will accept, letting someone on the network path impersonate a service and read or alter traffic.

Jackson’s disclosure page says the CA generated the keys incorrectly, so the private keys could be recovered from the public certificates themselves. If so, the keys have been exposed to anyone who looked since the intermediates were issued in April 2025. According to The Hacker News, eMudhra’s trust-services repository showed no incident notice as of 20 October.

There is some reassurance for browser users. Chrome, Firefox, Edge and Safari all require Certificate Transparency (CT) logging. Google says nothing issued under the six TLS intermediates appeared in CT logs before its block, so a forged certificate could not have been trusted by default in a CT-enforcing browser. It has since reviewed the rest of its root store and found no other CA with the same flaw.

The weak point is everything that does not enforce CT or consume revocation data. Each of the eight intermediates also exists as a Sectigo cross-signed copy under the AAA Certificate Services root, using the same public key. Chrome and Firefox no longer trust that root for websites, and Chrome’s block matches on the public key anyway. Apple’s December 2025 root list covering iOS 26 and macOS 26, however, still carried AAA Certificate Services. Jackson notes that macOS’s bundled curl uses a static certificate file, ignores revocation, and had not been updated.

The fixes take two forms. Go now rejects chains that include any of the eight public keys, whether verification runs in Go itself or is handed to the macOS or Windows platform verifier, and the block cannot be disabled. Protection arrives only when a binary is recompiled with a patched toolchain; Go 1.25 and earlier are unsupported and will not be fixed. Python’s certifi, Rust’s webpki-roots and Homebrew’s ca-certificates have removed the affected roots instead, and Homebrew has also removed the Sectigo root. According to The Hacker News, fixes for Node.js and Composer were still pending on 20 October.

Timeline of the eMudhra intermediate CA key compromise response from 17 to 20 October 2026

Why it matters for UK organisations

Few UK sites will have bought certificates from eMudhra, but that is not the issue. The risk is whether your clients would trust a forged certificate for your domains, or for your suppliers’ domains. Any organisation running Linux servers, containers, CI/CD pipelines, Go-based tooling or Python automation probably has trust stores that do not check revocation and will trust these chains until someone updates them.

Removing roots also breaks legitimate sites. Mozilla has warned that some servers will stop working for software relying on its root list outside Firefox until their operators reissue on new chains. If a partner’s API suddenly fails TLS validation after a package update, this incident is a likely cause.

The two code-signing intermediates need separate attention. Chrome left them alone because a CA restricted to code signing can never validate a website in its verifier. Application allowlisting, EDR trust decisions and software supply chain checks that rely on Authenticode signatures are a different matter. Microsoft has blocked the certificates on its platforms, but security teams should confirm that their own controls inherit that block and do not keep a separate trust list.

Expert view

The browser response was quick, and the CT requirement did its job. What worries me is the long tail.

When we test internal estates, the trust store is almost never in anyone’s asset register. It is baked into container base images, bundled with Python virtual environments, compiled into Go binaries and frozen into appliance firmware. In my experience, TLS inspection proxies, load balancers and OT gateways are the worst offenders, because they run vendor-supplied bundles that get updated on the vendor’s timetable, not yours. Go cryptography maintainer Filippo Valsorda made much the same point, arguing that revocation simply does not reach applications through Linux root stores, which is why Go hard-coded the keys.

The other open question is time. If the keys could be recovered from public certificates since April 2025, then “no CT entries” proves only that browsers were safe. It says nothing about non-browser clients. Nobody has published a way to detect misuse against those clients, so defenders should assume the exposure was possible and close it, rather than wait for proof.

What to do now

  1. Update browsers and operating systems. Check that Firefox Remote Settings is not blocked by policy or proxy. If it is, deploy 158.0.1 or the matching ESR. This is Cyber Essentials security update management in its simplest form.
  2. Rebuild Go services. Find every Go binary you build or deploy, rebuild it with 1.27.3 or 1.26.10, and retire anything still on Go 1.25 or older.
  3. Refresh bundled trust stores. Update certifi, webpki-roots and ca-certificates packages, rebuild container base images, and watch for distribution ca-certificates updates.
  4. Audit appliances. Ask vendors of TLS inspection, proxy, load balancer and gateway products whether their trust store still includes the emSign G3 roots or the Sectigo AAA Certificate Services root. Use the published impacted-intermediates list to check.
  5. Review code-signing trust. Confirm that allowlisting and EDR policies reject the two EM OV CS CA intermediates.
  6. Brief the service desk. Some legitimate third-party endpoints will fail validation as roots are removed.
  7. Make trust stores an asset. Add them to your Cyber Essentials secure configuration baseline.

Bottom line

Browsers were covered within hours, and Certificate Transparency appears to have stopped any forged certificate being trusted there. Everything else in your estate that speaks TLS without checking revocation still needs a rebuild or a bundle update. Treat this week as a trust store inventory exercise.

Sources

Related Posts