eMudhra CA Compromise: When an Intermediate Private Key Was the Number 4

What happened

eMudhra is a Bangalore-based public CA whose emSign ECC Root CA - G3 is in the Mozilla, Microsoft, Apple and Google root programs — which means every mainstream browser and most operating systems trust it to issue TLS certificates for any domain on the internet. In April 2025 eMudhra issued eight intermediate CA certificates under that root. The intermediates themselves were never logged to Certificate Transparency, which is already a red flag, but the real failure sat one level deeper: the private keys for all eight certificates were generated with so little entropy that the keys could be recovered by trial and error from the public key alone. One of the eight private keys turned out to be the small integer 4.

The root cause: a key-generation routine that produced one byte of entropy

A healthy 256-bit ECC private key is a uniformly random integer somewhere in the ~10¹¹⁵-wide keyspace. The eMudhra keys landed in a space of at most 256. The two leading theories, both consistent with the recovered values:

• A type-casting bug that generated a cryptographically random big-integer and then truncated it to a byte somewhere between the random source and the keypair constructor.
• A Go decimal-conversion footgun from a deprecated API that silently coerced large integers through a narrower representation during serialisation.

Either way, the published cert gave anyone with a laptop everything they needed to reconstruct the signing key, mint a certificate for google.com or login.microsoftonline.com, and present it to any client that still trusts the chain.

What an attacker could actually do with this

An adversary with a network position — a hostile Wi-Fi hotspot, a compromised router, a nation-state-grade tap — could forge TLS certificates for any domain and intercept traffic to clients that still accept the eMudhra chain. The code-signing intermediates widen the blast radius further: a signed Windows binary from one of those keys would have validated against the Microsoft trust store until the OS received the revocation update. There is no public evidence the keys were abused in the wild, but once a private key is recoverable from a public artefact the question is reach, not possibility.

Who is already protected — and who is still exposed

Timeline

The CA-bundle versions to ship

Browsers can revoke by push. Everything else needs a new ca-certificates package or an application-level trust-store bump. The fixed packages at time of writing:

Runtimes that bundle roots independently of the OS (certifi, webpki-roots, Java cacerts, Node.js) also need their own refresh — pin to the first release after 20 October 2026 and rebuild downstream images.

Verifying your fleet

The incident site publishes test hosts whose chain terminates in a revoked eMudhra intermediate. A healthy host should fail TLS validation:

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/

Expected output on a patched host: HTTP 000 (SSL verification failure). Any 2xx/3xx response means that host still trusts the compromised intermediate.

What to do in the next 72 hours

1. Patch OS trust stores. Run apt upgrade ca-certificates, apk upgrade ca-certificates, or dnf upgrade ca-certificates across Linux fleets. Reboot or restart long-lived services that cache the bundle in memory.
2. Rebuild container images. docker build --pull --no-cache all images that FROM a Linux base, including :latest images in internal registries and CI runner images. Mirror updated base images to your private registry.
3. Refresh language-runtime roots. Bump certifi in Python requirements, upgrade Java cacerts via your JDK vendor's October 2026 bundle, pin webpki-roots >= the first post-20 Oct 2026 release in Rust projects, and rebuild Go and Node services against the latest point release.
4. Audit code-signing paths. Microsoft Authenticode validation on Windows machines without the 20 Oct 2026 update will still accept binaries signed by the two code-signing intermediates. Push the update through WSUS / Intune and search EDR logs for unexpected signed-binary executions since April 2025.
5. Verify with the curl probes above. Run them from a representative node per environment (prod, staging, CI, a container built from each base image you ship) and capture the output as evidence for your next audit.

How TigerGate helps

• Container Security flags images whose ca-certificates package predates the fixed version and surfaces the first service running each affected image, so you rebuild in reachability order rather than alphabetically.
• SCA and SBOM finds projects pinned to pre-fix certifi, webpki-roots, Java cacerts and Node bundled-root versions across every repo and lockfile.
• Server Vulnerability Monitoring fingerprints the installed ca-certificates version on every Linux host and cloud VM — including CI runners and bastion hosts — so the known-stale machines rise to the top of the queue.
• eBPF runtime detection flags TLS handshakes that complete against the compromised chain on hosts you thought were patched — the fastest way to catch an unexpected pre-baked trust store in a legacy image.
• Compliance evidence maps the trust-store refresh to SOC 2 CC7.1 vulnerability lifecycle, PCI DSS 4.0 requirement 2.2.5 (cryptographic trust management), and ISO 27001 A.8.24 — the audit trail your next auditor will ask for.

Sources

• CCADB and root-program bulletins from Mozilla, Microsoft, Apple and Google, 17–20 October 2026