One of eMudhra's CA Private Keys Was the Number 4. Browsers Blocked It Within Days. Our Own Mac's curl Still Trusted It.
Test every TLS client you run against the four public test hosts listed below, today. Browsers are already protected. Our production containers were too. But on the laptop we run this company from, the built-in curl and the built-in Python both connected without a warning to sites whose certificates were signed with keys anyone can work out in 256 guesses.
What happened
eMudhra is an Indian certificate authority whose roots are trusted by Mozilla, Google, Microsoft and Apple. In April 2025 it created eight intermediate CA certificates. Six were for TLS and two were for code signing, trusted by Microsoft. Each one is supposed to hold a 384-bit elliptic-curve private key, a number too large to guess.
They didn't. The eight private keys were 4, 56, 66, 115, 155, 156, 230 and 237. Anyone who tried the first 256 numbers against the public certificates could recover all eight, and with them sign a certificate for any website. BleepingComputer verified that a published key matches one of the revoked certificates. eMudhra's explanation, as reported, is that a faulty step produced a second set of weak keys with labels similar to the real ones, and the weak set was picked for signing.
A researcher identified as Wayne found the problem on October 17 while scanning public certificate data. He signed a test message with each key and sent the proof to the browser root programs. Chrome pushed a block within hours, and Firefox blocked the same day. eMudhra revoked all eight on October 19. Microsoft followed on October 20 and Apple on October 22. Oracle shipped an out-of-band Java fix on October 21 as CVE-2026-91403, rated 9.1, and Go shipped CVE-2026-111943.
eMudhra says most of the certificates were never used in production and it found no certificates issued to customers from them. The public tracking site reports no Certificate Transparency entries for these intermediates since April 2025. No misissued certificates or attacks have been reported. The Mozilla bug, 2083449, is still asking whether the keys came from the hardware security module's certified generator at all.
Why "patched" is the wrong word for your fleet
Oracle's advisory reads like a TLS library bug. It isn't one. The fix in Java, Go, Node and the browsers is the same: stop trusting eight specific certificates. That only protects software that received the update or checks revocation. A great deal of software does neither. Command-line tools, language runtimes with their own certificate bundles, appliances and embedded devices tend to trust whatever chains to a root in their store, and the two roots involved stayed in many stores.
So we tested our own. A tracking site run for this incident publishes test hosts whose certificates are signed with the recovered keys, two of them with chains that were never logged to Certificate Transparency. A client that connects successfully would trust a forged certificate from anyone holding these keys, which is everyone.
Node.js 22.23.4, the runtime in our production base image, refused all four with CERT_REVOKED. So did Node.js 26.12.1.
curl inside our production image, on Debian 12, refused them.
The macOS 26.6.2 system curl on our operator workstation returned HTTP 200 for all four, including both chains with no Certificate Transparency record.
The macOS system Python 3.9.6 on the same machine also accepted all four.
The browsers on that same laptop were protected. The tools an engineer or a script uses from the terminal were not. A macOS update, 26.7.1, is pending on that machine; we have not yet confirmed whether it changes the result, and we will retest after applying it.
The code-signing half
Two of the eight were code-signing intermediates trusted by Microsoft, and that half has had less attention. A recovered code-signing key lets anyone sign a Windows binary that chains to a trusted root. Microsoft's block landed on October 20. Any binary signed under these intermediates is not evidence of anything, whatever its signing date says. If your allow-listing or EDR policy trusts signers by chain, check that it picked up Microsoft's change.
What to do
Test from each kind of client you run, not just a browser. Connect to dv-g3b-emudhra.we-have-a-problem.com, dv-g3b-aaa-emudhra.we-have-a-problem.com, dv-g3b-noct-emudhra.we-have-a-problem.com and dv-g3b-aaa-noct-emudhra.we-have-a-problem.com. A certificate error is the good result. A page that loads means that client would trust a forged certificate.
Update Java to the October 21 release and Go to the release carrying CVE-2026-111943. On Debian and Ubuntu, resync the Java trust store after updating ca-certificates, because the two can drift.
On macOS, apply system updates and follow the tracking site's macOS steps for the command-line trust file. The built-in pip uses its own outdated roots.
On Windows, the tracking site offers a PowerShell script that puts the compromised intermediates and their cross-signs in the Untrusted store. Read it before you run it, and on managed machines ask whoever runs your fleet.
Look for anything that bundles its own CA list: containers built from old base images, Python virtual environments, appliances, IoT. They need their own update.
There are no network indicators to block here; the risk is in what your software trusts, not in an address. Credit to Wayne for the find and the clean proof, to the tracking site for the test hosts, and to the root programs for moving within hours.
If this was useful, or if it wasn't, the rating widget below takes ten seconds and is the only way we know.
Every indicator in this post is in the feed. Free.
1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.
Was this useful? Thirty seconds, no cookies, no tracking, no third parties, your address hashed and never stored. If the box below does not load, the same question lives at https://analytics.dugganusa.com/nps.html?post=one-of-emudhra-s-ca-private-keys-was-the-number-4-browsers-blocked-it-within-days-our-own-mac-s-cu
Comments