On 17 October 2026, eight intermediate certificate authorities operated by eMudhra were reported compromised. Six were TLS intermediates, two were code signing. By 20 October, Mozilla, Google, Apple and Microsoft had all blocked them. What deserves attention is not the speed of the revocation, which was good. It is that a substantial population of software never checks the lists those vendors publish.

How the keys failed

The intermediates were generated in a certificate authority ceremony on 30 April 2025. The P-384 private keys produced there were effectively tiny integers rather than the 384-bit values the algorithm requires. One of them was literally the number 4. A key that small can be recovered by brute force in practical time, so every certificate issued under those intermediates has to be treated as forgeable by anyone willing to do the arithmetic.

The disclosure arrived at 20:06 UTC on 17 October. Mozilla pushed the eight certificates into OneCRL about three hours later. Chrome added them to CRLSet the same day. Apple followed on 19 October, Microsoft on 20 October, and eMudhra revoked all eight. From the trust store side that is close to a best case.

The gap: clients that do not use CRLSet or OneCRL

CRLSet and OneCRL are distribution mechanisms for browsers. Software that validates TLS with its own trust store and its own revocation strategy is not automatically covered by either.

  • curl ships its own CA bundle and consults that bundle, not a browser blocklist.

  • Python's certifi bundle is a snapshot that updates when someone publishes a release.

  • Node.js uses a bundled root store in some configurations and the system store in others.

  • Go compiles its trust policy into the binary.

  • Device firmware and industrial appliances frequently carry a root store frozen at manufacture.

A second and sharper reason makes this compromise worse for those clients than for browsers: the intermediate certificates were created without being submitted to Certificate Transparency logs. Browsers that enforce CT would have rejected certificates chained to them. A client with no CT enforcement has nothing to reject.

Downstream fixes you may already have

The open-source ecosystems moved quickly, and the fixes are version-specific rather than configuration-based.

  • Go released CVE-2026-111943 with fixes in 1.27.3 and 1.26.10. Programs compiled with an older toolchain carry the vulnerable trust behavior until they are rebuilt.

  • Rust users have RUSTSEC-2026-0382, fixed in rustls-webpki 0.103.16 and 0.104.0-alpha.8.

Cisco Talos published the disclosure on 21 October, four days after the report, which is a reasonable cadence. The published analysis is at https://emudhra.we-have-a-problem.com/, and Mozilla's account is on its security blog.

A trust store inventory that finds the risk

The action that reduces exposure is not patching a single library. It is knowing which trust stores your organisation actually depends on, because the answer is never one.

  1. 1.

    Enumerate where TLS validation happens, not where TLS is configured. A service mesh sidecar, a database driver, a package manager and a language runtime each carry their own.

  2. 2.

    For each, record where the root store comes from, when it was last updated, and whether revocation is checked at all. Many embedded clients do not check.

  3. 3.

    Prioritise everything that validates certificates for code, packages or firmware. A forged TLS certificate gets an attacker a session; a forged code signing certificate gets them execution.

  4. 4.

    Rebuild rather than reconfigure. Go binaries in particular do not pick up a new trust policy without a recompile.

  5. 5.

    Add certificate authority key strength to vendor review. The failure here was a key that was never strong enough, which makes it a process question rather than an incident response one.

What to take from this

Browsers came out of this well because the browser ecosystem built shared machinery for exactly this event. Everything else is on its own. For the next occurrence, the operative assumption is that revocation will be fast, that browsers will be covered, and that the rest of the estate will be covered only if someone did the inventory in advance.

References

  • eMudhra incident write-up: https://emudhra.we-have-a-problem.com/

  • Mozilla security blog, October 2026: https://blog.mozilla.org/security/