Eight Stolen CA Keys: Checking Your Estate After The Intermediate Certificate Compromise

On Saturday 17 October, a researcher proved to the browser root programmes that he could sign messages with the private keys of eight intermediate certificates belonging to a commercial certificate authority (CA). Anyone holding those keys can issue a certificate for any website, and every client that trusts the chain will accept it.

Browsers moved fast. Mozilla and Google blocked the certificates the same evening, Apple followed on 19 October and Microsoft platforms on 20 October. The CA has revoked the intermediates. That covers browsers and up-to-date Windows machines. It doesn't cover the long tail of software that carries its own list of trusted roots and never checks revocation. That tail is where the work is this week.

What happened

According to the public disclosure site, the eight intermediates were created in April 2025, and their private keys were "incorrectly generated by the CA". In other words, the keys can be recovered from information that was never meant to be secret. The researcher demonstrated control by signing the same message with each key, and published the certificates and signatures so anyone can verify the claim without the keys themselves being released.

The intermediates chain to two roots: the CA's own ECC root, and a cross-signature from an older root that is trusted almost everywhere. That cross-signature is what makes this serious. It means clients that never added the CA's own root still trust the chain.

The timeline so far:

• 17 October, 20:06 UTC: Mozilla receives the report. Firefox's centralised revocation list, OneCRL, blocks the certificates within three hours, without users needing to update or restart (Mozilla). Chrome blocks them the same day.
• 19 October: Disclosure to downstream trust stores. Apple blocks the certificates.
• 20 October: Microsoft platforms block the certificates. Mozilla ships Firefox 158.0.1, ESR 115.43.1 and ESR 153.5.1, and NSS 3.131.1, which removes the signing root from Mozilla's trust store altogether.

No attacks using the keys have been reported. Misusing them also needs a position in the middle of the connection, such as a compromised network, a rogue Wi-Fi access point or DNS hijacking. But the keys can be recovered by anyone who has the certificates, so assume the capability is now widely available.

Who is still exposed

The risk sits with clients that trust the chain and don't receive or check revocation. The disclosure site lists fixed versions for the common cases:

• Python applications that use the certifi bundle, which is most of them: fixed in certifi 2026.10.19, pip 26.2.2 and uv 0.13.4.
• Go programs: fixed in Go 1.27.3 and 1.26.10, which means rebuilding the program, not just patching the server it runs on.
• Electron desktop apps: fixed in Electron 44.9.1, 43.8.1 and 42.11.16. Each app vendor has to ship its own update.
• Rust (webpki-roots 1.0.10, rustls-webpki 0.103.16), the curl CA bundle (2026-10-20), and Linux ca-certificates packages for Ubuntu, Debian, Fedora, Alpine and others.
• Node.js and Bun: fixes were still pending when we wrote this.

For a Microsoft-centric estate, that translates into a few concrete places to look: Windows machines where automatic certificate updates are switched off, line-of-business tools written in Python, Go or Node.js, Electron-based desktop apps, Linux servers and containers in Azure, and any proxy or appliance that does TLS inspection with its own trust store.

Checking Windows

Windows receives certificate distrust updates automatically through its certificate trust list updates, unless policy has turned them off. Machines most likely to have missed the 20 October update are those where the Turn off Automatic Root Certificates Update policy is enabled, which is common on air-gapped networks, OT environments and some hardened server builds. For those, follow Microsoft's documented process for distributing trust list updates in disconnected environments, and confirm the change has landed.

You can test any client, Windows or otherwise, against the two test endpoints on the disclosure site. A certificate error means the client is protected. A page that loads means it still trusts the compromised chain.

Hunting in Defender and Sentinel

These queries use Microsoft Defender XDR advanced hunting tables, also available in Sentinel through the Defender XDR connector. Treat them as starting points to tune. The CA's certificates carry the "emSign" name in their issuer fields, which is what the first query keys on.

1. Certificates from the affected CA in your device inventory

Defender Vulnerability Management keeps an inventory of certificates installed on onboarded devices. Anything issued by the CA deserves a look, and a client or server certificate issued under one of the eight intermediates should be replaced.

DeviceTvmCertificateInfo
| where IssuedBy has "emSign" or IssuedTo has "emSign"
| join kind=leftouter (DeviceInfo
    | summarize arg_max(Timestamp, DeviceName) by DeviceId) on DeviceId
| project DeviceName, IssuedTo, IssuedBy, Thumbprint, Path,
          IssueDate, ExpirationDate, SerialNumber

2. Software that brings its own trust store

This is a rough first pass at finding runtimes and apps that may need updating. Adjust the names to match how your software inventory records them.

DeviceTvmSoftwareInventory
| where SoftwareName has_any ("python", "node.js", "nodejs", "electron", "go_programming")
| summarize Devices = dcount(DeviceId), Versions = make_set(SoftwareVersion, 20)
          by SoftwareVendor, SoftwareName
| order by Devices desc

3. Machines with automatic root updates turned off

This only shows changes made while Defender was watching, so pair it with a review of your Group Policy and Intune configuration.

DeviceRegistryEvents
| where RegistryKey has @"Policies\Microsoft\SystemCertificates\AuthRoot"
| where RegistryValueName in~ ("DisableRootAutoUpdate", "EnableDisallowedCertAutoUpdate")
| summarize arg_max(Timestamp, RegistryValueData, ActionType) by DeviceName, RegistryValueName

What to do now

1. Make sure Windows and browsers are current, and that automatic certificate trust updates aren't disabled anywhere without a replacement process.
2. Update language runtimes and rebuild. Python, Go and Rust programs need updated packages and, for Go and Rust, a rebuild and redeploy. Container images need rebuilding with updated base layers.
3. Chase vendors of Electron and Node.js apps for updates, and track Node.js and Bun until their fixes ship.
4. Check TLS inspection proxies and appliances that keep their own trust stores. Ask the vendor when the distrust will be included, and add it manually if they support that.
5. Replace any certificates you hold that were issued under the affected intermediates. The CA has revoked them, so they'll start failing anyway.
6. Use the test endpoints to confirm each class of client now rejects the chain.

We wrote about a related problem last week, where attackers obtained valid certificates for real brands after hijacking country-code domains. See Rogue Certificates For Real Brands. Both cases show that "the padlock is there" tells you less than people assume.

How a managed SOC helps

• Inventory turned into a to-do list. Queries like the ones above only help if someone runs them across every tenant and follows up. Our SOCs are manned 24/7, with senior analysts and incident responders on shift around the clock, so new research becomes a hunt across your estate the same day.
• Interception shows up elsewhere. A forged certificate needs a man-in-the-middle position, and getting one leaves traces: rogue DNS changes, new network devices and unusual sign-ins. CYBERSHIELD AI's Investigation Agent works each alert to a verdict in an average of 3m 30s, or 7m 50s where Advanced Investigation is needed.
• Patching that covers more than Windows. Runtimes, containers and appliances are where this fix will be missed, and they're part of our vulnerability and patch management service.

If you're not sure which of your systems carry their own trust stores, talk to our team.