Skip to content
Security & Trust

eMudhra CA key leak: browsers are blocked, bundled trust lists may not be

Endor Labs says two popular HTTP libraries carry old root lists that no operating system patch will change

W
WebPulse Newsroom
AI-assisted · 4 min read
Share on X LinkedIn
eMudhra CA key leak: browsers are blocked, bundled trust lists may not be

AI-generated image for WebPulse. About our images

In brief
  • Endor Labs reports that eight eMudhra intermediate CA keys were compromised. Browsers block them, but many non-browser clients rely only on their own trust store.
  • Endor Labs found two widely used HTTP libraries that bundle a root trusting the compromised chains. Neither is on any fixed-software list.
  • Patch the known components, then search your code and images for bundled certificate files and test clients from their real environments.

A trust decision from 2015 can still run in 2026

Every secure connection starts with a list of authorities that software agrees to believe. Most teams assume the operating system owns that list. Often it is a copy, and copies age.

Endor Labs examined a Ruby web client library. Inside it sits a file of 153 certificates, copied from a Mozilla list dated October 28, 2015. The library loads that file unless the application's code says otherwise. A system update does not touch it. The application keeps trusting a list from 2015.

That turns a routine certificate incident into a question about inventory. You cannot patch a trust list you did not know you had.

What happened

Endor Labs says the private keys of eight eMudhra intermediate certificates were exposed, with the disclosure dated October 20, 2026. An intermediate is a certificate authority that a trusted root has allowed to issue certificates. Six of the eight issue web (TLS) certificates.

The cause is a flaw in how the keys were made. Anyone can work out the private key from the public certificate. Endor says all eight were created in April 2025.

The practical danger is impersonation. A party that holds any one of the six web-issuing keys could mint a certificate for whatever hostname it likes, and affected clients would accept it.

Four root programs run by Mozilla, Microsoft, Apple and Chrome trust roots that these intermediates connect to. Some links are direct. Others run through cross-signatures from Sectigo. On October 17, the root programs received proof of the leak. It was a message signed with each intermediate's private key.

Why browsers are covered and servers may not be

Endor lists when browser makers acted. Firefox and Chrome blocked the intermediates on October 17. Apple followed on October 19 and Microsoft on October 20. The CA has also revoked them.

Browsers have one more defence. They reject certificates that lack a certificate transparency proof, which is a record in a public log of issued certificates.

Most other software skips these checks. Endor says such a client builds the chain, looks at the root on top, and connects if that root is in its own list. That covers API clients, webhooks, package managers, CI jobs and agents.

These clients often carry credentials. If an attacker poses as the server, it receives whatever the client sends. For these clients, the trust list is the only control.

The copies nobody listed

Endor points to one root above all: AAA Certificate Services, an older Sectigo root. Mozilla and Chrome have dropped it. Frozen copies of older root lists still hold it.

A bundle that contains it also trusts the bad chains. The link is Sectigo's cross-signed certificates.

Endor checked two popular HTTP client libraries. Both still carry that root. Neither shows up on a published list of fixed software.

The first is a Python library with a 71-certificate store inside the package. It uses that file when certifi is not installed. Certifi is a separate certificate bundle package. A slim container image or a trimmed function package can stay exposed after every other update.

Two libraries are a small sample. Endor says its search across ecosystems continues. It also says it has no view into trust lists on servers, network devices, IoT devices or outside SaaS tools.

Java needs its own check. The JDK keeps a separate keystore of trusted certificates, and Endor's fixed list leaves it out. Treat Java services as unconfirmed until the JDK vendor ships an update.

What to ask your teams

The lesson here is that a patch list covers what you chose to install. It misses what your software brought along. Endor Labs sells scanning tools, so weigh its framing with that in mind. Its manual steps work without them.

First, have base images been rebuilt from patched ca-certificates packages? Updating a host today does nothing for a container image that was built last month, Endor notes. Is certifi pinned at 2026.10.19 or later wherever Python runs?

Second, can anyone search source trees, environments and images for PEM certificate files? Compare each certificate's SHA-256 fingerprint with the affected roots. Endor says fingerprints catch bundles under any filename.

Third, has each important client been tested from its real environment? Endor's disclosure site runs test hosts that serve certificates from the bad chains. If a client throws an error, it is refusing them. If the connection succeeds, the client still trusts the compromised chains.

Fourth, the keys could be recovered from April 2025. Have proxy and endpoint logs been checked for certificates from the eight intermediates? Start with clients that carry credentials.

Last, do not delete roots by hand. Endor warns that removing AAA Certificate Services can break legitimate connections that use older Sectigo chains. Swapping an outdated bundle for a current one is safer.

Trust is a list, and every list needs an owner. The risk sits where nobody has been named.

Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Endor Labs.

Follow this story: every update on eMudhra certificate compromise