Microsoft ships OOB updates to distrust eMudhra CA certificates

Microsoft released out-of-band updates on October 26 to pull trust in certificates tied to compromised eMudhra certificate-authority keys. The target is systems that don't receive automatic Certificate Trust List (CTL) updates — air-gapped machines, hosts that can't reach Microsoft's certificate-update service, and endpoints where CTL auto-update is disabled. The primary source is the MSRC advisory; BleepingComputer has the operational detail.

What the update does

The OOB packages remove seven certificates from the Windows trust list — six eMudhra G3 roots and one AAA Certificate Services cross-sign — and withdraw trust in the eMudhra root certificates used to validate anything the CA issued. The same seven were slated to leave the Edge trust list on October 27.

• KB5134133 — Windows 11 24H2, 25H2, and 26H2.
• KB5134125 — Windows 10 21H2 and 22H2.

Connected machines already got this through the Disallowed CTL and a CRLSet update for Edge and WebView2; Microsoft had earlier blocked the eight intermediates (six TLS, two code-signing) that way. The OOB updates exist for the systems that CTL servicing never reaches.

Why

Eight eMudhra intermediate CA private keys generated in April 2025 were cryptographically weak — each had a value below 256, so the private key could be recovered by testing 256 candidates. With a recovered key, an attacker could forge certificates for legitimate sites and intercept TLS traffic. A researcher surfaced the flaw running a check against the Common CA Database around October 17; Mozilla made it public on October 20, and Mozilla, Google, Apple, and Microsoft all blocked the affected certificates. eMudhra revoked the eight intermediates and says none of them issued end-user certificates and its infrastructure was not breached. Red Sift's write-up walks the recoverable-key math.

Action checklist

1. Install KB5134133 / KB5134125 on disconnected and CTL-disabled Windows hosts today. Internet-connected machines with automatic CTL updates already received the trust change; this is specifically for the fleet that doesn't.
2. Inventory certificates that chain to the removed roots. Microsoft notes these may need to be replaced — anything issued under the affected eMudhra hierarchy will stop validating once the trust change applies.
3. Re-issue affected server and client certificates from an unaffected CA before the removal breaks production TLS or code-signing checks.
4. If a specific compatibility need forces you to keep trusting one of these certificates locally, treat it as a separate, documented trust decision under your own policy — not a default to leave in place.
5. Watch for further removals. Microsoft says it is still reviewing the remaining eMudhra roots and may make additional trust changes.

Context

This is a weak-key compromise, not a stolen-key one: the private keys were derivable from public data, so every certificate under those intermediates has to be treated as forgeable. That is the harder class to reason about, because there's no breach timeline to bound exposure — the keys were recoverable from the day they were issued. The broader pattern is familiar: when a CA's keys fail, the fix is trust-store surgery pushed by every major root program at once, and the long tail is always the disconnected and unmanaged endpoints that CTL updates never touch. Those are exactly the machines these OOB packages exist to reach.