The eMudhra CA compromise: eight keys anyone could recover.

What happened

At 18:05 UTC on Saturday 17 October 2026, a researcher who signs as “Wayne” emailed Apple, Chrome, Microsoft, Mozilla and eMudhra with evidence that the private keys behind eight eMudhra intermediate CA certificates could be recovered. He later said he found them by running Google’s open-source paranoid_crypto checks across the public corpus of CA certificates.

Mozilla’s description of the flaw is stark: “P384 private keys are randomly selected integers between 1 and the group order. The 8 impacted keys all used integers less than 256. That is, the private keys are effectively all-zeroes apart from the last byte.” Mozilla recovered them independently within two hours of receiving the report. CERT-In adds the point that matters for anyone worried about elliptic-curve cryptography itself: the weakness “arose during key generation and does not indicate a vulnerability in the P-384 cryptographic algorithm itself.”

All eight came from a single key-generation ceremony on 30 April 2025. eMudhra’s preliminary explanation is that a key wrap/unwrap step “produced a second, weak set of keys alongside the original strong keys”, and that the weak set was used to create the certificate requests “because the key labels were similar”. eMudhra says it has “not yet confirmed the exact root cause”, and as of 23 October it had not answered the formal questions Mozilla sent on 20 October.

The certificates involved

How the industry responded

Removing the root is the step with collateral damage. Chrome’s analysis of Certificate Transparency logs found roughly 30,800 unexpired certificates chaining to emSign ECC Root CA - G3, 99.9% of them issued through two Internet2 / InCommon subordinate CAs serving US research and education. Those sites already fail in clients built on NSS 3.131.1 — Debian, Ubuntu, Red Hat, Python’s certifi, Node.js — and will fail in Chrome from 27 October unless they replace their certificates.

Where each platform stands

Java: CVE-2026-91403, and the update you had to apply twice

Oracle’s quarterly Critical Patch Update arrived on 20 October with 55 Java SE fixes, 49 of them remotely exploitable without authentication. The next day Oracle issued an out-of-band Security Alert, CVE-2026-91403 — CVSS 3.1 9.1 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N) in JSSE, Java’s TLS implementation — higher than anything in the scheduled update.

The awkward detail: the builds released on 20 October — 8u511, 11.0.33, 17.0.21, 21.0.13, 25.0.5 and 27.0.1 — are themselves listed as affected. Anyone who patched promptly on 20 October had to patch again on 21 October, to 8u511 b32 or the x.0.2 builds.

Oracle’s fix adds all sixteen certificates to lib/security/blocked.certs (blacklisted.certs on JDK 8) and leaves the root certificates in place. OpenJDK goes further, asking users of standalone runtimes to act “even if you have already updated”: delete the emsigneccrootcag3 [jdk] and comodoaaaca [jdk] entries from the bundled cacerts, or enable revocation checking. OS-packaged OpenJDK on Red Hat, Fedora and similar distributions uses the system trust store and is fixed by the ca-certificates update; on Debian and Ubuntu the Java keystore may need rebuilding.

One caution before deleting Sectigo’s AAA root everywhere: some certificate authorities still serve cross-certificates that chain up to it, so very old clients without the newer roots can fail on otherwise healthy sites. Test after the change, as the community tracker for this incident also warns.

India: what is and is not affected

eMudhra is one of India’s licensed certifying authorities, and the obvious first question for Indian organisations is whether Digital Signature Certificates and eSign are touched. They are not. CERT-In’s advisory is explicit: “The issuance of digital signature certificates and eSign services, regulated by the Controller of Certifying Authorities (CCA) under MeitY are not impacted.”

The reason is structural. The compromised intermediates sit under eMudhra’s globally trusted emSign roots and Sectigo’s AAA root — the web PKI that browsers use — not under the CCA’s Root Certifying Authority of India. The two hierarchies are separate, audited separately, and the incident is confined to the first.

What does affect Indian organisations is eMudhra’s decision, announced on 22 October, to withdraw from the global SSL/TLS business. eMudhra says its RSA (G1) roots will keep serving customers during the transition and that revocation services will run until every certificate has expired or been replaced, and it is offering Sectigo-issued certificates to customers. Chrome has said it is “closely investigating” eMudhra’s remaining roots. Any site on an emSign TLS certificate should plan a move now rather than on someone else’s deadline.

Who is still exposed

Google notes that because no certificate from the six TLS intermediates appeared in Certificate Transparency logs before the block, “no fraudulent certificates issued by these CAs could have been used against CT-enforcing clients” — which means browsers. Most other software does not enforce CT, and that is where the exposure lives:

• Servers and scripts using OpenSSL, curl or GnuTLS with a system trust store that has not been updated.
• Java runtimes older than the 21 October builds, and Debian or Ubuntu Java keystores that were never rebuilt.
• Python environments with certifi older than 2026.10.18, including pip vendored inside old virtual environments.
• Node.js below 22.23.4, 24.22.1 or 26.12.1 — and every end-of-life Node.js line, which gets no fix.
• Go programs built with a toolchain older than 1.26.10 or 1.27.3. Updating Go on the build machine changes nothing until each binary is rebuilt and redeployed.
• Electron desktop apps until each vendor ships an update built on a fixed Electron.
• Container images, appliances, IoT devices and firmware with a CA bundle baked in.
• Windows machines that do not receive automatic certificate-list updates — air-gapped or locked-down hosts — including for code signing, where Windows still trusts eMudhra’s code-signing root.

Was anyone attacked? CERT-In’s position on 21 October was that public disclosures “do not establish confirmed malicious exploitation of the affected keys.” For clients that do not enforce Certificate Transparency, misuse between April 2025 and October 2026 can be neither confirmed nor ruled out — which is the reason to treat the clean-up as urgent rather than theoretical. A community test site referenced by Mozilla recorded tens of thousands of successful connections in a few hours from clients that still trust the compromised intermediates — monitoring agents, curl, Python and pip among the most common.

How to check your own systems

Does this machine still trust the compromised chain?

A note on that Node.js check: the simpler /emSign/.test(pem) form that has circulated always returns zero, because it searches the base64 text of the certificate rather than its decoded subject. Patched Node.js releases block the eight keys regardless of what the root list says.

Is your website’s certificate affected?

Since the compromised intermediates issued no customer certificates, the realistic finding for a site owner is not a compromised certificate but one that chains to emSign ECC Root CA - G3 — the root being removed. Google’s instruction to those operators is that they “must immediately acquire and install a new TLS certificate from another PKI hierarchy included in the Chrome Root Store”. ACME clients will not renew on their own outside the renewal window, so force the renewal.

Code signing

eMudhra says its two code-signing CAs never issued a certificate, so a signature chaining to EM OV CS CA - G3B or G3C would be anomalous and worth escalating. On Windows, signtool verify /pa /v /all prints the full signing chain; on Linux, osslsigncode verify does the same; for Java archives, jarsigner -verify -verbose -certs -strict — and Oracle notes that strict verification now fails for anything signed through these chains.

What to do

How SemperWise helps