eMudhra CA Keys Compromised: Eight Intermediates, a Private Key Equal to 4, and What to Update

The private keys of eight eMudhra intermediate certificate authorities were weak enough to compute from their public certificates. Security researcher Scott Helme said he recovered all eight in under a second. One key was the number 4; the others were whole numbers below 256. A correctly generated P-384 key is a random 384-bit number. With these keys, anyone could have issued a certificate for any domain that browsers and operating systems would trust.

Browsers moved within hours of the October 17, 2026 report. The harder problem is everything that is not a browser: Go binaries, Python and Node.js tools, container images, CI runners, IoT devices and the AI agents and services that make HTTPS calls from them. Many do not check revocation and keep trusting the bad chain until their code or trust bundle changes. This post covers what happened, what is confirmed, and what to update.

eMudhra broke the same week as PHP2Shell. The two are unrelated, but they share a lesson: browsers update in hours, and the long tail of servers and containers does not.

TL;DR

What happened

Timeline, from The Hacker News, Mozilla's Dennis Jackson and Cloudflare:

The reporter, credited only as "Wayne," proved the problem by signing the message "We have a problem here - Wayne" with each private key. Mozilla's Dennis Jackson published the proof, test hosts and a crowdsourced list of patched packages at emudhra.we-have-a-problem.com.

The eight certificates

The six TLS intermediates were issued by emSign Root TLS CA - G3, which chains to emSign ECC Root CA - G3. Each also exists as a Sectigo cross-signed copy under the AAA Certificate Services root, which is why some fixes distrust that root too.

Root cause: confirmed versus claimed

• eMudhra: a flaw in the key wrap and unwrap step of the April 2025 ceremony produced a second, weak key set next to the intended strong keys, and the weak keys were published to the root stores. It says its HSMs are FIPS 140-2 Level 3 certified and investigation continues.
• Google: the keys were generated with too little randomness, so anyone can compute them from the public certificates. They did not need to be stolen.
• eMudhra also says: its infrastructure was not breached, its root keys and other intermediates are unaffected, only one of the eight was in production, and none issued an end-entity certificate.

Cloudflare's assessment is the plain one: "an attacker can create a forged certificate for any domain."

Who is exposed now

Browsers are fine once updated. They get revocation pushes (CRLSets, OneCRL, CRLite) and Certificate Transparency enforcement. The exposure is in software that trusts a bundled root list and does not check revocation:

• Go programs. Go uses its own verifier on many platforms. CVE-2026-111943 is fixed in Go 1.27.3 and 1.26.10, which reject any chain containing one of the eight keys. Every Go binary must be rebuilt with a fixed toolchain. Go 1.25 and older get no fix.
• Python tools on certifi. requests, httpx and many SDKs use certifi; 2026.10.19 drops emSign ECC Root CA - G3.
• Node.js. Fixed in 22.23.4, 24.22.1 and 26.12.1, according to the tracking site; The Hacker News reported a draft change still pending at its writing, so check the release notes.
• Rust (webpki-roots 1.0.10), PHP Composer (ca-bundle 1.6.0 and 1.4.16), Homebrew ca-certificates.
• Linux distribution trust stores. Ubuntu and Debian packages are on the tracking list; Fedora, Arch, Alpine and Gentoo were being tracked. Filippo Valsorda said Linux root stores are too poorly maintained for revocation to reach applications.
• macOS curl still accepted the chain at the time, because it uses a bundle Apple had not updated.
• Containers. An image carries the trust store from the day it was built. Old images keep trusting the bad chain until rebuilt.

Why AI agents and automation are in the blast radius

Most AI agent traffic is HTTPS from non-browser runtimes: Python SDKs, Node.js tools, Go binaries, agent sandboxes and MCP servers. Those are exactly the clients that do not check revocation. In practice:

• An agent calling a model API or a tool endpoint through an old trust store could be shown a forged certificate by anyone in the network path, and send prompts, files or credentials to an impersonated server.
• MCP servers and plugin installers that fetch over HTTPS could be served a malicious package from a forged host.
• Long-lived sandboxes and dev containers that agents run in are often built once and reused for months.

