Mozilla says private keys for eight eMudhra intermediate CA certificates were compromised and could let attackers issue fraudulent HTTPS certificates; eMudhra says the keys were cryptographically weak, it revoked all eight on 19 October and none had issued a certificate; Chrome and Firefox blocked them on 17 October, Mozilla and Chrome are removing the signing root, and Go 1.27.3 / 1.26.10 block trust in them (CVE-2026-111943)

Mozilla said on 20 October 2026 that on 17 October at 20:06 UTC (18 Oct 04:06 Perth) a community member reported that the private keys behind eight intermediate certificates of Indian certificate authority eMudhra had been compromised, which would let an attacker issue HTTPS certificates for sites they do not control. Firefox blocked the certificates through OneCRL by 22:59 UTC the same day without needing an update, and Mozilla is now shipping an NSS trust-store update that removes the root that signed them, which will break some non-Firefox clients until affected servers move to new chains. The Chrome Root Program said it got the same report from a researcher at 18:05 UTC on 17 October and pushed a CRLSet block on the public keys of the six TLS-issuing intermediates at 19:45 UTC, which also covers Sectigo cross-certificates that share those keys; the two code-signing intermediates cannot be used for TLS in Chrome. Chrome says no TLS certificates chaining to the six intermediates were in Certificate Transparency logs before the block, so no fraudulent certificate could have been trusted by default in Chrome or other CT-enforcing browsers. Chrome Root Store version 43 will drop the upstream eMudhra root, and Chrome is reviewing eMudhra's remaining CA certificate. Mozilla says it does not believe other CAs are affected and has not said how the keys were exposed; eMudhra's responses are posted in Mozilla's incident bug (see the 21 October update), and it has since published a statement on its website (first published 20 October, updated 21 October; see the update below). Separately, Go released 1.27.3 and 1.26.10 on its URGENT security track (CVE-2026-111943, Go issue 82345): crypto/x509 now drops any chain through the eight keys, matched by public-key hash so cross-signed copies are caught too, including on the macOS and Windows platform verifiers. There is no switch to turn it off, and it also bites private deployments that deliberately trust those keys. Go clients only get the block once rebuilt on a fixed release, since Go's verifier does no revocation checking. The Hacker News reports a commenter matched the hashes to EM DV, OV and EV TLS CA - G3B/G3C and EM OV CS CA - G3B/G3C under emSign Root TLS CA - G3 and emSign Root CS CA - G3. Microsoft and Apple had not published a response. Primary: Mozilla dev-security-policy (Mozilla and Chrome Root Program posts); vendor: Go issue 82345; wire: The Hacker News (20 Oct). UPDATE (20 Oct, Mozilla Security Blog): Mozilla released Firefox 158.0.1 for desktop and Android, Firefox ESR 115.43.1 and Firefox ESR 153.5.1 to deliver the block to the minority of users whose custom settings stopped the OneCRL update, and NSS 3.131.1, which removes the root that signed the affected intermediates from Mozilla's trust store for other applications that use it or lists derived from it. UPDATE (20–21 Oct): Mozilla's Dennis Jackson told trust-store maintainers on 19 October (oss-security, posted 20 Oct) that six of the eight intermediates are for TLS and two for code signing, that eMudhra revoked them on 18 October and Sectigo revoked its cross-certificates on 19 October, and that clients which do not check revocation, or fail open, need a trust-store update; he warned abuse of the keys is likely in the near future and that no certificates from them had appeared in Certificate Transparency logs. A disclosure site he maintains (emudhra.we-have-a-problem.com) says the reporter, 'Wayne', proved the compromise on 17 October by signing a message with each key, and that Apple devices have blocked the certificates since 19 October. Cyber Kendra reports Microsoft blocked them on 20 October; Microsoft had not published its own notice as of 21 October. The site tracks downstream fixes: Ubuntu ca-certificates 20260816ubuntu0.22.04.1/24.04.1/26.04.1/26.10.1, Alpine ca-certificates 20261020-r0, Arch ca-certificates-mozilla 3.131.1-1, Gentoo, Chainguard, the curl CA bundle of 2026-10-20, Python certifi 2026.10.19, pip 26.2.2, uv 0.13.4, Rust rustls-webpki 0.103.16 and 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 and Elixir castore 1.0.22; Debian, Fedora, FreeBSD, Node.js and Bun were still pending. It also warns that macOS's built-in curl checks /etc/ssl/cert.pem without revocation, and that file has not been updated. UPDATE (21 Oct; Mozilla Bugzilla incident 2083449 and the disclosure site): the cause is flawed key generation, not theft. Mozilla's Dennis Jackson found the eight P-384 private keys were all integers smaller than 256, so anyone can recover them almost instantly from the public certificates; Mozilla recovered them independently on 17 October without knowing the reporter's method, and says several other people have since done the same, at least one publicly. The keys came from a 30 April 2025 key ceremony, so the weakness has existed since then; no certificates from them appeared in Certificate Transparency logs in that period, so CT-enforcing browsers (Firefox, Chrome, Edge, Safari) could not have been attacked, but it is unknown whether clients that do not enforce CT were. eMudhra said in the bug (19 Oct) that the keys were made on Utimaco HSMs during an approved deviation to test key wrap and unwrap for export to its US and European data centres, that a script flaw created a second, weak set of keys, and that these were used by mistake to make the certificate requests because the key labels were similar, including the requests sent to Sectigo for cross-signing. It says only EM DV TLS CA - G3C was in production and no end-entity certificates were issued from the eight; its RSA intermediates and India-only A-series keys (Entrust HSMs) are not affected; and it will re-check every key ceremony over the next week. On 20 October Mozilla began an emergency removal of trust in emSign ECC Root CA - G3 (not emSign Root CA - G1), and Chrome committed to the same. eMudhra stopped issuing from all intermediates under the G3 ECC root that day and said about 30,000 certificates, about 97% issued via ACME, must move to chains under its RSA root G1. Sectigo completed revocation of its cross-certificates on 19 October. Debian (20250419~deb12u2, 20250419+deb13u1, 20260816+nmu1) and Fedora (2026.2.92_v9.0.319) have now shipped ca-certificates fixes, and the disclosure site gives a manual workaround for FreeBSD 14 and later; FreeBSD packages, Node.js and Bun were still pending. UPDATE (21 Oct; Cloudflare blog and disclosure site): Cloudflare says it learned of the compromise at about 17:00 UTC on 19 October, patched critical services before public disclosure and has found no active exploitation on its services. It has shipped fixed Cloudflare One / WARP clients (Android 2.5.6, iOS 1.12.16, Windows, macOS and Linux 2026.8.2115.0), 1.1.1.1 app (Android 6.38.10, iOS 6.31.7) and Cloudflare Tunnel (cloudflared) 2026.10.2, and deployed mitigations across its CDN, Developer and Zero Trust products; Gateway users with current clients are protected. Customers must still review mutual TLS trust stores used to verify client certificates, origin certificates and server settings in Full (strict) mode, and container images, and Cloudflare warns that updating an SDK may not change the trust store an HTTP library or runtime actually uses, and that errors should not be fixed by turning off verification. The disclosure site now says Microsoft platforms have blocked the certificates since 20 October, and lists Cloudflare CFSSL trust store 2026.10.1 and Perl Mozilla::CA 20261020 as fixed. UPDATE (21 Oct, evening Perth): Node.js's 21 October security releases (26.12.1, 24.22.1, 22.23.4) include a CA-certificate update for the eMudhra intermediate CA compromise on all three lines (see this desk's Node.js card). UPDATE (21 Oct, eMudhra statement): eMudhra's statement on its website, last updated 21 October, says an independent security researcher reported on 18 October that the keys of eight of its Global TLS intermediate CAs were cryptographically weak, and that it revoked all eight the following day. eMudhra says no certificates had been issued from any of them, its infrastructure was not compromised and no data was breached, seven of the eight were never used in production, and the browser root programs distrusted its ECC root as a precaution. It says the keys were generated on FIPS 140-2 Level 3 certified HSMs and that a key wrap/unwrap step in the April 2025 ceremony produced a second, weak set of keys, which were the ones published to the browser root stores; it says it has not yet confirmed the exact root cause and is not aware of any evidence that the weak keys were recovered or exploited by anyone before the issue was disclosed. eMudhra says the impact is limited to TLS certificates chaining to the distrusted ECC root and contained to a single customer ecosystem in the United States, which it is moving to certificates from an alternate, independently operated, publicly trusted CA hierarchy, and that its digital signature and eSign services, emSigner, CertiNext, emCA, Privatrust and SecurePass are not affected. UPDATE (22 Oct, eMudhra press release): eMudhra announced on 22 October that its board has decided to voluntarily withdraw from the global SSL/TLS certificate business. Chairman V. Srinivasan said global SSL/TLS contributes about 1% of eMudhra's global revenue, that the company revoked the affected CAs within 14 hours of discovery, that no end-entity certificates were issued from them, and that its infrastructure was not compromised and no data was breached. eMudhra says its G1 RSA roots will keep serving customers until the transition is complete, it will contact affected customers to replace certificates free of cost from partners, revocation and status services will run until every issued certificate has expired or been replaced, and it will deliver a full root-cause report to the browser root programs; it gave no exit date and did not name the partners. It says its digital signature certificate, eSign, emCA, CertiNext, emSigner, SecurePass and emAS services are not affected. Google's security blog says the removal of emSign ECC Root CA - G3 from the Chrome Root Store is expected to reach all devices relying on it on Tuesday morning, 27 October 2026 (US Pacific time), and that website operators with certificates chaining to that root must immediately get a new TLS certificate from another hierarchy in the Chrome Root Store. UPDATE (21–22 Oct; Mozilla Bugzilla incident 2083449): the Chrome Root Program posted 12 questions to eMudhra on 21 October (20:38 UTC, 22 Oct 04:38 Perth). It says that, based on Certificate Transparency data as of 21 October, about 30,800 unexpired precertificates chain to emSign ECC Root CA - G3, and 30,791 of them (99.9%) were issued by two Internet2 / InCommon subordinate CAs (InCommon Intermediate CA - OVG3C, 23,806; DVG3C, 6,985), with 18 from eMudhra's own intermediates. Chrome asks how ACME subscribers will actually be renewed before Chrome Root Store v43 lands (expected in Stable on 27 October 2026, US Pacific time), for per-CA migration figures and a completion date, and why eMudhra's June 2025 report on mis-signed CRLs (Bug 1970728) did not disclose that two key pairs existed for the affected CAs; it says that disclosure 'raises serious concerns regarding eMudhra's transparency and incident handling'. Chrome also asks which private key signed CRL #11 for emSign Root TLS CA - G1, published on 14 October 2026 with a signature that does not verify against that root or any disclosed 4096-bit RSA CA key, and whether multiple key pairs exist for any eMudhra root. eMudhra had not replied in the bug as of the latest comment checked (22 Oct 13:31 UTC, 21:31 Perth). Separately, Mozilla's Dennis Jackson said on 21 October that some Firefox for Android profiles were not applying the updated blocklist at startup and that Firefox for Android 158.0.2 fixes this.

Product

eMudhra / emSign intermediate CA certificates (six TLS, two code signing); Go crypto/x509; Mozilla NSS and Chrome Root Store

Versions

Eight eMudhra intermediates (six TLS-issuing, two code-signing). Go: fixed in 1.27.3 and 1.26.10 (Go 1.25 and older unsupported). Firefox: protected via OneCRL since 17 Oct UTC; Firefox 158.0.1, ESR 115.43.1 and ESR 153.5.1 also carry the block; Firefox for Android 158.0.2 fixes profiles that were not applying it at startup. NSS 3.131.1 removes the signing root. Chrome: protected via CRLSet since 17 Oct UTC; Root Store v43 removes the eMudhra root. Apple: blocked since 19 Oct. Downstream: Ubuntu, Alpine, Arch, Gentoo and Chainguard ca-certificates, curl CA bundle 2026-10-20, certifi 2026.10.19, pip 26.2.2, uv 0.13.4, rustls-webpki 0.103.16, Electron 44.9.1/43.8.1/42.11.16 fixed; Debian and Fedora ca-certificates fixed; Node.js 26.12.1, 24.22.1 and 22.23.4 update the bundled CA certificates (21 Oct); FreeBSD and Bun pending (21 Oct). Mozilla and Chrome removing emSign ECC Root CA - G3.

CVSS

not scored (CVE-2026-111943 has no published CVSS)

Exploited in Australia?

unknown

Patch to

Rebuild and redeploy Go services and tools on Go 1.27.3 or 1.26.10. Keep Firefox and Chrome current (both already block the keys). If you run your own trust store, appliance or Java, OpenSSL or container CA bundle, block the eight intermediates using Mozilla's impacted-intermediates.json or take the updated NSS or Chrome root list when your vendor ships it. If any of your own sites or APIs use an eMudhra or emSign certificate, check its chain now and reissue from another CA, because rebuilt Go clients and updated trust stores will reject it with errors such as 'x509: no valid chains built'. Where Firefox's remote settings or OneCRL updates are disabled by policy, update to Firefox 158.0.1 (Android: 158.0.2), ESR 115.43.1 or ESR 153.5.1; update NSS-based applications and Mozilla-derived CA bundles to NSS 3.131.1 when your vendor ships it. Update OS packages and language bundles as fixes land (Ubuntu and Alpine ca-certificates, certifi 2026.10.19, pip 26.2.2, uv 0.13.4, rustls-webpki 0.103.16, webpki-roots 1.0.10, Electron 44.9.1/43.8.1/42.11.16, Composer ca-bundle 1.4.16/1.6.0); Debian (20250419~deb12u2 / 20250419+deb13u1 / 20260816+nmu1) and Fedora (2026.2.92_v9.0.319) ca-certificates fixes are out; Node.js shipped the CA-certificate update in 26.12.1, 24.22.1 and 22.23.4 on 21 Oct; FreeBSD (manual workaround on the disclosure site) and Bun were still listed as pending on 21 Oct. Use the test hosts on emudhra.we-have-a-problem.com to check whether a client still trusts the keys, and note macOS's built-in curl still trusts them through /etc/ssl/cert.pem. If you hold certificates from eMudhra/emSign chaining to emSign ECC Root CA - G3, replace them now: Mozilla and Chrome are removing that root and eMudhra has stopped issuing under it. Cloudflare users: update WARP / Cloudflare One clients to 2026.8.2115.0 (desktop), 2.5.6 (Android) or 1.12.16 (iOS), the 1.1.1.1 app to 6.38.10 (Android) or 6.31.7 (iOS), and cloudflared to 2026.10.2 (redeploy container images), then review mTLS client-certificate CAs and origin certificates. Chrome's root removal is expected to reach all Chrome Root Store users on the morning of 27 October 2026 US Pacific time (Google); eMudhra says it is exiting the global SSL/TLS business, so plan to move eMudhra/emSign TLS certificates to another CA rather than relying on its G1 root long term.

Primary: Mozilla dev-security-policy — Compromised eMudhra Intermediate Certificates (Mozilla, 20 Oct 2026; Chrome Root Program reply same day) · Vendor: Go — crypto/x509: mitigation for security concerns with a specific Certificate Authority (CVE-2026-111943; fixed in Go 1.27.3 and 1.26.10, 20 Oct 2026) · CVE: CVE-2026-111943 · The Hacker News — Go issues emergency update blocking eight CA keys over undisclosed security concerns (20 Oct 2026) · Mozilla Bugzilla — Bug 2083449, eMudhra compromised intermediates incident (Chrome Root Program questions, comment 30, 21 Oct 2026) · eMudhra — eMudhra to Exit global SSL/TLS Certificate Business (press release, 22 Oct 2026) · Google — Protecting Chrome and Android users from compromised eMudhra intermediate CA certificates

vulnerabilities network identity