eMudhra blames a script error for CA keys that anyone can recover

• Affected: any client that still trusts eight eMudhra intermediate CAs. That means stale trust stores, old Go builds, unrebuilt Electron apps and bundled CA files.
• Fixed in: current Chrome, Firefox, Edge, Safari and Windows trust data; Go 1.27.3 and 1.26.10; Node.js 22.23.4, 24.22.1 and 26.12.1; Electron 44.9.1.
• Exploited? No known attacks. CVE-2026-111943 is not in CISA KEV (checked 27 October 2026). Public tools can recover the keys.
• Do this now: update operating systems, runtimes and CA bundles. Then rebuild containers and apps that ship their own roots.

What happened

Anyone can recover the private keys of eight eMudhra intermediate certificate authorities. Six of them could sign TLS certificates for any website, so a client that still trusts them can be fooled by a forged certificate.

A researcher reported the flaw on 17 October 2026. Browser root programs blocked the keys that day, and the incident went public on 20 October. The new fact is eMudhra's leadership note of 26 October 2026. It says plainly: "The flaw was ours. A script error resulted in issuing CA's with weak keys."

The keys date from a key generation ceremony on 30 April 2025. Mozilla says all eight are P-384 keys whose private values fall in a tiny range. Mozilla recovered them independently in under two hours, without knowing the reporter's method.

eMudhra's preliminary account, posted in Mozilla's incident bug, describes a test of key wrapping and unwrapping. A code flaw created a second, weak key pair inside the HSM. Because the labels looked alike, staff used the weak pair for the certificate requests.

eMudhra revoked all eight intermediates on 18 October, between 09:24 and 09:38 UTC. On 22 October, it said it would leave the global SSL/TLS certificate business.

Who is affected

Up-to-date browsers are protected. The risk sits with software that checks certificates against a static root list and ignores revocation. Mozilla, Apple and the disclosure site all warn about that gap.

The eight intermediates are EM DV, OV and EV TLS CA - G3B and G3C, plus EM OV CS CA - G3B and G3C for code signing. Apple says the six TLS intermediates are issued by emSign Root TLS CA - G3, which chains to emSign ECC Root CA - G3. Sectigo also cross-signed each under AAA Certificate Services.

Still exposed until updated:

• macOS command-line tools. Apple says curl, git, python3, ruby, perl and openssl read /etc/ssl/cert.pem. That file waits for a future macOS update.
• Electron apps. The disclosure site says an app is fixed only after it rebuilds on a patched Electron release. Updating the OS does not help.
• Bundled and embedded CA lists. Containers, appliances, IoT firmware, Java keystores and language packages carry their own roots. The disclosure site lists OpenJDK as still pending.
• Code signing on Windows. Microsoft says the two code-signing keys could sign content that appears to come from a trusted CA. Apple's frameworks do not trust them.

Am I affected? Ask three questions. Does the client use its own CA file? Was that file built before 20 October 2026? Does it still contain emSign ECC Root CA - G3 or AAA Certificate Services? If yes, treat it as exposed.

What is confirmed

Mozilla's incident bug lists all eight certificates with fingerprints and CCADB ids. Apple's support page lists the twelve TLS certificates it blocks. Six are eMudhra-issued and six are Sectigo cross-signs.

Google says no TLS certificate chaining to the six TLS intermediates was in Certificate Transparency before its block. Chrome requires CT for publicly trusted certificates, so a forged certificate aimed at Chrome would have had to appear there. Cloudflare says its review found no active exploitation on its services.

eMudhra says the eight intermediates issued no end-entity certificates, and seven never went into production. It also says its infrastructure was not breached.

Go calls the fix a denylist in crypto/x509. Verify now rejects chains that contain these intermediates. Go assigned CVE-2026-111943 and published GO-2026-6809. NVD lists it as awaiting analysis with no CVSS score.

Working public proof of concept exists. Mozilla says several people recovered the keys and some published them. We read four GitHub projects without running them. Three recover the real keys and sign lab certificates; one uses throwaway keys.

We do not link to those projects. The useful public tool is the disclosure site's checker, which tests whether a client still trusts the keys.

On 27 October 2026, the Chrome Root Program answered questions in Mozilla's bug. Within an hour of the report, it said, it scanned every Chrome-trusted CA certificate it knew of. That scan found no other weak CA keys.

Chrome also said standard linters had not checked for small elliptic-curve private keys before this incident. It called its block emergency containment, not the end of its work.

What is not confirmed

No vendor reports real-world misuse. That is not proof of absence. Clients that skip CT checks, such as curl, would not reveal a forged certificate to the public.

eMudhra has not published the exact code fault. It promises a full root-cause report through the CCADB process. Mozilla and Chrome asked further questions, and some answers were still pending at our check.

A community analysis in Mozilla's bug counts 107,107 certificates signed with six of the keys after disclosure. Most name google.com and look like demonstrations. We did not verify that count.

The disclosure site says Microsoft blocked the keys on 20 October and Apple on 22 October. Microsoft's own blog matches the first date. Apple's page gives 19 October, so we use Apple's date.

We could not confirm that the Chrome Root Store change has reached every Stable user. Google described it as expected on 27 October 2026, Pacific time.

What to do

1. Update browsers and operating systems, and let Windows certificate trust lists and Edge components update.
2. Upgrade Go to 1.27.3 or 1.26.10, then rebuild and redeploy Go binaries.
3. Upgrade Node.js to 22.23.4, 24.22.1 or 26.12.1. The disclosure site also lists Bun 1.4.4, Deno 2.9.8 and Python 3.14.10 and 3.13.18 as patched.
4. Ask vendors of Electron apps for a build on a patched Electron. The disclosure site lists 44.9.1, 43.8.1 and 42.11.16.
5. Refresh ca-certificates packages, certifi, Java keystores and other bundled CA lists. Rebuild container images from fresh bases.
6. Search your inventory for anything that chains to emSign ECC Root CA - G3. Replace it before root removals break it.
7. Monitor Certificate Transparency for your domains, and alert on any issuer named EM DV, OV or EV TLS CA.
8. Test each TLS client with the disclosure site's checker. On TLS 1.2 networks, Corelight's open-source Zeek package flags these intermediates.

Website owners on this root should get a new certificate from another hierarchy now. Google gave that advice for its root removal.

Our take

This is a key generation failure, not a broken algorithm. The weak keys date from April 2025. Browsers blocked them within hours because they can push revocation data. Most other software cannot.

That gap is the lesson. The same Node.js releases that fixed the Brotli bug in our Node2Shell story also block these keys. Shipping one update rarely refreshes every trust store you run.

Cloudflare's 27 October post grouped this incident with PHP2Shell as the week's two big events. One needs a code patch, the other a trust store refresh. Both need an inventory.