eMudhra CA Compromise: One Key Was 4, and Your Backend Probably Still Trusts It

Eight of eMudhra’s intermediate certificate authority private keys were so weak they could be cracked in under a second. One of them was literally the integer 4 — the scalar value 4 on a P-384 elliptic curve, where you normally need a 115-digit random number. Browsers moved decisively: Chrome, Firefox, Apple, and Microsoft all blocked the compromised certificates within three days of the October 17 discovery. If your users browse the web, they’re covered. If you run Go services, Node.js APIs, Python microservices, or Java applications, your backend is a different story entirely.

How Eight Keys Became Worthless

eMudhra, an Indian digital identity company whose emSign ECC Root CA – G3 sits in every major browser and OS trust store globally, had a defect in its key generation process. During a cryptographic wrap/unwrap step, the procedure collapsed the entropy of the resulting P-384 keys to somewhere between 3 and 8 bits — against the expected 384. The eight affected intermediate CA private keys were the integers 4, 56, 66, 115, 155, 156, 230, and 237. Not random strings. Single and double-digit numbers.

These intermediates were active from April 30, 2025 until October 17, 2026 — roughly 18 months. Anyone who thought to brute-force the small integer space could have recovered these keys and issued a certificate for any domain they wanted, or signed code Windows would trust. eMudhra says no intermediates were used to issue end-entity certificates, and Okta has found no evidence of active exploitation. That’s the good news. The bad news is in your dependency manifest.

Why “Browsers Fixed It” Is Not Your Fix

Chrome pushed a CRLSet update the day the vulnerability was reported. Mozilla shipped NSS 3.131.1, removing the root entirely. Apple and Microsoft followed within 72 hours. Today, Chrome finishes removing trust in the emSign ECC Root CA – G3 across all users. For connections made through a browser, this incident is closed.

But Go, Node.js, Python’s certifi, Rust’s webpki-roots, Java’s cacerts, Electron, and Bun all ship their own certificate bundles. They do not use the OS trust store. They do not automatically pick up browser or OS-level revocations. A Go binary compiled with Go 1.27.2 still validates against the compromised keys after you install Go 1.27.3 on the same machine — because the fix is compiled in, not loaded at runtime. You have to rebuild.

What to Patch, by Runtime

Here is the full list. If your stack includes any of these, act today:

• Go: Upgrade to 1.27.3 or 1.26.10 (CVE-2026-111943), then rebuild all binaries. Upgrading the toolchain without rebuilding does nothing.
• Node.js: Upgrade to 22.23.4, 24.22.1, or 26.12.1. Node.js 20 and below are end-of-life and will not receive a fix.
• Python: Run pip install --upgrade certifi — version 2026.10.19 or later removes the affected root.
• Rust: Update to rustls-webpki 0.103.16 and webpki-roots 1.0.10, then rebuild.
• Java: Update to a patched JDK vendor build (21.0.13.0.2, 17.0.21.0.2, 11.0.33.0.2, 8u511 b32, or newer). Java 20 and older receive no vendor fix; use keytool -delete to manually remove compromised entries from cacerts.
• Electron: Update to 44.9.1, 43.8.1, or 42.11.16.
• Bun: Update to 1.4.4 or later.

Quick Audit Checklist

Before you call this done, run through these:

• Check your own TLS endpoints: openssl s_client -connect yourdomain.com:443 -showcerts and look for emSign or eMudhra in the chain.
• Grep containers and Dockerfiles for emSign or eMudhra strings — if you pinned a CA bundle in an image, it needs a rebuild.
• For Java: keytool -list -keystore $JAVA_HOME/lib/security/cacerts | grep -i emsign on every JVM in your fleet.
• Python: pip show certifi — the version field must read 2026.10.19 or later.

The Bigger Lesson

The real takeaway is not that eMudhra made an embarrassing mistake — though one key being the number 4 will live in PKI infamy. The real lesson is that the modern software stack has too many independent trust stores, and most developers have no idea they own all of them. The browser handled its trust store. Your OS handled its trust store. But the Go binary you shipped in a scratch container, the Node.js service running on an EOL runtime, and the Python worker calling an external API through requests — all of those are yours to fix, and none of them were waiting on browser vendors to tell them what to do.

eMudhra has announced it is exiting the global SSL/TLS certificate market entirely. That is a decisive response. The rest of the fix is on you.