eMudhra CA Compromise: Chrome Drops emSign ECC Root CA - G3 October 27

TL;DR

• A researcher who goes by Wayne showed on October 17, 2026 that anyone can compute the private keys of eight eMudhra intermediate CA certificates from the public certificates, signing a message with each recovered key as proof. eMudhra blames a flawed key-wrap step in its April 30, 2025 key ceremony. All eight values are whole numbers below 256; Scott Helme recovered them on his laptop in under a second.
• Anyone holding an intermediate CA key can issue a valid certificate for any domain, which means undetectable website and service impersonation for clients that trust it. Chrome (CRLSets) and Firefox (OneCRL) blocked the intermediates on October 17, Apple from October 19, per its advisory, and Microsoft on October 20. No certificate from the six TLS intermediates was ever logged to Certificate Transparency, so none reached a CT-enforcing browser.
• The exposure is every client that does not enforce CT and does not consume revocation: curl and other command-line tools, language runtimes and applications that ship their own CA bundles, Electron applications such as Slack and Discord built on unpatched Electron releases, and IoT and embedded devices. Go, Node.js, Python, certifi, Electron, the major distributions and many vendors have shipped updates or key denylists.
• If you operate a website whose certificate chains to emSign ECC Root CA - G3, Chrome removes that root in Root Store version 43, reaching devices on the morning of October 27 Pacific time. Google's instruction is to acquire and install a certificate from another hierarchy immediately. About 30,800 unexpired certificates chain to the root, 99.9 percent of them issued through InCommon.

Am I affected?

Two groups are affected: clients that still trust emSign ECC Root CA - G3 or the compromised intermediates without CT and revocation checks, and site operators whose certificates chain to that root. Check both.

Certificate Transparency (CT) is the system of public, append-only logs that record issued TLS certificates. A CT-enforcing browser trusts a certificate only if it carries proof that the certificate was logged.

As a client (can someone intercept my connections?), you are affected if all of these hold:

• The software verifies TLS against a system or bundled trust store that still contains emSign ECC Root CA - G3 or accepts the compromised intermediates.
• It does not enforce Certificate Transparency, which rules out browsers (Chrome, Edge, Firefox, Safari) but not curl, most language runtimes, most Electron apps and most embedded clients.
• It does not consume the pushed revocation blocks (OneCRL, CRLite, CRLSets) that already protect the browsers.

Test the client directly with the checker hosts published by the incident site. A certificate error means the client is protected. A successful connection means it still trusts the compromised intermediates, and success on the "noct" hosts also means it does not enforce CT.

curl itself never checks Certificate Transparency, so it succeeds on the "noct" hosts whenever it trusts the chain. To test CT enforcement, connect to them from the client you want to check:

curl https://dv-g3b-emudhra.we-have-a-problem.com/
curl https://dv-g3b-aaa-emudhra.we-have-a-problem.com/
curl https://dv-g3b-noct-emudhra.we-have-a-problem.com/        # chain without SCTs; curl does not check CT
curl https://dv-g3b-aaa-noct-emudhra.we-have-a-problem.com/

As a server operator (will my site break?), you are affected if any certificate you serve chains to emSign ECC Root CA - G3. About 30,800 unexpired certificates did, as of October 21, per Chrome's count of CT logs. 99.9 percent were issued through InCommon, the certificate service Internet2 runs for higher education. InCommon moved onto eMudhra's CertiNext platform between April and July 2026.

Two of these CVEs carry a CVSS score from the organization that assigned them: CVE-2026-115557 is 9.4 Critical (CVSS 4.0, Python Software Foundation) and CVE-2026-114820 is 9.1 Critical (CVSS 3.1, Oracle). Go's CVE-2026-111943 record has no score. Mozilla gave CVE-2026-113470 (Firefox) no score either; CISA's enrichment of the record rates it 5.4 Medium (CVSS 3.1).

