eMudhra: tiny private keys, a much bigger trust problem

Your browser can reject a dangerous certificate while Git, Python or an AI coding agent on the same laptop still accepts it. The eMudhra incident shows why "I updated Chrome" is not a complete response to a certificate authority failure.

On October 17, researcher Wayne reported eight recoverable private keys belonging to eMudhra intermediate certificate authorities. Mozilla independently confirmed the weakness. Six intermediates were for TLS, which protects HTTPS connections. Two were for code signing.

Now there are fresh developments. Apple's November 10 update fixes a gap affecting macOS command-line tools. And eMudhra's newly published full incident report describes both the original failure and additional RSA key-handling problems.

What actually broke

A certificate authority, or CA, signs certificates that help software check who it is connecting to. A root CA can authorize an intermediate CA to issue certificates. That intermediate's private key must remain secret and difficult to guess.

In this case, the eight affected P-384 elliptic-curve private keys were all integers below 256, according to Mozilla's investigation. A key that should have been chosen from an enormous range was reduced to a tiny set of possibilities.

The keys could be recovered from public certificates. No server break-in was needed. This was not a break of P-384 or TLS encryption.

Someone holding a compromised TLS intermediate key could create a certificate for a website they do not own. If a client still trusted that intermediate, and the attacker could redirect or intercept the connection, the client could accept the attacker's server as genuine.

That could expose credentials, API requests or downloaded code. It does not mean someone could automatically decrypt every previously recorded HTTPS connection.

A hardware security module did not save the process

The keys originated in an April 30, 2025 ceremony. eMudhra's full report says its hardware security modules generated the original keys correctly.

The failure came later. A custom Python script handled an export-and-import process intended to move keys between different vendors' devices. According to eMudhra, the script read a private value into host memory, kept only its leading byte for the elliptic-curve keys, and created new key objects from that value.

The wrong objects were then selected for certification. Similar labels helped the mistake pass unnoticed. The company also says FIPS-approved mode was disabled for the wrap-and-unwrap step.

There was an earlier warning. In 2025, some revocation lists had signatures that did not match their CA certificates. eMudhra now says staff fixed the mismatch by signing with the matching objects, without finding why two different key objects existed.

That is the uncomfortable engineering lesson: making a failing check pass is not the same as fixing the cause.

The new report also expands the scope to eight RSA intermediates. eMudhra says their key values were not truncated, but private key material passed through the Python process's memory, violating its key-transfer requirements. It reports revoking those intermediates on November 7.

Do not merge these findings into "sixteen easily guessed keys." Eight recoverable elliptic-curve keys and eight improperly handled RSA keys are different findings. The script explanation is eMudhra's account; community reviewers are still asking for supporting code and records.

Revoked does not always mean rejected

The community incident site says Firefox and Chrome blocked the compromised certificates on October 17, Microsoft platforms on October 20, and Apple products on October 22.

Those protections do not cover every program equally. Browsers can receive emergency certificate blocklists. Other clients may carry a static collection of trusted roots and never receive the same revocation information.

Apple is a useful example. Safari was protected, while Apple-supplied Git, curl and Python still accepted the compromised chains. The November 10 update identifies macOS 27.2.1, 26.7.3 and 15.8.3 as fixing that developer-tools issue. Apple's guidance now tells users to update macOS.

There is another near-term deadline. In its November 11 update, Microsoft says removal of remaining eMudhra roots begins November 16, with timing varying by product. That is a further trust-policy change, not the date when protection against the original eight keys begins.

No known abuse is not proof of no exposure

The original weak intermediates had not issued legitimate end-user certificates, according to eMudhra. That does not make them harmless: an attacker could issue their own.

The incident site reports no Certificate Transparency entries for these intermediates before disclosure. CT requires certificates to be publicly logged. This is an important protection for browsers that enforce it.

Many command-line tools and libraries do not enforce CT. An attacker targeting those clients would not need to publish the forged certificate in a CT log. The site therefore says exploitation against such clients is unknown.

Keep the distinction clear: key recovery is confirmed; malicious use before disclosure has not been established by these sources.

Why AI teams should care

This was not an AI model vulnerability. But AI agents depend on the same network trust as other software.

Consider a coding agent that clones a repository, downloads a package and calls a model API. Those steps may use Git, a package manager and a Python or Node.js runtime, each with a different certificate-verification path.

A safe browser result says nothing about those paths. A sandbox also does not tell a client whether the remote server is genuine.

Cloudflare's response makes the practical point: look beneath the SDK. Update the verifier, trust bundle, runtime or base image actually used. Rebuild and redeploy where needed.

Check the connection your application really uses

The incident site provides public test endpoints, including chains without CT logging:

curl --connect-timeout 10 --max-time 15 https://dv-g3b-noct-emudhra.we-have-a-problem.com/
curl --connect-timeout 10 --max-time 15 https://dv-g3b-aaa-noct-emudhra.we-have-a-problem.com/

These test two trust paths, not every affected chain. Use them without credentials. A completed HTTPS connection means that tested path still accepts the compromised chain. A certificate-validation error means it rejects that chain. A timeout or DNS error proves neither.

A TLS-inspecting proxy changes what is being tested: acceptance may come from the proxy, not the local client.

Repeat checks inside the real container, CI runner or application environment. Use the incident site's broader checks for other chains and Git. Update bundled trust stores and applications separately when necessary. Never "fix" the resulting errors by disabling certificate verification.

The useful question is not whether the laptop is updated. It is whether every client that handles your code, secrets and AI requests now rejects the compromised trust paths.

Sources

• Community incident summary, checks and patch tracker
• Mozilla investigation: weak P-384 keys
• eMudhra full incident report and expanded RSA scope
• eMudhra's public statement and customer transition updates
• macOS developer-tools findings and November 10 fix
• Apple guidance on the compromised intermediate CAs
• Microsoft response, updated November 11, 2026
• Cloudflare response and developer guidance

Hero photo: Small padlock with three keys in Holma Marina, by W.carter (Ann-Sophie Qvarnström), August 15, 2021. Licensed under CC BY-SA 4.0. Resized from 4629 x 3086 to 1920 x 1280 pixels and JPEG-compressed; the adapted image is shared under the same license. This archival photograph illustrates keys and trust. It does not show eMudhra equipment or evidence of the incident. No endorsement is implied.