Botched key ceremony leaves eMudhra CAs open to forgery

Published

Eight intermediate certificate authorities run by eMudhra were issued private keys so weak that recovering them is trivial, and anyone holding one could impersonate any website or service. Cisco Talos reports that instead of carrying the pseudo-random strength the keys were meant to have, several of them evaluated to single-digit and double-digit integers.

The browsers have already moved. Talos says the six TLS intermediates, trusted by Chrome, Mozilla and Apple, have been blocked by those vendors, and Microsoft has blocked the two used for code signing. eMudhra has revoked the certificates and stopped issuing new ones under its G3 root. The harder problem is everything that is not a browser.

One step in a key ceremony went wrong

According to Talos, the flaw dates to an April 30, 2025 key generation ceremony for 24 subordinate CAs under eMudhra's emSign Root TLS CA G3, which is cross-signed by Comodo AAA Certificate Services. A flaw in eMudhra's process created a second set of weak P-384 keys during a wrap and unwrap step, and those keys were mistakenly used for eight intermediate certificates. Per Mozilla's bug report, they are the EV, OV and DV TLS CAs in the G3B (eMudhra BV) and G3C (eMudhra Inc) families, plus the OV code-signing CAs G3B and G3C issued under emSign Root CS CA G3. Talos had seen no malicious use of them as of 14:00 UTC on October 21.

Why patched browsers are not the end of it

An attacker with one of these keys could issue certificates that clients accept, then impersonate a server and read or modify intercepted traffic, provided the client still trusts the key and nothing else blocks it. Revocation, key distrust, certificate transparency enforcement and pinning can all stop or expose that. But Talos warns that many programs check certificates without consulting revocation lists, and names VPNs as a clear example that will likely need software updates. Proxies, load balancers, gateways, CI/CD runners and package managers, and embedded or industrial devices with their own CA stores are all on its list to assess. A forged TLS certificate would not, by itself, defeat separate package integrity checks such as lockfile hashes or signatures.

The Go team went further and treated the certificates as a vulnerability in its own right, because Go implements its own chain verification in crypto/x509 and some platforms and static containers rely on embedded root pools that ignore revocation. It assigned CVE-2026-111943 and released Go 1.27.3 and 1.26.10, which reject chains containing the public keys of all eight intermediates. Talos says the move targets the wider cloud-native ecosystem, including Docker, Kubernetes, Terraform and Prometheus.

Update Go to 1.27.3 or 1.26.10, then refresh trust stores

Fingerprints of the eight intermediates (SHA-256)

Certificate trust is delegated down a chain, so one faulty step in one ceremony was enough to undermine eight intermediates at once. Unlike malware that plants its own fake root CA, nothing here had to be installed on a victim's machine. The browsers have closed their door; the devices and tools that never check revocation are where this will linger.

This briefing is provided by IntelFusions for informational and defensive purposes only. It is based on sources assessed to be reliable at the time of writing, and analytic judgments carry the confidence levels indicated. Indicators of compromise are defanged; re-arm them only in controlled environments. IntelFusions is not affiliated with the organizations named and makes no warranty as to completeness or accuracy.

Read the full analysis on IntelFusions