Security advisory: eight eMudhra CA keys compromised

On 17 October 2026, a security researcher reported that the private keys of eight intermediate certificate authorities (CAs) run by eMudhra, an Indian certificate authority, could be computed from public data. Browsers, operating systems and many applications trusted these intermediates. Anyone who holds such a key can issue a certificate for any domain, and that certificate would pass validation in software that has not been updated.

Browsers and Cloudflare's network are already protected. The software that may still be exposed is the software you run yourself: origin servers, containers, background jobs, API clients and anything else that bundles its own list of trusted CAs. This advisory explains what happened and what to check.

What happened

All eight certificates used P-384 elliptic-curve keys generated in April 2025. According to Mozilla's incident report, each private key was a number smaller than 256, so anyone could find it by trying at most 256 values. One researcher published the key for the "EM OV TLS CA - G3C" intermediate: it was 4.¹ eMudhra has said an error in a key-generation script produced a second set of weak keys, and those were mistakenly used to sign the certificates.²

The keys were not stolen. They were weak from the start, so they could have been recovered at any point since April 2025. There is no public evidence that anyone did so before the report. No certificate chaining to the six intermediates used for websites appeared in Certificate Transparency logs before Chrome blocked them.³ Chrome and other browsers that require Certificate Transparency would therefore have rejected a forged certificate. Software that does not check Certificate Transparency, which covers most server-side code, had no such protection.

The affected intermediates chain to the emSign ECC Root CA - G3 root. Some also chain to AAA Certificate Services (a Comodo root, now Sectigo) through cross-signed certificates.³ So removing only the emSign root does not fully protect older trust stores.

eMudhra has revoked the eight certificates and stopped issuing new certificates under the affected G3 root.²

Who is affected

Browsers are protected. Chrome, Firefox, Safari and Edge reject the compromised intermediates through revocation lists their vendors can update in minutes. Firefox users on unusual configurations should update to Firefox 158.0.1, ESR 153.5.1 or ESR 115.43.1.⁴

Cloudflare's network is protected. Cloudflare patched the services that check certificates presented by remote systems, including connections to your origin and calls to external APIs. It reports finding no active exploitation on its services.⁵

Software you operate may not be. Most server-side software does not ask the operating system or a browser vendor whether a certificate is trusted. It reads a CA bundle that was copied into a container image, pinned in a language package or shipped with a runtime, and that copy changes only when you update and restart. This includes:

• Containers and server images built before 20 October
• Backend services that call third-party APIs, payment providers or webhooks
• Go binaries, Python apps that use certifi, Node.js and Electron apps, Rust apps that use webpki-roots
• Appliances, agents and scripts that ship their own CA bundle
• /usr/bin/curl on macOS, which reads /etc/ssl/cert.pem without revocation checks. Apple had not updated that file at the time of writing.

An attacker would still need to be on the network path between that software and the server it calls. That is a high bar, but it is the exact scenario certificates exist to stop.

What to do

1. 1

   Update CA bundles and runtimes. Install the patched packages listed below, rebuild container images and check indirect dependencies too. Updating an SDK does not help if the HTTP library underneath reads a different trust store.

2. 2

   Restart or redeploy. Long-running processes keep the trust store they loaded at start-up. An updated package does nothing until the process restarts.

3. 3

   Update Cloudflare software. Upgrade cloudflared to 2026.10.2 (or redeploy the fixed container image). Update the Cloudflare One Client to 2026.8.2115.0 on desktop, 2.5.7 on Android or 1.12.7 on iOS, and the 1.1.1.1 app to 6.38.11 on Android or 6.31.8 on iOS.

4. 4

   Review mTLS trust stores. If you uploaded CAs to Cloudflare or your own servers to verify client certificates, make sure none of them is an affected eMudhra intermediate or root.

5. 5

   Check your origin certificates. If your zone uses Full (strict) or Strict SSL/TLS mode and your origin certificate was issued by an affected eMudhra intermediate, Cloudflare will stop trusting it. Replace it with a certificate from another CA or a Cloudflare Origin CA certificate before connections fail.

6. 6

   Test the real path. Run the test against the client your application actually uses, from where it actually runs.

Patched versions

These come from the community-maintained list on the disclosure site, which is updated as more fixes ship.³

Test a client

The disclosure site runs test hosts that present a certificate chain through a compromised intermediate. A protected client fails to connect. If the request succeeds, that client still trusts the compromised keys.

curl -sS https://dv-g3b-emudhra.we-have-a-problem.com/
curl -sS https://dv-g3b-aaa-emudhra.we-have-a-problem.com/

Test both hosts: the second one uses the cross-signed chain to AAA Certificate Services. Your exact error message will vary by client. What matters is that the connection fails. A passing test in your browser or your terminal says nothing about a background service using a different library, so run the test inside the container or from the host that runs the service.

To check whether your own origin certificate was issued by eMudhra:

$ openssl s_client -connect origin.example.com:443 -servername www.example.com </dev/null 2>/dev/null | openssl x509 -noout -issuer

An issuer containing emSign or eMudhra means you should check the issuing intermediate against the affected list on the disclosure site.

Do not turn off verification

After patching, some services may start failing with certificate errors. That is the fix working: something in that chain depends on a certificate that is no longer trusted. Find out which certificate it is and replace it. Setting verify=False, InsecureSkipVerify, NODE_TLS_REJECT_UNAUTHORIZED=0 or curl -k turns a contained incident into a permanent hole.

How Vigilbase can help

If Vigilbase manages your Cloudflare account, we can review your zones' SSL/TLS modes, origin certificates and uploaded mTLS CAs for the affected eMudhra certificates, and check your cloudflared versions. Contact your account team or our support team and reference this advisory.

If you are not a customer and are unsure whether your services are exposed, contact us and we will help you work through the checks above.

We will update this advisory as more fixes ship and as the root programs publish their final decisions.