There is no report of this happening. The point is where to look first when you update. Cloudflare's advice applies directly: an SDK update alone "may not change the underlying policy," because verification is often delegated to a runtime or OS store, and you should test "through the application's actual TLS path." It also warns: "It's important to not resolve these errors by disabling verification." Coding agents that hit a certificate error during this week may suggest verify=False or NODE_TLS_REJECT_UNAUTHORIZED=0. Do not accept that fix.

Beam can help with that last point on developer machines. It records the commands and file changes coding agents make and flags risky patterns, so a disabled-verification flag added by an agent is visible in review. It does not inspect your trust stores or TLS traffic.

What to do: a checklist

1. Update browsers and operating systems on every device. That covers most people.
2. Rebuild Go services with Go 1.27.3 or 1.26.10 and redeploy.
3. Update language trust bundles: certifi 2026.10.19, webpki-roots 1.0.10, Composer ca-bundle 1.6.0 or 1.4.16, and the fixed Node.js releases.
4. Update OS ca-certificates on servers as your distro ships the fix.
5. Rebuild container images with --pull and redeploy, including CI runners and agent sandboxes.
6. Update Cloudflare clients if you use them: cloudflared 2026.10.2, the current Cloudflare One Client and 1.1.1.1 app.
7. Review mutual TLS trust stores and any custom CA bundles your services load.
8. Test from the real runtime:

curl https://dv-g3b-emudhra.we-have-a-problem.com/
curl https://dv-g3b-aaa-emudhra.we-have-a-problem.com/
python -c "import requests; requests.get('https://dv-g3b-emudhra.we-have-a-problem.com/')"
node -e "fetch('https://dv-g3b-emudhra.we-have-a-problem.com/').then(()=>console.log('STILL TRUSTED')).catch(e=>console.log('rejected:', e.cause?.code||e.message))"

An error on every line is the result you want.

9. If you run sites on an eMudhra certificate chaining to emSign ECC Root CA - G3, move to another CA before Chrome removes the root. eMudhra says it is issuing replacements.
10. Search code and config for disabled verification added this week: verify=False, InsecureSkipVerify, rejectUnauthorized: false, NODE_TLS_REJECT_UNAUTHORIZED.

The India angle

eMudhra is one of 14 certifying authorities licensed by India's Controller of Certifying Authorities (CCA), and Medianama notes that UIDAI's website lists eMudhra as its certificate issuer. eMudhra says its Indian DSC and eSign services run on separate infrastructure and kept working normally. Medianama reported that neither CERT-In nor the CCA had issued a public statement at the time, and that the Internet Freedom Foundation planned a representation to MeitY, the CCA and CERT-In. Pranesh Prakash called the lapse "inexplicable" but said it may reflect one error rather than a systemic problem.

For Indian organizations: the browser fix protects users, but government and enterprise systems often run old Java, Go or appliance software. Those need the same trust-store review as anywhere else. We covered a related theme in CERT-In's report on AI agents accessing Indian live systems.

What people ask

"Do I need to remove the eMudhra root myself?"

Usually not. Mozilla says no action is needed where clients reliably check revocation. Where software can block individual intermediates, block the eight. Manual root removal is an expert-only workaround while waiting for packages.

"Is TLS broken?"

No. Cloudflare notes this is a certificate authentication failure at one CA, not a weakness in TLS encryption.

"Why did browsers fix it so fast?"

They update one application and push revocation data continuously. Everything else depends on many maintainers shipping new bundles and on you rebuilding.

Related reading

• PHP2Shell and AI agents: why the attack window just collapsed
• PHP2Shell patch guide: rebuilding containers and verifying restarts
• Vibe coding security checklist
• npm supply chain worms and AI tooling
• PHP2Shell: what happened and what to do now on explainx.ai
• eMudhra explained for users, developers and India on explainx.ai

Primary sources: Mozilla incident page · Cloudflare · The Hacker News · The Register · Medianama

Package versions and vendor status are as reported October 20 to 21, 2026, and change quickly. Check the Mozilla tracking page for the current list.