eMudhra Intermediate CA Keys Compromised: What Defenders Must Update

What has been reported

Simon Willison flagged an incident tracker reporting that the private keys of eight eMudhra intermediate CA certificates have been compromised. The tracker is hosted at emudhra.we-have-a-problem.com. The affected intermediates chain to roots trusted by the Mozilla, Microsoft, Apple and Chrome root programs, and by many downstream trust stores. Willison called it "very, very bad news".

The material we reviewed does not say how the compromise was discovered. It also does not say whether the keys have been used to issue certificates in the wild. We have left both questions open rather than guess.

Why an intermediate CA key compromise matters

A certificate authority's intermediate key signs the leaf certificates that browsers and clients validate. Whoever holds that key can, in principle, sign certificates that validate as legitimate for any hostname the intermediate is technically permitted to cover. That is why the root programs treat private-key exposure as a distrust-level event rather than a routine revocation.

The practical difficulty is distribution. Revoking the intermediates is only effective once every client that trusts them has been updated. The reported exposure is therefore wider than browsers. It covers any software that ships a bundled list of trusted certificates.

What to update

• Linux distributions: update the ca-certificates package as your distribution releases it.
• Python tooling: updated certificate lists have shipped in uv 0.13.4, pip 26.2.2 and certifi 2026.10.19.
• Anything else that bundles roots: the tracker's authors are following software updates through a GitHub repository. Check it for your stack.

A practical checklist for security teams

1. 1Inventory the places that carry their own trust store: container base images, language runtimes and virtualenvs, CI runners, mobile apps with bundled roots, and embedded or appliance firmware.
2. 2Rebuild and redeploy images that pin an old ca-certificates or certifi version. Patching the host does not fix a container with its own copy.
3. 3Check whether any of your own systems pin or explicitly trust eMudhra-issued certificates, and plan their replacement.
4. 4Review TLS-inspection and egress monitoring for certificates issued under the affected intermediates. Treat any unexpected one as a lead for incident response.

The wider lesson

Trust stores are a dependency like any other, and they are often pinned in places nobody is watching. A distrust event exposes how many copies of that dependency an organisation actually runs, and how quickly it can rebuild and redeploy them. Teams that already track certifi-style packages in their software bill of materials will move faster than teams that treat certificates as an operating-system concern.