The eMudhra intermediate CA compromise left eight certificate authority private keys so weak that anyone could recover them from the public certificates. Browsers blocked the intermediates within days of the 17 October report. Many of the command-line tools, language runtimes and container images that run your CI and production traffic did not, and some still trust them.
If you run software that ships its own CA bundle, such as Python with certifi, Node.js, Go, Java, curl or Rust tools, it may accept certificates forged with these keys until you update it and rebuild. Your browser is fine. Your build agents and container images need checking.
What happened at eMudhra?
According to BleepingComputer, all eight intermediates used P-384 private keys whose values were below 256. Recovering one means trying at most 256 numbers. One published key, for EM OV TLS CA - G3C, was simply 4.
Six of the intermediates could issue TLS certificates and two were for code signing. eMudhra blamed a bug in a key generation script that produced a second, weak set of keys, which were then picked for signing because their labels looked like the real ones.
The keys date from April 2025. That means they were recoverable for roughly 17 months. eMudhra said most of the intermediates were never used in production, and no matching certificates appeared in Certificate Transparency logs before the block.
How fast did browsers and platforms react?
Mozilla blocked the certificates in Firefox through OneCRL on 17 October, and Chrome blocked the six TLS intermediates the same day. Apple followed on 19 October and Microsoft on 20 October.
Mozilla also announced an emergency removal of the emSign ECC Root CA - G3 on 20 October, and Chrome scheduled its removal of that root for 27 October. Go assigned CVE-2026-111943 and fixed it in Go 1.27.3 and 1.26.10.
That is a quick response by any standard. It just does not reach everything.
Why do CI tools and containers still trust the forged certificates?
Browsers get block lists pushed to them. Most other software checks certificates against a bundle file that was frozen when the package or image was built, and many of these clients do not enforce Certificate Transparency or check revocation at all.
An independent researcher who tested clients on macOS on 21 October found that the built-in /usr/bin/curl 8.7.1 and Node.js 25.3.0 fetch both accepted a test endpoint signed through the compromised chain. Python with certifi 2026.7.22 accepted it through the eMudhra root, and uv 0.13.3 passed TLS verification. Go rejected it, and so did Python once certifi was updated.
There is a second path too. Sectigo cross-signed the same eight keys under its AAA Certificate Services root, which Apple and Microsoft still trust. On AWS Lambda, the Python 3.13 image's botocore 1.42.97 still trusted that cross-signed path, and the java:21 image from 22 October trusted both roots, according to a tracking advisory.
Which versions remove the trust?
Go 1.27.3 and 1.26.10, which reject the keys regardless of the system bundle
Python certifi 2026.10.19, pip 26.2.2, uv 0.13.4 and botocore 1.43.117
Node.js 22.23.4, 24.22.1 and 26.12.1
rustls-webpki 0.103.16 and webpki-roots 1.0.10
The curl CA bundle dated 2026-10-20, plus ca-certificates updates for Ubuntu, Debian, Alpine and Arch
As of 22 October, Amazon Linux 2023 and 2, Red Hat UBI, Bottlerocket, Amazon Corretto and Bun had no fix listed.
How do you inventory CA bundles in your images?
Start with the base images, because one update there covers a lot of services. Then look for the bundles that applications bring themselves. Inside a running container or an exported image filesystem, search for files such as cacert.pem, ca-bundle.crt and ca-certificates.crt, and check the versions of certifi, botocore and any Node.js or Go toolchain used at build time.
For Go services, the fix lives in the compiler's standard library, so the binary only picks it up when it is rebuilt with a fixed Go version. Same for single-file Node.js builds. Updating the base image alone does not touch them.
Then test from inside the workload, not from your laptop. The checker Mozilla's Dennis Jackson published at emudhra.we-have-a-problem.com gives you endpoints to hit. If a request succeeds, that container still trusts the bad chain.
Do not "fix" failing builds by turning verification off. That removes the protection these updates add back. Lockfiles and hash pinning, such as go.sum or pip's --require-hashes, still catch tampered packages, but only when the expected hash is already recorded.
Any certificate you hold that chains to emSign ECC Root CA - G3 should be reissued, preferably under a different CA, before Chrome drops the root on 27 October.
The browsers moved in hours. The long tail will take months, and it lives in images nobody has rebuilt since the summer.
Quick answers
Are browsers safe from the eMudhra intermediate CA compromise?
Yes, if they are up to date. Firefox and Chrome blocked the eight intermediates on 17 October 2026, Apple followed on 19 October and Microsoft on 20 October.
Which tools need updating after the eMudhra key compromise?
Anything with its own CA bundle: Go (1.27.3 or 1.26.10), Python certifi (2026.10.19), Node.js (22.23.4, 24.22.1, 26.12.1), rustls-webpki (0.103.16), webpki-roots (1.0.10), uv (0.13.4), botocore (1.43.117) and your distro's ca-certificates package.
Do I need to rebuild container images for the eMudhra issue?
Yes. CA bundles are copied into images at build time and Go binaries carry the fix only when rebuilt, so update base images and dependencies, rebuild and redeploy.
