The private keys were weak enough to recompute from the public certificates. That is the failure mode Chrome, Go, and the other trust stores raced to block.
On Saturday 17 October 2026 at 18:05 UTC, the Chrome Root Program received a report that eight eMudhra subordinate CA certificates had private keys generated with insufficient randomness. By 19:45 UTC Chrome had corroborated the finding and shipped a CRLSet update blocking the affected Subject Public Key Info hashes. Android and Google devices followed through Play Services. The failure mode is simple to say and hard to clean up: anyone who can derive the keys can mint certificates for arbitrary names against clients that still trust those intermediates.
A 30 April 2025 ceremony produced intermediates with single-byte entropy
Kudelski Security's 21 October research note, building on the Mozilla thread and the researcher's disclosure, places the eight intermediates in a batch of twenty-four produced during a key ceremony on 30 April 2025. Certificates carry NIST P-384 public keys. The corresponding private keys reportedly took effective values such as 4, 56, 66, 115, 155, 156, 230, and 237 rather than roughly 384 bits of entropy. eMudhra has described a flawed ceremony script, an approved test deviation, and a weaker onboard key pair mistakenly used for the CSR.
The affected set is six TLS intermediates (EM DV/OV/EV TLS CA G3B and G3C) and two code-signing intermediates (EM OV CS CA G3B and G3C), under emSign Root TLS CA - G3 and emSign Root CS CA - G3. Each also exists as a Sectigo (AAA Certificate Services) cross-sign, bringing the certificate count to sixteen. The researcher signed the demonstration message "We have a problem here - Wayne" with the recovered keys.
Chrome, Firefox, Go, and the root-program cascade publish timed blocks
Chrome's public post (20 October) states that no TLS certificates chaining to the six TLS intermediates were logged to Certificate Transparency before the blocking action, so CT-enforcing clients, including Chrome by default, should not have accepted fraudulent certificates from those CAs prior to the block. Chrome later moved to remove emSign ECC Root CA - G3 from the Chrome Root Store for consumers that do not take CRLSet updates, with breakage expected for remaining legitimate subscribers on that root and a migration commitment from eMudhra.
Mozilla distrust via OneCRL began the evening of 17 October. eMudhra revoked the eight intermediates on 18 October; Sectigo revoked cross-signs by 19 October. Apple and Microsoft shipped protections around 19–20 October. Mozilla emergency-distrusted emSign ECC Root CA - G3 on 20 October.
Go's security releases 1.27.3 and 1.26.10 address the trust-store side for the toolchain (CVE-2026-111943). Node, certifi, and distribution ca-bundles entered the same remediation wave. Kudelski notes Firefox 158.0.2 fixed an Android blocklist issue on 21 October.
eMudhra estimates roughly 30,000 affected subscriber certificates, about 97% issued through ACME, and has ceased issuance from the affected chains while migrating customers toward the G1 RSA hierarchy. emSign Root CA - G1 is described as remaining.
Browsers heal first; non-browser TLS clients become the long tail
Once CRLSet, OneCRL, and vendor root updates land, mainstream browsers stop trusting the weak intermediates quickly. The durable exposure moves to everything that embeds its own CA bundle and updates slowly: containers, IoT firmware, VPN clients, language runtimes, and agent toolchains built with older Go or Python trust stores. Filippo Valsorda's warning, relayed in secondary coverage and Kudelski's note, is that cleanup may outlast the acute browser window for the same structural reasons Heartbleed did.
Rebuild Go binaries, refresh CA bundles, and migrate emSign ECC G3 subscribers
Operators should verify browser and OS updates, rebuild Go services on 1.27.3 or 1.26.10 or later, refresh container base images and ca-certificates packages, and inventory mTLS trust stores and uploaded origin certificates. Subscribers still chaining to emSign ECC Root CA - G3 need a replacement certificate from an unaffected hierarchy. Do not "fix" the incident by disabling certificate validation on model endpoints or hub downloads.
For AI delivery paths specifically, treat Hugging Face downloads, inference gateways, webhook callbacks, and agent tool MCP endpoints as ordinary TLS clients. If the binary or image pins an old CA bundle, browser safety does not transfer.
Absent confirmed exploitation still leaves residual trust risk
Researchers and Google report no confirmed active exploitation and no CT evidence of malicious pre-block issuance against CT-enforcing clients. That finding leaves open whether every non-CT client stayed safe, and whether every embedded bundle has already been updated. The researcher's test hosts presenting chains from compromised intermediates are demonstration infrastructure; they do not constitute an exploitation ledger.
Complete embedded-device inventory and final Chrome Root Program disposition remain open
A full inventory of IoT and appliance trust stores that still accept the weak keys will not appear as a single primary document. Chrome Root Program review of eMudhra's remaining inclusion is ongoing in public forums such as the Common CA Database lists. Until those close, assume the browser story is largely handled and the agent-toolchain story is only as good as your oldest pinned bundle.