Eight intermediate certificate authorities run by eMudhra, six for TLS and two for code signing, had private keys that were single-byte numbers. One of them was the number 4. Anyone holding the public certificates could have computed the keys at any point since April 2025. Browsers blocked them within hours to three days. Almost everything else that speaks TLS has to be found and updated by hand.
What happened
On Saturday, October 17, a researcher credited as "Wayne" told the Chrome and Mozilla root programs, Apple, Microsoft and eMudhra that the eight keys were compromised, and proved it by signing a message with each one. The keys were never stolen. According to eMudhra, a flaw in its April 30, 2025 key generation ceremony produced a second, weak set of keys beside the intended ones, and the weak set is what reached the root stores.
The browser response was fast. Chrome pushed a CRLSet block for the six TLS keys at 19:45 UTC the same evening, and Mozilla finished its OneCRL block at 22:59 UTC. Apple followed on October 19 and Microsoft on October 20. Mozilla has removed emSign ECC Root CA - G3 from NSS, and Chrome is removing it from its root store.
There is no public evidence of misuse. Chrome reports that no certificate chaining to these CAs was ever logged to Certificate Transparency, so no forged certificate could have been trusted by default in Chrome or another CT-enforcing browser. Ars Technica's Dan Goodin quoted Go cryptography maintainer Filippo Valsorda on what comes next: "a massive cleanup job, bigger than Heartbleed."
Why this is worse than a stolen key
A stolen key has a moment of theft and a thief. These keys had neither. They were recoverable from day one, so there is no way to know who computed them in the seventeen months before the report. Scott Helme recovered all eight on a laptop in under a second, and reports that an AI model did it from a single prompt.
Certificate Transparency protects the clients that require it, and that is mostly browsers. curl, Python, Node, Go, Java, git, package managers, CI runners and most daemons trust a CA bundle on disk and check neither revocation nor CT by default. A clean CT log tells you nothing about what may have been presented to them.
Two of the keys are code-signing CAs. Any Windows verifier that does not check revocation would treat software signed under them as legitimately signed.
Who is still exposed
Exploitation needs an active attacker in the network path: a hostile Wi-Fi network, a compromised switch, a malicious network operator. With that position, the attacker can impersonate any site to any client that still trusts these CAs. That list is long:
Non-browser TLS clients: curl, Python, Go, Java, cloud CLIs and SDKs, Terraform, kubectl.
Installers and self-updaters: curl-pipe install scripts and firmware updaters, where a forged certificate means running someone else's code.
CI/CD and containers: runners and build images on stale base images, often holding cloud keys and signing keys.
Server-to-server traffic: webhooks, payment and OAuth calls, origin connections.
VPN clients that validate the concentrator with the public PKI.
Embedded, IoT and OT devices with frozen trust bundles, which keep trusting these intermediates until they expire or the firmware is replaced.
Mutual-TLS trust stores that accept the eMudhra or Sectigo roots for client certificates.
Patches are landing quickly. Dennis Jackson's incident tracker lists fixes for the major Linux ca-certificates packages, NSS, the curl bundle, Go, Python certifi, pip, uv, Node.js, Electron and Rust's webpki crates, with Java, Bun and FreeBSD still pending as of October 21. A patch only helps once it is deployed on every host, in every image and in every tool that ships its own roots.
Not affected: Signal, WhatsApp and WireGuard, which do not rely on the web PKI for confidentiality.
What to do now
1. Remove or block. Block the eight keys if your stack supports it; otherwise remove trust in emSign ECC Root CA - G3 and the Comodo AAA Services root from every store you operate.
2. Update every bundle. OS ca-certificates on hosts and in container images, language runtimes, Java cacerts, and every CLI that bundles its own roots. Rebuild images and restart what loaded the old bundle.
3. Review the trust you accept. Mutual-TLS CA lists on edges, load balancers and APIs, VPN concentrators, and Windows code-signing policy.
4. Test the real verifier path. Point each application's own TLS stack at the public test hosts. A passing browser check proves nothing about a background service.
5. Never fix the error by disabling verification. Servers still presenting eMudhra chains need a new CA, not a weaker client.
6. Track the long tail. Inventory the devices and software you cannot update this week and plan their isolation or replacement.
Is this a quantum problem?
No. The failing component is a classical P-384 key that was generated wrongly. Post-quantum cryptography would not have prevented it, and we will not pretend otherwise.
What this incident does test is the same muscle a post-quantum migration needs: knowing where your cryptographic trust lives, changing it by policy and proving the change landed. Most organizations will spend this week answering three questions by hand. Which hosts still trust the two roots? Which clients would still accept a forged certificate? Which servers still present an affected chain?
Our Take
Browsers solved their part of this in hours because they have a central way to change trust and prove it. Most enterprises have neither for the rest of their estate. Treat this week as a crypto-agility fire drill: the time it takes your team to answer those three questions is a fair preview of how a post-quantum migration will go. Federal agencies owe OMB their post-quantum migration plans tomorrow, October 22. This is the same inventory problem at a smaller scale.
So what
QuantaView™, EnQuanta's Cryptographic Intelligence Platform, answers all three questions from inventory it already holds:
Which hosts still trust the two roots? QuantaView's Endpoint Client inventories each host's trust-store roots. Remove the two roots from your approved trust-anchor set and the incident becomes one finding with a host list.
Which clients would still accept a forged certificate? It records how each certificate consumer validates (trust anchors, name checks, revocation mode, fail-open behavior) for curl, git, pip, npm, Java, nginx, Apache, HAProxy, Kubernetes and Windows policy, and a read-only bench asks the host's own TLS stacks (OpenSSL, curl, wget, PowerShell) to connect to deliberately bad chains and records which accept one.
Which servers still present an affected chain? The TLS scanner records issuer organization and SPKI hash for every endpoint it reaches, so a search for eMudhra or emSign lists the servers to move. Re-keying and renewal run as human-approved, reversible jobs; the replacement issuer is a choice your PKI team configures.
To be precise about scope: QuantaView finds the hosts, verifies the change and keeps the evidence. It does not remove or replace public roots in your trust stores; that operating-system change is your team's.
For applications that cannot afford to depend on any public CA, the QuantaCrypt™ SDK lets the application own its trust: a CA bundle it supplies, mutual TLS, a peer-certificate pinning callback (in the Go and Swift bindings today), and records sealed under keys derived from a shared secret the PKI cannot forge. QuantaCrypt is a FIPS 140-3 validated cryptographic module, CMVP certificate #5312.
Want those three answers for your own estate? We'll run them on a representative slice. Book a 20-minute scoping call.
Incident facts are as published by Mozilla, the Chrome Root Program, eMudhra, Dennis Jackson, Scott Helme and Ars Technica as of October 21, 2026, and may change as the investigation continues. QuantaView and QuantaCrypt are trademarks of EnQuanta.