The incident site tracks dozens more, including Bun 1.4.4, Deno 2.9.8, Docker Desktop 4.96.2, Git for Windows 2.56.0.3, VS Code 1.143.1, GitHub CLI 2.102.1, conda 26.9.4, pip 26.2.2 and mitmproxy 12.3, with LibreOffice, Godot, certbot and containerd pending as of October 27.

Tools that bundle their own Node inherit the fix only when they move to a patched runtime. mongosh below 2.14.0 verifies against the host Node runtime's trust store, while 2.14.0, released October 23, 2026, bundles Node 24.22.1, which carries the key blocklist.

How do I fix it?

Patch every browser and non-browser client, then replace any certificate that chains to emSign ECC Root CA - G3 before October 27. As a client operator, update in this order:

1. Browsers and operating systems update themselves; confirm they are current, since the blocks arrived through Chrome's CRLSets (October 17), Firefox's OneCRL (October 17), Android's Google Play services (October 19), Apple's automatic trust-list updates (from October 19, per its advisory) and Microsoft's automatic trust-list updates (October 20).

2. Patch every non-browser client from the table:

   • Go: rebuild binaries on 1.27.3 or 1.26.10.
   • Node.js: update runtimes and any applications that bundle one.
   • Python: update to 3.15.2, 3.14.10, 3.13.18, 3.12.16 or 3.11.18, the first releases whose ssl module carries the CVE-2026-115557 denylist, or pin certifi 2026.10.19 or later.
   • Java: update to the Azul out-of-cycle builds or another JDK that blocks the keys.
   • Electron: rebuild apps on 42.11.16 or newer.

   Warning: the October 21 Python releases 3.15.1, 3.14.9 and 3.13.17 do not carry the denylist. They bundle pip 26.2.2 with its vendored certifi 2026.10.19, which protects only pip's own operations.

3. On distributions, install the updated ca-certificates package; on RHEL 7, where the package was pending, apply Red Hat's documented trust-store blocklist workaround.

On macOS specifically, the command-line curl, git, and built-in Python verify against /etc/ssl/cert.pem without checking revocation. Apple's advisory 149555 says the platform has blocked the twelve intermediate certificates since October 19 and the root since October 23, and that the fix for /etc/ssl/cert.pem, the file those command-line tools check, "will be available in a future software update".

Until then, remove emSign ECC Root CA - G3 from that file with the removal script the incident site publishes. A second step also drops Sectigo's AAA Certificate Services root to block the six cross-signed copies; it warns that removing AAA can break unrelated sites and that a macOS update may restore the file.

As a website operator with a certificate under emSign ECC Root CA - G3, there is no workaround: Google's Chrome Root Program instruction is that operators "must immediately acquire and install a new TLS certificate from another PKI hierarchy included in the Chrome Root Store", before the root removal reaches devices on the morning of October 27 Pacific time.

Chrome also warned that standard ACME clients do not replace certificates outside their renewal window unless they support ACME Renewal Information (ARI) or someone intervenes by hand; eMudhra estimates about 30,000 certificates need to move, about 97 percent of them ACME-issued. Universities reported a practical path: InCommon RSA certificates under eMudhra's unaffected G1 root still work today, and Let's Encrypt is the common alternative.

What is the root cause?

An intermediate CA's private key must be an unpredictable random number; eMudhra's key ceremony produced, alongside the intended strong keys, a second set so predictable that the public certificates themselves give them away.

The eight intermediates, six for TLS (EM DV, EM OV and EM EV TLS CA in G3B and G3C variants) and two for code signing (EM OV CS CA G3B and G3C), were created under emSign ECC Root CA - G3 in a key generation ceremony on April 30, 2025, on hardware security modules certified to FIPS 140-2 Level 3.

In its incident statement, eMudhra said that "a key wrap/unwrap step produced a second, weak set of keys alongside the original strong keys". Key wrapping packages a key for transfer, and unwrapping unpacks it again. eMudhra added that "the weak keys were the ones published to the browser root stores".

The incident site states the consequence plainly: "The private keys for the intermediate certificates were incorrectly generated by the CA. This means that anyone can recover them from the certificates." Scott Helme verified it in practice, recovering all eight keys from the public certificates in under a second on his laptop.

