eMudhra CA Key Compromise: Weak Keys, Risks and Fixes
The eMudhra CA key compromise is a certificate authority (CA) security incident in which eight intermediate certificates issued by eMudhra, an Indian digital trust provider, carried private keys that anyone can recover from the public certificate. An independent researcher reported the weakness on October 17, 2026, and Chrome and Firefox blocked the intermediates within hours.
The keys were P-384 elliptic-curve values below 256, generated during an April 30, 2025 key ceremony. Six of the intermediates issue Transport Layer Security (TLS) certificates and two sign code. Browsers are now protected, but software that relies on its own CA bundle and skips revocation checks may keep trusting the compromised chain. This FAQ covers what happened, who is exposed and which updates close the gap.
Key Takeaways
- Eight keys, trivially recoverable: Eight eMudhra intermediate CA certificates from an April 30, 2025 key ceremony used P-384 private keys below 256. One key was the number 4.
- Six TLS CAs, two code-signing CAs: The TLS keys let anyone issue certificates that clients would trust for any domain; the code-signing keys could lend malware a verified-publisher signature on Windows systems that skip revocation checks.
- Browsers are covered: Chrome, Mozilla, Apple and Microsoft blocked the compromised certificates between October 17 and 20, 2026. Mozilla has also removed the emSign ECC Root CA – G3 root, and Chrome’s removal reaches all devices by October 27, 2026.
- Non-browser clients are the gap: API clients, containers, build pipelines and embedded devices that skip revocation and Certificate Transparency checks stay exposed until their trust stores are updated.
- No confirmed abuse: As of October 21, 2026, no malicious use has been confirmed, but the keys were recoverable for about 17 months.
eMudhra CA Key Compromise at a Glance
| Attribute | Details |
|---|---|
| CVE ID | None for the CA incident itself; downstream fixes tracked as CVE-2026-111943 (Go crypto/x509) and CVE-2026-113470 (Firefox OneCRL block list) |
| CVSS | Not scored for the CA incident; no NVD score for either downstream CVE as of October 21, 2026; Mozilla rates CVE-2026-113470 High impact, and CISA’s ADP entry scores it 5.4 CVSS v3.1 |
| Affected Products | Eight eMudhra intermediate CAs (six TLS, two code signing) and their Sectigo cross-signed copies; any client that trusts eMudhra’s G3 roots or Sectigo’s AAA Certificate Services without revocation or CT checks |
| Affected Versions | G3B and G3C intermediates generated on April 30, 2025 with P-384 keys; client side, trust stores and toolchains released before the October 17-20, 2026 updates |
| Fixed In | Firefox 158.0.1, ESR 153.5.1 and ESR 115.43.1; NSS 3.131.1; Go 1.27.3 and 1.26.10; Python certifi 2026.10.19; updated Linux ca-certificates packages |
| Exploitation Status | No confirmed malicious use as of October 21, 2026; keys recovered independently by multiple researchers |
| Patch Available | Yes for browsers and most trust stores; Bun and FreeBSD pending as of October 21, 2026; Node.js fixed in 22.23.4, 24.22.1 and 26.12.1 |
| Discovered By | Independent researcher “Wayne”, reported October 17, 2026 |
1. What Is the eMudhra CA Key Compromise?
The eMudhra CA key compromise is the exposure of private keys for eight eMudhra intermediate CA certificates, reported on October 17, 2026. Each key was a P-384 value below 256, so anyone holding the public certificate could recover it in under a second and sign certificates that clients trusting eMudhra’s G3 hierarchy would accept.
2. Which eMudhra Certificates Are Affected?
Eight intermediates from eMudhra’s April 30, 2025 key ceremony are affected: six TLS issuing CAs covering Domain Validation (DV), Organization Validation (OV) and Extended Validation (EV) in G3B and G3C variants, plus two code-signing CAs. Sectigo had cross-signed all eight under its AAA Certificate Services root, so each key also appears in a Sectigo-issued certificate.
| Intermediate | Purpose | Subject Organization | Private Key Value |
|---|---|---|---|
| EM DV TLS CA – G3B | TLS (DV) | eMudhra BV | 156 |
| EM OV TLS CA – G3B | TLS (OV) | eMudhra BV | 155 |
| EM EV TLS CA – G3B | TLS (EV) | eMudhra BV | 115 |
| EM DV TLS CA – G3C | TLS (DV) | eMudhra Inc | 230 |
| EM OV TLS CA – G3C | TLS (OV) | eMudhra Inc | 4 |
| EM EV TLS CA – G3C | TLS (EV) | eMudhra Inc | 56 |
| EM OV CS CA – G3B | Code signing | eMudhra BV | 66 |
| EM OV CS CA – G3C | Code signing | eMudhra Inc | 237 |
3. How Weak Were the eMudhra Private Keys?
Every affected private key was an integer below 256, roughly eight bits of strength instead of the 384 random bits a P-384 key should carry. The key for EM OV TLS CA – G3C was simply the number 4. Recovering any of the eight requires testing at most 256 candidate values against the public key, a task a laptop finishes in milliseconds.
The certificates themselves look structurally normal, so inspecting their contents does not reveal the flaw. Only testing the private key against the public key does.
4. How Did Weak Keys End Up in Trusted eMudhra Certificates?
eMudhra’s preliminary explanation blames a flaw in its key-generation ceremony script, which created a second, weak key pair on the hardware security module (HSM). Similar key labels caused that weak pair to be used for the certificate signing requests, and eMudhra cites human errors at multiple steps. eMudhra says it will re-verify every key ceremony it has performed, and its investigation was ongoing as of October 21, 2026.
An earlier warning sign was misdiagnosed. In June 2025, Mozilla bug 1970728 recorded invalid certificate revocation list (CRL) signatures from the same six TLS intermediates, and Mozilla now notes those failures date back to at least May 23, 2025. At the time, eMudhra blamed a manual process that referenced the wrong CA key, published corrected CRLs on June 6, 2025, and the bug was closed. Its 2026 account ties those invalid CRLs to the same key mismatch, which only became clear once the weak keys surfaced.
5. Who Discovered the eMudhra Weak Keys?
An independent researcher who signs as “Wayne” found the weakness on October 17, 2026, while testing public certificate data, and reported it the same day to Apple, Google, Microsoft, Mozilla and eMudhra. As proof, they signed the message “We have a problem here” with each of the eight private keys. Mozilla credits Wayne as the reporter of CVE-2026-113470.
Mozilla cryptography engineer Dennis Jackson later published a public disclosure site that tracks affected software and patch status.
6. How Long Were the eMudhra Keys Exposed?
The weak keys existed from the April 30, 2025 key ceremony until browsers began blocking them on October 17, 2026, an exposure window of about 17 months. Anyone who inspected the certificates during that period could have recovered the keys, and no technical record can show whether someone did so outside Certificate Transparency (CT) logs.
| Date | Event |
|---|---|
| April 30, 2025 | Key ceremony generates the eight intermediates with weak P-384 keys |
| May 14, 2025 | Sectigo cross-signs the intermediates under AAA Certificate Services |
| May 23, 2025 | Earliest archived evidence of invalid CRL signatures from the six TLS intermediates |
| October 17, 2026, 18:05 UTC | Chrome Root Program receives Wayne’s report (Mozilla logs it at 20:06 UTC) |
| October 17, 2026, 19:45 UTC | Chrome ships a CRLSet update blocking the intermediates’ keys |
| October 17, 2026, 22:59 UTC | Mozilla’s OneCRL block reaches standard Firefox installs |
| October 18, 2026 | eMudhra revokes all eight intermediates as CA compromise |
| October 19, 2026 | Apple blocks the certificates; Sectigo revokes its cross-signed copies; Android update ships via Google Play Services |
| October 20, 2026 | Microsoft blocks the certificates; Go 1.27.3 and 1.26.10, Firefox 158.0.1 and NSS 3.131.1 ship; Mozilla removes trust in emSign ECC Root CA – G3 |
| October 27, 2026 | Chrome’s removal of emSign ECC Root CA – G3 expected to reach all devices |
7. Why Is a Compromised Intermediate CA Key Dangerous?
Anyone holding an intermediate CA private key can sign new certificates that chain to a trusted root. With the six TLS keys, an attacker on the network path could issue a valid-looking certificate for any domain and intercept HTTPS traffic from clients that trust the chain. The two code-signing keys could make malware appear to come from a legitimate publisher on systems that skip revocation checks.
8. Has the eMudhra Key Compromise Been Exploited?
As of October 21, 2026, no malicious use of the eMudhra keys has been confirmed. Google reports that no TLS certificate chaining to the affected intermediates was logged to CT before the block, which rules out attacks against CT-enforcing clients. Clients that skip CT checks have no equivalent evidence, so past misuse against them cannot be ruled out.
Since disclosure, several people have recovered the keys independently, and all eight key values are now public. Treat all eight keys as known to attackers.
9. Are Chrome, Firefox and Safari Users Protected?
Yes, users of current major browsers are protected. Chrome blocked the six TLS intermediates through a CRLSet update on October 17, 2026, and Firefox followed through OneCRL the same day, with no restart required. Apple added platform-level protections on October 19. Chrome, Firefox and Safari also enforce CT, and Google has worked to ensure CT logs reject certificates chaining to the compromised CAs.
Firefox users who disabled remote settings updates by policy receive the block through Firefox 158.0.1, ESR 153.5.1 or ESR 115.43.1. Android devices received an equivalent update through Google Play Services around 22:00 UTC on October 19.
10. Which Systems Are Still at Risk From the eMudhra Certificates?
Non-browser TLS clients carry most of the remaining risk. API clients, backend services, containers, continuous integration and delivery (CI/CD) pipelines and Internet of Things (IoT) devices often trust a bundled CA store, skip revocation checks and ignore CT. In Scott Helme’stests, curl, Python and Node.js on Linux and macOS accepted a forged certificate issued under EM DV TLS CA – G3B.
High-value paths include curl-piped installers and self-updaters, build systems holding cloud and signing credentials, and server-to-server API calls that carry secrets. The disclosure site also flags the built-in /usr/bin/curl on macOS, which reads an unupdated /etc/ssl/cert.pem bundle and does not check revocation.
11. Does the eMudhra Incident Affect Windows Code Signing?
Yes, two of the eight intermediates, EM OV CS CA – G3B and EM OV CS CA – G3C, are code-signing CAs issued under emSign Root CS CA – G3, a root trusted by Microsoft. A holder of those keys could sign executables that Windows systems skipping revocation checks would attribute to a seemingly verified publisher. eMudhra says only one of the eight, EM DV TLS CA – G3C, ever entered production, so neither code-signing CA was used.
As of October 21, 2026, Microsoft has published no advisory on the incident. The eMudhra disclosure site reports that Microsoft platforms have blocked the compromised certificates since October 20, 2026, but no source confirms whether that block covers Authenticode code signing as well as TLS. Code-signing certificates are not logged to CT, so no public record shows what, if anything, the two CAs signed.
12. Is There a CVE for the eMudhra Certificate Compromise?
No CVE covers the CA incident itself, because the flaw sits in eMudhra’s key ceremony rather than in a software product. Downstream fixes carry their own IDs: CVE-2026-111943 tracks the Go crypto/x509 block, and CVE-2026-113470 tracks the Firefox OneCRL block list update, which Mozilla rates High impact in advisory MFSA 2026-111.
13. What Have Browsers and Root Programs Done About eMudhra?
Root programs went beyond blocking the intermediates and moved to distrust the root above them. Mozilla removed emSign ECC Root CA – G3 in NSS 3.131.1 on October 20, 2026. Chrome is removing the same root from the Chrome Root Store, with the change expected on all devices by October 27, 2026, and is reviewing eMudhra’s remaining CA certificates.
eMudhra revoked all eight intermediates on October 18, 2026, and stopped issuing under G3 after Mozilla’s root removal decision. Sectigo also revoked its cross-signed copies. Mozilla is not removing trust in emSign Root CA – G1 at this time.
14. Which Software Updates Fix the eMudhra Trust Issue?
Most major operating systems, language runtimes and package managers have shipped updated trust stores. As of October 21, 2026, fixes for Bun and FreeBSD were still pending. Go programs only gain the block after being rebuilt with a patched toolchain, so existing binaries keep the old behavior.
| Software | Fixed Version | Notes |
|---|---|---|
| Firefox | 158.0.1, ESR 153.5.1, ESR 115.43.1 | Needed only where OneCRL updates are blocked; Thunderbird 158.0.1 and 153.5.1 carry the same fix |
| NSS | 3.131.1 | Removes emSign ECC Root CA – G3 |
| Go | 1.27.3, 1.26.10 | CVE-2026-111943; rebuild binaries |
| Node.js | 22.23.4, 24.22.1, 26.12.1 | One release per supported line |
| Python certifi | 2026.10.19 | Also update pip 26.2.2 and uv 0.13.4 |
| Rust rustls-webpki / webpki-roots | 0.103.16 / 1.0.10 | |
| Electron | 44.9.1, 43.8.1, 42.11.16 | Rebuild Electron apps |
| curl CA bundle | October 20, 2026 extract | |
| Ubuntu ca-certificates | 20260816ubuntu0.22.04.1 through 20260816ubuntu0.26.10.1 | Per supported release |
| Debian ca-certificates | 20250419~deb12u2, 20250419+deb13u1 | |
| Alpine ca-certificates | 20261020-r0 | Rebuild container images |
| Bun, FreeBSD ca_root_nss | Pending | As of October 21, 2026 |
15. How Can Teams Test If a Client Trusts the Compromised eMudhra CAs?
The public disclosure site runs 12 test hosts (two are shown below) that serve certificate chains through the compromised intermediates. A certificate error from the client in question means it rejects those intermediates, while a successful connection means it still trusts them and needs an update.
curl https://dv-g3b-emudhra.we-have-a-problem.com/
curl https://dv-g3b-aaa-emudhra.we-have-a-problem.com/16. What Should Website Owners Using eMudhra Certificates Do?
Website operators with certificates chaining to emSign ECC Root CA – G3 should replace them with certificates from a hierarchy browsers still trust, since Chrome warns that G3-chained sites will break once its root removal lands. eMudhra says about 30,000 certificates need migration to emSign Root CA – G1 intermediates; roughly 97% were originally issued via Automatic Certificate Management Environment (ACME).
17. What If a Device Cannot Receive a Trust Store Update?
Devices with frozen trust stores need the compromised intermediates blocked by hand. Removing emSign ECC Root CA – G3 alone is not enough: Sectigo’s cross-signs chain the same keys to AAA Certificate Services, and Windows trusts the emSign Root TLS CA – G3 and Root CS CA – G3 issuers directly. Add the eight intermediates to a distrust list, enable revocation checking, and restrict the device’s outbound TLS to known endpoints.
The disclosure site documents manual distrust steps for macOS curl, major Linux distributions, NetBSD and FreeBSD. Removing AAA Certificate Services outright can break legitimate connections, so test before applying that workaround broadly.
Mitigation and Recommendations
Browser coverage is in place, so the remaining work sits in servers, build systems and devices that manage their own trust.
- Update every trust store: Apply operating system ca-certificates updates and update language-level bundles such as certifi, pip, uv, webpki-roots and Electron. Rebuild container images from patched base images rather than relying on running containers.
- Rebuild Go binaries: Recompile Go services and tools with Go 1.27.3 or 1.26.10, since deployed binaries keep the old trust behavior until rebuilt.
- Test critical clients: Run the disclosure site’s test hosts from API clients, CI/CD runners, proxies and appliances, and treat any successful connection as an open finding.
- Inventory eMudhra G3 certificates: Find internal and external services that present certificates chaining to emSign ECC Root CA – G3 and replace them before Chrome’s root removal reaches all devices on October 27, 2026.
- Hunt for misuse since April 30, 2025: Review TLS inspection, proxy and endpoint logs for certificates or signed binaries chaining to the eight intermediates, with particular attention to code-signing activity on Windows.
- Contain frozen devices: Distrust the eight intermediates where possible, segment devices that cannot be updated, and limit their outbound connections to known destinations.
- Enable revocation checking where supported: Windows applications using CryptoAPI and other clients with optional revocation checks gain an extra layer while trust store updates roll out.
How SOCRadar Can Help
SOCRadar can help teams find where eMudhra’s G3 hierarchy still touches their environment and follow the incident as trust stores change:
- Attack Surface Management: Discovers internet-facing domains, subdomains and IP addresses and monitors the SSL/TLS certificates they serve, so teams can flag services presenting chains through emSign ECC Root CA – G3 or the eight revoked intermediates and replace them before Chrome’s root removal reaches all devices on October 27, 2026.
- Cyber Threat Intelligence: Tracks CVE-2026-111943, CVE-2026-113470 and related trust store updates through vulnerability intelligence, and surfaces Dark Web and threat actor discussion of forged certificates or binaries signed with the compromised keys.
Pairing external certificate visibility with incident intelligence helps teams close the non-browser gap that browser blocks leave open.
