eMudhra certificate compromise: what to update on servers, containers and language runtimes

On 17 October 2026 a researcher told the root programs that eight intermediate certificates from the eMudhra certificate authority had private keys that could be derived from the public certificates themselves. Whoever holds one of those keys can issue a valid certificate for any domain. Browsers blocked the certificates within hours; the remaining risk lies in software that is not a browser. This article explains the mechanism, gathers the timeline and orders what to update on servers, containers and programming environments.

An explanation for readers who do not run servers

When a program connects to a secure site (HTTPS), it checks that the site's certificate is signed by an authority it trusts. It is like checking an identity document by the issuer's seal. If an issuer's seal can be forged, anyone can manufacture identities that look legitimate.

That is what happened with eight intermediate "seals" from eMudhra. Chrome, Firefox, Safari and Edge already reject them. But many business systems, such as application integrations, scripts, containers, appliances and devices, use their own list of trusted authorities and do not learn about it on their own. Until that list is updated, someone with access to the network in between could impersonate a legitimate service and read or alter the data.

Mechanism of the compromise

According to Aikido's analysis, eMudhra generated the keys of the eight intermediates incorrectly: all of them are numbers below 256, whereas a proper key takes on the order of 10¹¹⁵ guesses to find. Six intermediates issue TLS certificates and two sign code. The certificates chain to the emSign ECC Root CA - G3 root and, through cross-certificates, to Sectigo's (Comodo) AAA Certificate Services root, according to Red Hat.

An attack needs three conditions at once: the system still trusts those intermediates, the attacker holds one of the keys, and the attacker can intercept the connection from a network position in between, such as hostile Wi-Fi or a compromised router. Clients that enforce Certificate Transparency (CT), the mandatory public log of certificates, were not attackable because the intermediates were not in CT before the block. The ctlogs.dev log documents that, after the block, more than one hundred thousand certificates issued with those keys appeared in CT, most of them naming well-known domains: the risk for clients without CT or revocation checks is concrete.

Timeline

Date (2026)	Event
17 October	Report to the root programs. Chrome (CRLSet) and Firefox (OneCRL) block the intermediates.
18 October	eMudhra revokes the eight intermediates.
19 October	Sectigo revokes the cross-certificates. Apple blocks the intermediates. Go releases 1.27.3 and 1.26.10.
20 October	Microsoft blocks the intermediates. Public disclosure. Mozilla removes the emSign ECC Root CA - G3 root (NSS 3.131.1).
21 October	Node.js and Oracle Java (CVE-2026-91403) release fixes. Red Hat publishes bulletin RHSB-2026-012.
27 October	Expected date for Chrome to remove the emSign ECC Root CA - G3 root from its store.

What to update, layer by layer

The practical rule is to identify where each program takes its list of trusted authorities from. There are three possible sources: the operating system, a file of the language runtime itself, or a file frozen inside an image or firmware.

• Operating system (Linux): update the ca-certificates package. Aikido cites as fixed, among others, Debian 12 20250419~deb12u2 and Alpine 20261020-r0; Red Hat will publish the RHEL versions in its bulletin. In the meantime, Red Hat explains how to disable the affected roots (article 7149312).
• Containers: rebuild with docker build --pull --no-cache on an updated base image and redeploy. A running container keeps the old list.
• Python: certifi ships its own list. Update it in every virtual environment with pip install --upgrade certifi; sources place the fix in the 18 and 19 October releases. requests and urllib3 depend on it.
• Go: update to 1.27.3 or 1.26.10 and rebuild the binaries, because the protection lives inside the compiled program (see the dedicated Go article).
• Java: CVE-2026-91403. Standalone JDK distributions use their own cacerts and need the fixed build or the official blocked.certs file (see the dedicated Java article).
• Node.js: 22.23.4, 24.22.1 and 26.12.1 update the built-in store. With --use-openssl-ca, Node.js uses the system store.
• Rust: sources report that webpki-roots 1.0.10 removes the root; confirm it in the crate's changelog.
• macOS command line: curl, git or python3 may use /etc/ssl/cert.pem, which does not update automatically.
• Devices and firmware: according to Aikido, equipment that ships authorities in firmware may stay vulnerable for years; ask the manufacturer.

Verification procedure

1. List the HTTPS clients that are not browsers: integrations, scheduled jobs, monitoring agents, CI runners and services that call APIs.
2. Check the ca-certificates version with dpkg -l ca-certificates, apk info -v ca-certificates or rpm -q ca-certificates.
3. In Python, run python -c "import certifi; print(certifi.__version__, certifi.where())" in each environment.
4. Test rejection with the test servers published by the incident site, emudhra.we-have-a-problem.com: a protected client must fail with a certificate error; an HTTP 200 response means it still trusts the intermediates.
5. Repeat the test from inside each container, not only from the host that runs it.

Frequently asked questions

If our site does not use eMudhra certificates, is there anything to do?

Yes. The risk is not in your own certificate but in your systems accepting forged certificates for other sites. It affects whoever connects, not whoever is visited.

Is there evidence of attacks?

Red Hat reports no active exploitation. However, the mass appearance of certificates in CT after the block shows that the keys are circulating, so waiting is not advisable.

Sources

• Red Hat, RHSB-2026-012.
• Aikido, eMudhra CA Compromise.
• ctlogs.dev, timeline and affected intermediates.
• Google, protecting Chrome and Android users.
• OpenJDK, advisory of 21 October 2026.

TLS client review

Xterra Engine inventories an organisation's HTTPS clients, identifies which trust store each one uses and documents the rejection test. To request the review or a quote, write to info@xterraengine.com or use the contact form.