One of the eight values is the number 4; the rest are also whole numbers below 256.

Two aggravating facts surfaced afterward.

In 2025, eMudhra had published invalid CRLs for six of the same intermediates and reported fixing them by "regenerating the CRLs using the appropriate private key associated with each Intermediate CA". On October 19, 2026, the company told Mozilla those lists had in fact been "resigned with flawed keys", the same weak keys. Chrome said this "raises serious concerns regarding eMudhra's transparency and incident handling".

On October 14, 2026, eMudhra published a CRL for emSign Root TLS CA - G1 whose signature does not verify against that CA's key. A Mozilla bug report participant assessed it as signed with an OCSP certificate's key, "a case of using the wrong signing key, rather than evidence of another weak key".

As of October 22, eMudhra had not answered Chrome's twelve questions about these points.

How is it exploited?

Exploitation is mechanical: recompute one of the eight private keys from the public certificate, forge a leaf certificate for the target domain, and intercept the connection of a client that skips CT and revocation checks. No exploitation has been observed in the wild. The attack path for an affected client:

1. The attacker computes one of the eight private keys from the public intermediate certificate, the step that takes under a second on a laptop.
2. The attacker issues a certificate for any domain they want to impersonate, signed by that intermediate, and serves it from a position that can intercept or answer the victim's connections: a rogue access point, a BGP or DNS interception, a malicious intranet host.
3. The victim's client builds a chain from the forged leaf through the intermediate to a root it trusts, either emSign ECC Root CA - G3 in its bundle, or Sectigo's AAA Certificate Services through the cross-signed copy of the intermediate.
4. The connection is accepted if the client does not enforce Certificate Transparency and has not received the revocation blocks or an updated bundle. Enforcing CT would force the attacker to log the forged certificate publicly, where it could be spotted. Browsers fail both conditions and are safe; most command-line tools, bundled runtimes and embedded clients historically fail both and were exposed until they were patched.

The decisive mitigating fact is that no certificate chaining to the six TLS intermediates was ever logged to Certificate Transparency before the blocks went in. CT-enforcing browsers require a logged certificate, so no forged certificate from those intermediates reached Chrome, Edge, Firefox or Safari. Whether anyone used the keys against non-CT clients is not knowable from CT logs, and the incident site says it is unknown.

How does the attack flow?

The flow is linear: compute the key from the public certificate, forge a leaf for the target domain, position yourself on the connection path, and let a non-CT client validate the chain.

What can an attacker do?

Against an unpatched, non-CT client, the attacker can impersonate any website or service the client connects to over TLS: harvest credentials, serve malware as an update feed, or redirect API traffic, all with a certificate the client fully trusts. The conditions:

• A network position that can intercept or answer the victim's traffic. No action from the victim beyond connecting is needed.
• A client that trusts one of the affected roots or cross-signs, does not enforce CT and has not received a block. That combination excludes current browsers and includes curl-based tooling, runtimes and applications with their own bundles, Electron apps built before the patched releases, and IoT devices.
• Nothing else. The keys were never stolen because they never needed to be: they were published, effectively, inside the certificates themselves.

The two code-signing intermediates extend the theoretical surface to signed code on platforms that trust them, though Chrome's TLS verifier will not build a path through an intermediate restricted to code signing, and no code-signing abuse has been reported. Certificate Transparency, the logging that confirms no forged TLS certificate reached the browsers, covers only TLS certificates, so it offers no comparable trail for signed code.

Why does the fix work?

The fix works because it closes every path a forged chain could take: key denylists reject the weak keys themselves, bundle removals cut the root, and pushed revocation blocks the intermediates in browsers. Each mechanism has different coverage:

