eMudhra certificate compromise: what to do with servers and images

The private keys of 8 intermediate certificates from the eMudhra certificate authority are compromised. According to Mozilla (2026), 6 of them are for TLS and 2 for code signing. Whoever holds such a key can issue a valid certificate for any domain, impersonate any website, and read or change its traffic. According to Aikido's analysis (2026), every one of these keys is smaller than 256, and one of them is the number 4.

Browsers blocked these certificates on their own. Servers, containers, command-line tools and runtimes such as Go, Node.js, Java and Python keep trusting them until someone updates them.

Short answer: what to do after the eMudhra key compromise

1. Update operating systems and browsers. That protects most users.
2. Update the ca-certificates package on servers and virtual machines.
3. Rebuild container images on a fresh base image and redeploy them.
4. Update runtimes with their own certificate list: Go, Node.js, Java, Python certifi, Rust webpki-roots.
5. Restart long-running services so they load the new list.
6. Test every service through its own TLS path.

eMudhra in numbers: statistics 2026

Figures checked on 23 October 2026.

• According to Mozilla (2026), 8 eMudhra intermediate certificates are compromised: 6 for TLS and 2 for code signing.
• According to Aikido's analysis (2026), an attacker needed at most 256 guesses to find each key, while a properly generated key of this type takes about 10^115.
• According to the incident site (2026), Firefox and Chrome have blocked these certificates since 17 October 2026, and Apple devices since 22 October.
• According to Mozilla (2026), eMudhra revoked the certificates on 18 October and Sectigo on 19 October 2026.
• According to Cloudflare (2026), it deployed its CDN and Zero Trust mitigations less than 27 hours after learning of the compromise at 17:00 UTC on 19 October.

Sources: eMudhra incident site, Mozilla on oss-security, Aikido, Cloudflare.

Who the eMudhra key compromise affects

Browsers have their own mechanisms to switch off trust in a bad certificate quickly. Most other software has none. It holds a list of trusted root certificates and accepts anything that chains to one. The only fix is to ship a new list.

At risk are:

• command-line tools: curl, git, python3, openssl, including the ones built into macOS that read /etc/ssl/cert.pem;
• containers and CI: an image keeps the certificate list from the day it was built;
• runtimes with their own list: Go, Java, Node.js, Python certifi, Rust webpki-roots;
• IoT devices that ship certificates in firmware and rarely get updates;
• code signing: 2 of the 8 certificates could sign software under any publisher name. Microsoft has blocked them since 20 October.

To use a forged certificate, an attacker has to sit on the network path, for example on a hostile Wi-Fi network or a compromised router. According to the incident site, the certificates never appeared in public Certificate Transparency logs, so browsers that enforce transparency could not be attacked. Software that does not check those logs could, and the incident site does not know whether anyone used the keys against it.

How bad the eMudhra key compromise is: examples

A certificate is a server's proof of identity. When software trusts a forged certificate, it talks to a criminal while believing it talks to a bank, a payment provider or your own API. The encryption still works, just with the wrong party. Mozilla told trust store maintainers that abuse of these keys is likely in the near future.

A personal data breach has legal consequences in the EU. Under the GDPR (2016), a company has 72 hours after becoming aware of a breach to report it to the supervisory authority. Under the GDPR (2016), failures in security and breach notification can be fined up to €10 million or up to 2% of total worldwide annual turnover, whichever is higher. Source: GDPR, Regulation 2016/679, Article 33 and Article 83(4).

Fixed versions: systems and runtimes

The incident site keeps the full list, including the packages still pending. Status changes daily. For Go, we cover the GO-2026-6809 fix in crypto/x509 separately.

To see your ca-certificates version:

dpkg -s ca-certificates | grep Version   # Debian, Ubuntu
apk info ca-certificates                 # Alpine
rpm -q ca-certificates                   # Fedora, RHEL

How to check whether a server still trusts the eMudhra certificates

The incident site provides two test addresses. Run the commands from the server or from inside the container:

curl -sS -o /dev/null -w "HTTP %{http_code}\n" https://dv-g3b-emudhra.we-have-a-problem.com/
curl -sS -o /dev/null -w "HTTP %{http_code}\n" https://dv-g3b-aaa-emudhra.we-have-a-problem.com/

An SSL error with HTTP 000 is the result you want. A 200 means that client still trusts the compromised certificates.

Cloudflare points out the limit of this test. A passing browser test does not prove a background service is protected. Nor does a curl test, if the application verifies certificates another way, for example through an HTTP library or the Go or Java runtime. Test every service through its own path.

What not to do after patching

After the update you may see certificate errors in logs and dashboards. Cloudflare warns against making them go away by switching off certificate verification. That removes the very protection the update restores. Find the cause instead: either the server on the other side uses a certificate from a blocked chain, or the service has its own outdated certificate store.

Cloudflare users have extra steps. Cloudflare Tunnel needs version 2026.10.2, and the Cloudflare One client and the 1.1.1.1 app need the versions in the advisory. Review the trusted authorities in your mutual TLS settings and your origin server certificates as well.

How Syntalith helps after the eMudhra key compromise

This problem rarely sits in one place. The certificate list lives in the operating system, in every image, in every Go, Java or Python runtime, and in devices nobody remembers. We can do the whole job for you.

First we find every place your services verify certificates: servers, images, CI, runtimes, HTTP libraries and devices. Then we upgrade ca-certificates, runtimes and libraries with their own list, rebuild images on fresh base images, restart services that hold the old list in memory and redeploy everything. We test each service through its own TLS path, with certificate verification switched on. You get a written report: what trusted the compromised certificates, what we fixed, and what needs your decision, such as devices without updates. We work on your infrastructure, with access only for the duration of the job.

We ran the same steps on our own systems. On 23 October we moved our website, booking system and MCP server to Node.js 24.22.1, which already carries the new certificate list.

Start with a free 30-minute call with an engineer. Tell us what your services run on, and we will tell you where to start. Book a call.

The same week also brought the Node2Shell flaw in Node.js and the PHP2Shell flaws in PHP.