eMudhra Intermediate CA Key Compromise: What Breaks and What to Update

TL;DR - The private keys of eight eMudhra intermediate CA certificates have been compromised. Cloudflare reports the keys are weak; the original reporter proved control by signing a test message with each one. - Anyone holding those keys could issue a certificate for any domain and impersonate it to clients that still trust the intermediates. - Browsers are already protected: Chrome and Firefox blocked the intermediates on October 17, Apple on October 19 and Microsoft on October 20. - Non-browser software is the gap. Update language runtimes, CA bundles, container images and any custom trust store, then verify through each application’s real TLS path. - Never “fix” new certificate errors by disabling verification.

What happened#

On October 17, 2026, a researcher reported to the browser root programs that they held the private keys for eight eMudhra intermediate certificate authorities, and proved it by signing a message with each key. The disclosure site maintained by Mozilla’s Dennis Jackson publishes the proof bundle and the list of affected certificates.

Cloudflare says it learned of the compromise around 17:00 UTC on October 19, patched its own clients and services ahead of public disclosure, and published its write-up on October 20. Cloudflare attributes the problem to the keys themselves being weak, and says its review found no active exploitation on its services.

The intermediates chain to roots that are trusted by the Mozilla, Microsoft, Apple and Chrome root programs and by many downstream trust stores. eMudhra has revoked the intermediates, but revocation only helps clients that actually check revocation, and most non-browser software does not.

This is a certificate authentication problem, not a break in TLS encryption algorithms. The danger is impersonation: a forged but “valid-looking” certificate lets an attacker in a network position read or alter traffic for the targeted domain.

Which certificates are affected#

Each intermediate exists twice: an original issued by an emSign root, and a Sectigo cross-sign that shares the same public key. Blocking by SPKI (public key) hash covers both copies.

The Sectigo cross-signs chain to Sectigo’s “AAA Certificate Services” root. Full fingerprints, serial numbers and CCADB record IDs are in the published affected-certificates.json; use that file, not this table, for any automated blocklist.

Two of the eight are code-signing CAs. If your environment trusts code signed under emSign’s code-signing hierarchy, treat signatures chaining through those two intermediates as untrustworthy until your platform’s trust store is updated.

Are you affected?#

You are most likely protected already if you only use an up-to-date Chrome, Firefox, Safari or Edge. Browsers distribute revocation data through mechanisms such as Chrome CRLSets and Mozilla OneCRL/CRLite, which is why they could react within hours.

You need to act if any of the following apply:

What to update: patched packages#

The disclosure site tracks package status. As of October 20, 2026:

Some of these arrive as indirect dependencies, so check the dependency tree, not just your top-level manifest. After updating, rebuild images and reload, restart or redeploy the services; a patched file on disk does nothing for a process that loaded the old bundle at startup.

Cloudflare products

If you use Cloudflare, its advisory lists specific minimum versions:

• Cloudflare One Client / WARP: Windows, macOS and Linux 2026.8.2115.0; Android 2.5.6; iOS 1.12.16.
• 1.1.1.1 app: desktop 2026.8.2115.0; Android 6.38.10; iOS 6.31.7.
• Cloudflare Tunnel (cloudflared): 2026.10.2; redeploy container images.
• Origin TLS in Full (strict) or Strict mode: review origin certificates; Cloudflare says Automatic SSL/TLS will notify customers still using the distrusted certificates.
• mTLS: review uploaded CAs used to verify client certificates.
• Cloudflare Containers and Sandboxes: update images, or enable HTTPS egress interception so certificate validation moves to Cloudflare-managed infrastructure.

Gateway customers on an up-to-date client are covered automatically, according to Cloudflare.

How to check what your application actually trusts#

Cloudflare’s developer guidance is the most important line in this incident: a passing browser test does not prove a background service is protected, and neither does a curl test if the application uses a different verifier. Test the path the application really uses.

Check versions of the common bundled stores:

# Python: certifi must be 2026.10.19 or later
python -c "import certifi; print(certifi.__version__)"

# Go: toolchain must be 1.27.3 / 1.26.10 or later
go version

# Rust: look for webpki-roots / webpki-root-certs in the lockfile
grep -A1 'name = "webpki-root' Cargo.lock

Find whether your own endpoints serve certificates from the affected intermediates:

# Prints the issuer of the leaf certificate a host presents
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -issuer
# An issuer CN of "EM EV/OV/DV TLS CA - G3B" or "- G3C" means that certificate needs replacing

For each application, the disclosure site at emudhra.we-have-a-problem.com runs a live browser check and documents how to test non-browser clients. Run the non-browser test from inside the application’s own runtime or container, not from your laptop.

What defenders should do now#

1. Inventory TLS verifiers, not just apps. List every runtime, HTTP library, base image and bundled CA file in production. This is the step most teams skip.
2. Update patched components from the table above, prioritizing services that call third-party APIs, payment processors, identity providers and internal service meshes.
3. Rebuild and redeploy container images, then restart long-running processes so they load the new trust data.
4. Track the pending items. Node.js and Composer ca-bundle fixes were still pending on October 20; watch those projects and redeploy when they ship.
5. Replace any certificates you hold that were issued under the affected intermediates, using a different CA.
6. Review mTLS trust stores and remove the affected intermediates from any uploaded CA lists.
7. Do not disable verification to clear the new certificate errors that patching may surface. Investigate each one; the error is the protection working.
8. Watch the trust-store thread on Mozilla’s dev-security-policy forum for guidance aimed at trust store operators.

Why this matters beyond eMudhra#

Browsers recovered quickly because they can push revocation data to every install within hours. Most other software treats its trust store as a static file that only changes when someone ships an update. Cloudflare’s write-up points to efforts such as Ubuntu’s upki project, which aim to give operating systems the same ability to push revocations and certificate transparency data quickly. Until that is common, every WebPKI incident will leave a long tail of servers, SDKs and appliances trusting certificates the browsers stopped trusting days earlier.

For security teams, the practical lesson is to know where certificate verification happens in your stack before the next incident, because that inventory is what determines whether remediation takes hours or weeks.

Related reading: PKI explained, What is an intermediate certificate authority?, What is a trust store?, Mutual TLS FAQ and certificate lifecycle management.

This advisory is informational. Confirm versions and actions against vendor guidance for your own environment.

Sources

• Cloudflare, 8 eMudhra certificates are compromised. Here’s what you need to know (October 20, 2026)
• eMudhra Intermediate CA Compromise disclosure and test site, published by Dennis Jackson (October 20, 2026)
• Affected certificates list (JSON)
• Mozilla dev-security-policy, trust store operator thread