• Key denylists, the strongest: Go's crypto/x509, Node.js and Python's ssl module reject any certificate carrying one of the eight keys, including the Sectigo cross-signed copies. Python matches the SHA-256 hash of each certificate's SubjectPublicKeyInfo regardless of SSLContext policy, and Go's denylist has no off switch.
• Bundle removals, the broadest: certifi, webpki-roots, Debian, Ubuntu, Fedora, RHEL and other distribution packages drop emSign ECC Root CA - G3 entirely, cutting off every certificate under the root, legitimate or forged.
• Pushed revocation, the fastest: CRLSets, OneCRL and Microsoft's trust-list updates block the intermediates for browsers with no software update.

The limits matter. A denylist only helps once the software is rebuilt or updated; Go binaries must be recompiled.

A bundle removal also cuts off the legitimate certificates under the root, which Mozilla, Canonical and Red Hat all warned about, and it is exactly what breaks the roughly 30,800 live certificates when Chrome removes the root itself on October 27.

Revocation-based protection covers only clients that actually consume revocation data, which the affected non-browser clients generally do not. That gap is why the denylist pattern in Go, Node.js and Python exists at all. As Filippo Valsorda put it on the Go issue:

"Linux root stores are maintained too inconsistently for revocation to reach applications, so the keys are rejected in code."

How do I check if I was compromised?

There is no published way to detect past misuse of the keys against non-CT clients, and the incident site says it is unknown whether anyone exploited the flawed generation before October 17. What you can verify:

• Client side, run the four checker hosts from the "Am I affected?" section in every environment that matters, including inside containers and on build machines. The site also publishes chains.zip with each served chain in PEM format for offline verification with OpenSSL, plus per-user-agent success statistics for the checkers.
• Server side, inventory your certificates for anything chaining to emSign ECC Root CA - G3 or emSign Root TLS CA - G3 using your CT-log monitor of choice; anything found must be replaced before October 27 rather than merely watched.
• Certificate management side, check whether your ACME setup supports ACME Renewal Information (RFC 9773); without it, clients do not replace certificates outside the renewal window, which is how a certificate that expires in November still breaks on October 27.

Timeline

• 2025-04-30: eMudhra's key generation ceremony creates the eight intermediates, producing the weak key set alongside the strong one.
• 2025: eMudhra publishes invalid CRLs for six of the same intermediates, later acknowledged as "resigned with flawed keys".
• 2026-10-17: Wayne reports the recoverable keys to the root programs with signed proof; Chrome ships a CRLSet block by 19:45 UTC and Mozilla pushes OneCRL by 22:59 UTC.
• 2026-10-19: Downstream trust stores are notified; Android receives its block through Google Play services around 22:00 UTC; Apple begins blocking the twelve intermediate certificates on Apple devices, per its advisory; eMudhra tells Mozilla the 2025 CRLs were resigned with the flawed keys.
• 2026-10-20: Mozilla and Google publish; Go releases 1.27.3 and 1.26.10; certifi releases 2026.10.19; Firefox 158.0.1 and ESR carry the block; Microsoft platform blocks arrive; Mozilla removes the root from NSS.
• 2026-10-21: eMudhra discloses the ceremony flaw in a BSE press release; CERT-In publishes advisory CIAD-2026-0050; Red Hat publishes RHSB-2026-012; Node.js ships its blocklist; Azul ships its out-of-cycle Zulu and Zing builds blocking the eight intermediates; eMudhra shares fall 20 percent in Mumbai.
• 2026-10-22: eMudhra's board decides to exit the global SSL/TLS business (about 1 percent of revenue); Chrome's twelve questions to eMudhra remain unanswered publicly.
• 2026-10-23: Apple also begins blocking emSign ECC Root CA - G3, per its advisory.
• 2026-10-24: Python announces the ssl-module denylist as CVE-2026-115557 and backports it to the 3.11 through 3.15 maintenance branches.
• 2026-10-25: Python releases 3.15.2, 3.14.10, 3.13.18, 3.12.16 and 3.11.18, the first releases carrying the denylist; certifi 2026.10.23 becomes current.
• 2026-10-27: Chrome Root Store version 43 removes emSign ECC Root CA - G3, expected to reach devices the morning of October 27, Pacific time. Apple's macOS update covering the command-line tools had still not shipped as of the morning of October 27, and its security-releases index carried no entry for this incident, so the manual /etc/ssl/cert.pem steps below remain the fix for the built-in curl, git and Python.

