eMudhra CA Compromise: A Private Key Was Just the Integer 4

One of a trusted certificate authority’s private keys was the integer 4. Not a 384-bit cryptographic secret — the number four. Security researcher Scott Helme recovered all eight of eMudhra’s compromised intermediate CA private keys in under one second, triggering emergency patches across Go, Python, Rust, Node.js, and every major browser. The keys had been sitting exposed since April 2025 — roughly 17 months — before anyone noticed.

How a Scripting Error Handed Out Root-Level Trust

eMudhra is an Indian certificate authority whose emSign infrastructure is trusted by Chrome, Firefox, Apple, and Microsoft root programs. During a key ceremony in April 2025, a faulty script generated two sets of P-384 private keys: one cryptographically strong, and one trivially weak — with values below 256. Staff selected the wrong set due to similar labeling, and those near-zero-entropy keys were published to browser root stores.

Helme described the severity directly: “Nobody had to steal anything. The key was effectively public from the day the certificate existed.” With the compromised keys, anyone could have forged trusted HTTPS certificates for any domain on the internet, or signed malicious code that Windows would accept without question. Six of the eight intermediates covered TLS issuance; two covered code signing.

What Stopped the eMudhra CA Compromise from Being Catastrophic

Certificate Transparency (CT) is the answer. CT is mandatory for Chrome and Firefox: any valid TLS certificate must be logged to public CT ledgers before a browser will trust it. No fraudulent certificates appeared in those logs during the 17-month exposure window, which means no confirmed man-in-the-middle attacks against browser users occurred.

However, the code-signing intermediates are a different story — CT does not cover code-signing certificates. Whether any malicious packages were signed with these keys during those 17 months remains unknown. Mozilla’s Dennis Jackson described the potential impact as “could not be higher” for devices lacking reliable revocation mechanisms. Browser makers moved fast once the disclosure landed: Chrome and Firefox blocked the certificates within hours on October 17. Apple followed on October 19, Microsoft on October 20.

The Gap: Your Dev Toolchain Is Not a Browser

Here is where it gets uncomfortable. Browsers use real-time revocation feeds — Chrome’s CRLSet, Firefox’s OneCRL — that push blocks without requiring a browser update. Your build pipeline does not have this.

Non-browser tools — curl, git, API clients, language runtimes, and container images — verify certificates against static CA bundles embedded at install or build time. They do not consult revocation feeds. Independent testing found that macOS’s built-in curl (version 8.7.1, SecureTransport) was still connecting to compromised test hosts even after Apple’s stated October 19 block, because /etc/ssl/cert.pem does not check revocation. Container images compound the problem further: a CA bundle is baked in at build time, meaning a host-level patch does nothing for already-running containers.

What to Patch Right Now

First, check whether your system is exposed. A TLS error indicates protection; a 200 response means you are still vulnerable:

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

Then patch by platform:

• Go: Upgrade to 1.27.3 or 1.26.10, then rebuild all binaries. Go embeds the trust store at compile time, so upgrading the toolchain alone does not fix already-deployed binaries. We covered the Go-specific fix in detail yesterday.
• Python: Run pip install --upgrade certifi to reach version 2026.10.18 or later. If you use uv, upgrade to 0.13.4.
• Rust: Update webpki-roots to 1.0.10 in your Cargo.toml and rebuild your project.
• Node.js: Upgrade to 26.12.1, 24.22.1, or 22.23.4 depending on your active release line.
• Linux: Run apt update && apt upgrade ca-certificates or the equivalent for your distribution.
• macOS curl: The built-in curl remains vulnerable. Use the Homebrew version (brew install curl) as a stopgap until Apple ships an updated /etc/ssl/cert.pem.
• Containers: Rebuild images from updated base images and redeploy. Host-level patches do not propagate into running containers.

Additionally, if your TLS certificate chains to emSign ECC Root CA – G3, replace it immediately from a different CA hierarchy. Chrome is removing the root from its trust store on October 27.

The Real Lesson from This Incident

Certificate Transparency saved the browser-facing web from 17 months of exploitable CA keys. That is a good outcome, and CT deserves the credit. Nevertheless, the developer ecosystem — build pipelines, language runtimes, container infrastructure — has no equivalent safety net. Each language runtime maintains its own CA bundle with its own independent patching cycle. Outside of browsers, revocation is effectively an afterthought.

This is not a new problem, but incidents like this make the cost concrete. If your services do any TLS verification outside a browser, your security posture depends on whether you are actively tracking a half-dozen independent trust store update schedules. Most teams are not. Start that inventory now.

Full technical details are available from Mozilla’s security team, Google’s security blog, and The Hacker News incident report. The eMudhra incident page includes test URLs to verify your client’s protection status.