eMudhra Certificate Authority Key Compromise

01Am I affected?

Your browsers and phones are already protected if they take automatic updates. The exposure sits in software that keeps its own list of trusted certificate authorities and does not check revocation: servers, container images, language runtimes, build pipelines and network appliances.

Test a system in one command

The researcher runs a site signed by one of the compromised intermediates. Run this from any server, container or laptop:

curl -sI https://dv-g3b-emudhra.we-have-a-problem.com

• A certificate error means the system no longer trusts the compromised authority.
• A normal response means it still does.

Test with the runtime your application actually uses. Python, Node.js and Java can each use a different trust list from the operating system, so a clean curl result on the host does not clear the application running on it.

02What to do

1. Update ca-certificates and rebuild. Update the package on servers and in every base image, then rebuild and redeploy. Updating a running container does not fix the image it came from.
2. Update runtimes that bundle their own list. Use the versions in the table below. A lock file that pins an older certifi keeps the old list through every rebuild.
3. Fix developer Macs. Run brew upgrade ca-certificates, then follow the researcher’s incident page to remove the affected roots from the macOS file that the built-in curl, git and python3 read.
4. Check appliance vendors. Look for advisories on any proxy, gateway or VPN that inspects or validates TLS.
5. Check what you bought from eMudhra. If any of your sites or signed software use an emSign certificate, confirm the issuing authority and replace it if it is one of the eight. Chrome removes the emSign ECC Root CA G3 on October 27.

Fixed versions

If you cannot do everything this week

Order the work by what the system talks to. Start with services that call payment processors, identity providers and partner APIs, because those are the connections where a forged certificate would hand an attacker credentials or money. Build and deploy pipelines come next, since they pull code over TLS and push to production. Internal-only services can follow in the next normal patch cycle.

03What happened

Every HTTPS connection rests on a chain of signatures. A root authority your system trusts signs an intermediate authority, the intermediate signs a website’s certificate, and your browser or server checks each signature up the chain. The intermediate’s private key is the only thing that makes its signature mean anything.

A private key for this kind of certificate authority should be a random number about 116 digits long. Each of these eight was a whole number below 256, and one of them was 4. Finding a key like that takes at most 255 guesses, which a laptop does in well under a second.

According to eMudhra’s account in the public Mozilla bug, the weak keys came from a chain of ordinary mistakes during a single key ceremony, and none of them was caught for a year and a half.

Six of the eight issue website (TLS) certificates and two issue code-signing certificates. Only one was in production, and it had issued no certificates to customers. Sectigo revoked its cross-signatures on October 19.

04Why it matters

With one of these keys, an attacker can issue a certificate for your bank, your identity provider or your own API, and any system that still trusts the authority will accept it. To use a forged website certificate, the attacker also has to sit in the network path.

Two things reduce the risk. No exploitation has been reported, and Google reports that no website certificate chaining to the six TLS authorities appeared in public Certificate Transparency logs before the block. Most server software does not check those logs, though, so that protection does not extend to your backend.

05Compliance notes

The issue went undetected for about 18 months, through two independent audit cycles.

eMudhra incident statement, October 2026

An audit samples whether a process was followed and documented; it does not test every artifact the process produced. Your own auditors will not ask about eMudhra by name. They will ask how you learned about a critical third-party vulnerability, how fast you assessed it, and what evidence shows it was closed. Under ISO 27001 that touches threat intelligence (A.5.7), use of cryptography (A.8.24) and management of technical vulnerabilities (A.8.8). Under SOC 2 it is CC7.1, with the change records under CC8.1.

• Open an incident ticket, even with no sign of impact.
• Record which systems you tested and the result for each.
• Record the image rebuilds and version bumps as changes.
• Close it with a re-test, not an assertion.

Done that way, this incident becomes a dated record of detection, investigation, remediation and close-out against a real external event, and a ready-made tabletop exercise if your incident response plan has not been tested this year. For the longer-term lesson, see Your Audit Passed. You’re Still Screwed. and Vendors Are Your Attack Surface.

06Timeline

07References

• eMudhra Intermediate CA Compromise: incident page, fixed versions and test sites (Incident researcher)
• Protecting Firefox users following the compromise of eMudhra intermediate certificates (Mozilla)
• Protecting Chrome and Android users from compromised eMudhra intermediate CA certificates (Google)
• Bug 2083449: eMudhra intermediate CA key compromise (Mozilla Bugzilla)
• Certificate security incident statement (eMudhra)
• The eMudhra certificate compromise (Cloudflare)
• USN-8944-1: ca-certificates update (Ubuntu)
• Go security release announcement (Go project)
• Node.js releases (Node.js)

Revision history