Somewhere out there, a researcher called Wayne spent the weekend signing test messages with private keys he was never supposed to have. The keys belonged to eight eMudhra intermediate certificate authorities, and getting them was not hard. The keys were generated so badly that anyone holding the public certificates could recover the private keys by guessing fewer than 256 possibilities. One of them had a private value of 4.
What actually broke
The eight intermediates were created in April 2025 during a key generation ceremony, the formal event where a certificate authority generates the keys that will sign other certificates. Six were for TLS, two for code signing. Their P-384 keys came out with insufficient randomness: the secret values were smaller than 256, which means anyone can brute-force the private key straight from the public certificate. This is not a stolen key situation. The keys were effectively public from birth.
Wayne proved key control by signing a message with each compromised key, then reported it to Mozilla on 17 October 2026 at 20:06 UTC. From there the ecosystem moved with unusual speed.
The response was fast
Mozilla blocked the certificates in Firefox through its OneCRL list, and the block reached every Firefox user on a standard configuration by 22:59 UTC the same day. Under three hours from report to full coverage, with no browser update or restart required. Chrome received the report earlier that afternoon, corroborated it, and had a CRLSet update blocking the intermediates by 19:45 UTC. Apple platforms blocked them from 19 October, Microsoft from 20 October.
eMudhra revoked the affected certificates on 18 October. Sectigo, which cross-signed the intermediates, revoked its cross-signs a day later. Firefox 158.0.1, ESR updates, and NSS 3.131.1 shipped on 20 October with the signing root removed from the trusted list.
There is a reason the machinery worked this smoothly. After DigiNotar in 2011 and the Symantec saga, browser root programs built exactly this: intermediate-blocking infrastructure that can act in hours instead of the months a full root distrust takes. This incident is the first real workout in a while, and it held.
Where it got messy
Revocation is the part of TLS everyone quietly ignores. Browsers enforce it badly or not at all, and most non-browser TLS clients, curl, language runtimes, appliances, never check it at all. So blocking eight intermediates in browsers was the easy half. The other half was shipping updated trust stores across an absurd range of software: Ubuntu, Debian, Fedora and Alpine distributions, the curl CA bundle, Go 1.27.3 and 1.26.10, Python’s certifi 2026.10.19, rustls-webpki, Electron. Node.js and FreeBSD were still pending when the incident report went up.
The reason for the long tail is worse than the compromise itself. The intermediates chain to widely trusted roots, and the only defense available to clients that neither check revocation nor enforce certificate transparency is to remove the root. Chrome is removing the emSign ECC Root CA – G3 root entirely, with removal reaching all devices by the morning of 27 October 2026. Legitimate subscribers under that root, roughly 30,000 certificates by Mozilla’s estimate, now need new certificates from another hierarchy because their CA broke key generation.
Was anyone attacked?
Probably not, and there is actual evidence behind that. Certificate transparency logs show no certificates issued from the compromised intermediates, which means CT-enforcing clients like Firefox, Chrome, Edge and Safari could not have been attacked with logged certificates. Non-CT clients have no such guarantee, and unlogged fraud cannot be ruled out. eMudhra states the incident is limited to the intermediates from the April 2025 ceremony, that its root CA keys were not affected, and that none of the compromised intermediates issued end-entity certificates, which crt.sh records corroborate.
The uncomfortable detail: all of this happened on FIPS 140-2 Level 3 certified hardware security modules. Compliance certification of the box says nothing about the correctness of the script driving it. A KGC that produces keys with fewer than 256 possible values passed through a certified HSM without complaint. The ceremony is the weak point, not the vault.
What to do about it
Update your systems’ trust stores. The patched versions to look for: NSS 3.131.1, Go 1.27.3 or 1.26.10, certifi 2026.10.19, rustls-webpki 0.103.16, and October 2026 ca-certificates from your distribution. Run your package manager’s security update rather than hand-patching.
Check whether anything you run still trusts the compromised intermediates. The incident report’s author hosts test hosts that will fail closed against them, and an offline chains bundle is available for OpenSSL checks on machines you would rather not poke at the public internet.
If you operate servers or clients that do not consume revocation, curl scripts, embedded TLS stacks, appliances, audit them now. The documented workaround is distrusting the emSign ECC Root CA – G3 and AAA Certificate Services roots in your system trust store.
And if you hold a certificate chaining to emSign ECC Root CA – G3, replace it before Chrome’s root removal finishes rolling out on 27 October. That deadline is not negotiable and the migration affects about 30,000 certificates.
Chrome’s root program also confirmed it found no other keys sharing this failure mode, though its statement leaves eMudhra’s remaining presence in the Chrome root store under review. The Mozilla root store policy will likely come out of this with stricter key generation ceremony requirements. Ceremonies are usually theater, cameras and printed scripts and witnesses. This time the script itself was the bug.