FAQ

Is my browser safe to use right now?

Yes. Chrome, Edge, Firefox and Safari enforce Certificate Transparency, and no certificate from the six TLS intermediates was ever CT-logged, so no forged certificate from those intermediates reached a browser, even before the revocation blocks arrived. The blocks since October 17 close the door for anything a browser might accept without a CT check.

I updated macOS. Why is curl still vulnerable?

Apple blocked the twelve intermediate certificates (each TLS intermediate under eMudhra's root and as cross-signed by Sectigo) on October 19, and the root on October 23, through automatic certificate configuration updates. These protect Safari, Mail and apps on Apple's networking and security frameworks.

The built-in curl, git and Python verify against /etc/ssl/cert.pem without checking revocation. Apple's advisory 149555 says the fix there "will be available in a future software update". Until then, remove the root from the file by hand or with the incident site's script; a macOS update may restore the file.

Will my website actually break on October 27?

Only if its certificate chains to emSign ECC Root CA - G3, which about 30,800 unexpired certificates did as of October 21. For those, yes: once Root Store version 43 reaches a Chrome user, the chain no longer validates. Google's guidance to operators is to replace the certificate immediately, not to wait for the removal, and to remember that ACME clients do not renew early without ARI support.

Was eMudhra hacked?

No system was breached and no keys were stolen, which is what makes the incident unusual. The keys were generated badly, and a badly generated key is public in effect: anyone with the certificate could compute it, no intrusion required. eMudhra says seven of the eight intermediates were never used in production, and none of the eight, including the one that was, issued an end-entity certificate.

Do I need to remove the Sectigo root too?

Only for clients you cannot otherwise fix. Six of the eight intermediates also exist cross-signed under Sectigo's AAA Certificate Services root, so removing emSign ECC Root CA - G3 alone leaves those paths open. But removing AAA also cuts off every legitimate certificate under it, which is why the distribution updates that remove both also warn about breakage, and why the key-denylist fixes are the better answer where one exists.

Is this the same as the Go emergency update I installed on October 20?

Yes. Go released 1.27.3 and 1.26.10 that day without naming the CA, blocking eight key hashes in crypto/x509 on its URGENT track; the eight hashes match these eight certificates. Go's security team said it kept the release notes vague because the flaw was trivially exploitable and it expected the details to become public that day.

Find the certificates that break on October 27

Use Ostorlab Attack Surface Discovery to inventory the internet-facing domains and hosts you own. Then check the certificate chain each one serves for emSign ECC Root CA - G3, and replace any match before Chrome removes the root on October 27.

References

• The incident site with the proof, checker hosts, offline chain bundle and the who-has-patched table, maintained since October 20, 2026: https://emudhra.we-have-a-problem.com/ (checked October 27, 2026)
• Apple's advisory on the compromised eMudhra intermediate CAs, 149555: blocking since October 19, the root since October 23, the /etc/ssl/cert.pem fix in a future update, manual removal steps; Apple's security-releases index, checked for an incident entry the morning of October 27, 2026: https://support.apple.com/en-us/149555 and https://support.apple.com/en-us/100100 (checked October 27, 2026)
• Azul's statement on the eMudhra intermediate CA compromise, October 22, 2026, with the October 21 out-of-cycle Zulu and Zing builds blocking the eight intermediates: https://www.azul.com/newsroom/azul-statement-on-the-emudhra-intermediate-ca-certificates-compromise/ (checked October 26, 2026)
• Google on protecting Chrome and Android users from the compromised eMudhra intermediate CA certificates, October 20, 2026: https://blog.google/security/protecting-chrome-and-android-users-from-compromised-emudhra-intermediate-ca-certificates/ (checked October 25, 2026)
• Mozilla on protecting Firefox users, October 20, 2026: https://blog.mozilla.org/security/2026/10/20/protecting-firefox-users-following-the-compromise-of-emudhra-intermediate-certificates/ (checked October 25, 2026)
• Chrome Root Program and Mozilla policy-list threads quoted in the coverage: https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/0R3XLJL6FuE/m/Kp1v6CPuAAAJ (checked October 25, 2026)
• eMudhra press release filed with the BSE stock exchange on the April 30, 2025 ceremony flaw: https://www.bseindia.com/xml-data/corpfiling/AttachLive/6be0c423-b335-494b-86f3-54c561c3a5f9.pdf (checked October 25, 2026)
• eMudhra's certificate-security-incident statement: https://emudhra.com/en/post/certificate-security-incident (checked October 25, 2026)
• Scott Helme's independent key recovery, all eight keys in under a second, one of them the number 4: https://scotthelme.co.uk/eight-bits-of-trust-emudhras-ca-keys-cracked-in-milliseconds/ (checked October 25, 2026)
• The Hacker News on the eight compromised CA keys and the ecosystem's emergency fixes, October 20, 2026, updated October 21: https://thehackernews.com/2026/10/eight-emudhra-ca-keys-compromised.html (checked October 25, 2026)
• The Hacker News on eMudhra exiting the global SSL/TLS business, the approximately 30,800 unexpired certificates, the InCommon concentration and Chrome's October 27 removal, October 22, 2026: https://thehackernews.com/2026/10/emudhra-to-exit-global-ssltls-business.html (checked October 25, 2026)
• Go's emergency releases blocking the eight keys, CVE-2026-111943: https://groups.google.com/g/golang-announce/c/66pojueaQek and https://cveawg.mitre.org/api/cve/CVE-2026-111943 (checked October 25, 2026)
• Python's ssl-module denylist announcement, CVE-2026-115557, October 24, 2026: https://www.openwall.com/lists/oss-security/2026/10/24/5 and https://cveawg.mitre.org/api/cve/CVE-2026-115557 (checked October 25, 2026)
• The Firefox CVE-2026-113470 record, with no score from Mozilla and CISA's 5.4 Medium enrichment: https://cveawg.mitre.org/api/cve/CVE-2026-113470 (checked October 27, 2026)
• CPython release changelogs confirming the denylist first shipped in 3.15.2, 3.14.10, 3.13.18 and 3.12.16 on October 25, and the CPython compare view confirming v3.11.18, tagged the same day, contains the backport: https://docs.python.org/3.15/whatsnew/changelog.html and https://github.com/python/cpython/compare/af52b41afa4330fb38583db553631baa2f122f90...v3.11.18 (checked October 26, 2026)
• Oracle's out-of-band Java alert removing the eMudhra roots, CVE-2026-114820: https://www.oracle.com/security-alerts/alert-cve-2026-114820.html (checked October 25, 2026)
• certifi advisory GHSA-6q48-6c7w-9gw2 removing the emSign root: https://github.com/certifi/python-certifi/security/advisories/GHSA-6q48-6c7w-9gw2 (checked October 25, 2026)
• uv advisory GHSA-hq85-5cpj-mr62 removing the emSign root: https://github.com/astral-sh/uv/security/advisories/GHSA-hq85-5cpj-mr62 (checked October 25, 2026)
• Red Hat security bulletin RHSB-2026-012 with the RHEL trust-store workaround: https://access.redhat.com/security/vulnerabilities/RHSB-2026-012 (checked October 25, 2026)
• CERT-In advisory CIAD-2026-0050, October 21, 2026: https://www.cert-in.org.in/s2cMainServlet?pageid=PUBVLNOTES02&VLCODE=CIAD-2026-0050 (checked October 25, 2026)
• Cloudflare's fixed WARP, 1.1.1.1 clients and cloudflared 2026.10.2: https://blog.cloudflare.com/emudhra-certificate-compromise (checked October 25, 2026)
• mongosh 2.14.0 release, October 23, 2026, bundling Node 24.22.1 with the key blocklist, where earlier versions verify against the host Node runtime's trust store: https://github.com/mongodb-js/mongosh/releases/tag/v2.14.0 (checked October 27, 2026)