eMudhra: trivial CA keys, revocations and trust stores to update
Eight eMudhra intermediate CAs had P-384 private keys below 256, letting anyone sign certificates. Revocations, patches and checks to run now.
After the hijacking of the .gh, .sl and .as ccTLDs, which let attackers obtain valid certificates for other people’s domains, trust in HTTPS is under pressure again, this time from inside a certificate authority. Eight intermediate CAs of India-based eMudhra had private keys so weak that they could be recovered from the public certificates in less than a second. With one of these keys, anyone can sign a certificate for any domain, accepted by every client that still trusts those CAs.
What happened
On 17 October 2026 at 20:06 UTC, Mozilla received, forwarded by the Chrome Root Program, a report from a researcher who signs as “Wayne”. According to Help Net Security, he found the issue while checking public data in the Common CA Database (CCADB) and, as proof, signed the message “We have a problem here – Wayne” with each key, sending it to Apple, Google, Microsoft, Mozilla and eMudhra. Mozilla independently recovered the keys at 21:48 UTC the same day, without knowing the researcher’s method.
The response, according to SecurityWeek and Help Net Security:
- 17 October: Firefox blocks the intermediates through OneCRL and Chrome blocks the six TLS intermediates through CRLSets, with no browser update or restart needed; Android devices and Chromebooks get an equivalent block via Google Play Services;
- 18 October: eMudhra revokes the eight certificates;
- 19 October: Apple ships protections; Cloudflare, informed that day, updates its services and clients and finds no exploitation;
- 20 October: Microsoft blocks the certificates; Mozilla releases Firefox 158.0.1 and ESR updates for configurations that had not received the block. Ars Technica reported, however, that on that day Edge on Windows 10 was still connecting to 12 vulnerable hosts.
Mozilla removed trust in the emSign ECC Root CA – G3 root that signs the intermediates; according to CSO Online, Google is removing it from the Chrome Root Store, effective on all devices from 27 October. eMudhra has stopped issuing under that root and estimates about 30,000 customer certificates need replacing (CSO Online quotes the same figure from Yash Kadakia of Security Brigade).
Technical details
According to Mozilla’s report as cited by the press, the eight intermediates come from a batch of 24 generated on 30 April 2025: six issue TLS certificates, two are for code signing. Help Net Security writes that Sectigo cross-signed all eight in May 2025; BleepingComputer only mentions “some”.
A P-384 ECC private key should be a random 384-bit number. eMudhra’s keys were all below 256: 4, 56, 66, 115, 155, 156, 230 and 237. Mozilla’s Dennis Jackson describes them as “effectively all-zeroes apart from the last byte”, recoverable almost instantly with the baby-step giant-step discrete log algorithm; simply trying the 256 possible values also works. Several people recovered them independently, and one was published on GitHub.
eMudhra’s explanation: in the key generation ceremony, using FIPS 140-2 Level 3 HSMs, a script error caused a wrap/unwrap step to produce a second set of weak keys alongside the correct ones. The weak keys had similar labels and were picked for the certificate signing requests. The company admits human errors at several steps; it says the intermediates were meant for its data centres in the United States and Europe, that only one went into production, that none issued end-entity certificates and that the root keys are not affected. It notes that roots and intermediates had passed independent audits for two years and will recheck every ceremony it has carried out.
Google states that Certificate Transparency (CT) logs show no TLS certificates chaining to the six intermediates before the block, so clients enforcing CT, such as Chrome in its default configuration, could not have been targeted. Not every client enforces CT, though, and anyone holding a key could sign certificates without going through eMudhra: it is unknown whether anyone did so in the previous 17 months. The sources do not detail the impact of the two code signing intermediates.
Exploiting a forged certificate requires an adversary-in-the-middle attack: according to Ars Technica this is within reach of well-resourced actors, but much easier for anyone controlling a local network.
MITRE ATT&CK (our classification): T1588.004 (Obtain Capabilities: Digital Certificates), T1557 (Adversary-in-the-Middle), T1553.002 (Subvert Trust Controls: Code Signing) for the code signing intermediates.
Impact for European and Italian companies
Browsers are protected; the rest is not. Applications with their own root list, servers, containers and devices that do not check revocation may still trust the intermediates until they are updated. Filippo Valsorda, speaking to Ars Technica, expects a “very, very long tail”: IoT devices, Docker containers, forgotten Linux machines, command-line tools shipping their own copy of the roots.
For NIS2 entities this is a concrete supply chain risk: trust depends on third parties they never chose directly. In healthcare and industry, equipment with long update cycles weighs heavily. Anyone with eMudhra certificates under the G3 root must replace them before the root is removed from the root stores.
What to do now
- Update root certificate packages. Status as of 20 October, from Jackson’s tracker as reported by BleepingComputer, among others: Ubuntu ca-certificates 20260816ubuntu0.*.1, Alpine 20261020-r0, Arch ca-certificates-mozilla 3.131.1-1, NSS 3.131.1, Python certifi 2026.10.19, pip 26.2.2, rustls-webpki 0.103.16, webpki-roots 1.0.10, Electron 44.9.1, 43.8.1 and 42.11.16, Composer ca-bundle 1.4.16 and 1.6.0; Go 1.27.3 and 1.26.10 (CVE-2026-111943, cited only by BleepingComputer). Debian, FreeBSD, Node.js and Bun were still pending.
- Rebuild images and containers with updated roots: an embedded copy does not update itself.
- Look for separate trust stores, as Kadakia suggests: payment gateways, vendor integrations, older Java applications, mobile apps, network appliances. On macOS, according to Jackson,
/usr/bin/curlmay keep trusting the intermediates because it does not check revocation. - Check that clients reject the compromised chains, cross-signed ones included, using the test endpoints on Jackson’s site.
- Replace eMudhra certificates issued under emSign ECC Root CA – G3 for your services.
- Monitor CT logs for your domains, as already advised for the ccTLD case.
How ARXDOME helps
ARX Expose shows your external attack surface every day, including the names and certificates of public services: it helps you find the ones to replace. On approved sites, ARX Watch’s active scan identifies the certificates of internal devices, including those without a probe.
Last updated:
