eMudhra: 8 Intermediate CAs Compromised, Qualys Releases Operational Detection Tools

According to an exclusive Qualys analysis, the sole primary source currently available, eight eMudhra intermediate CAs were compromised by a flaw in the key-generation process that reduced the effective entropy of P-384 keys to 3-8 bits. Qualys released QQL queries and specific QIDs on October 23, 2026 to identify compromised certificates in enterprise infrastructures.

The Key-Generation Flaw: How Nominally Secure P-384 Keys Became Weak

The compromise did not stem from an external attack but from an error in eMudhra's internal key-generation process. During a ceremony on April 30, 2025, a flaw in the wrap/unwrap step produced a second set of weak P-384 keys that were then mistakenly used for eight intermediate CA certificates.

"reduced the effective entropy of the affected P-384 keys to an estimated 3 to 8 bits, making private-key recovery trivial to compute" — Qualys Product Tech Blog

The nominal entropy for P-384 keys remains 384 bits. At 3-8 effective bits, the private key can be reconstructed with minimal computational resources, making the signing of fraudulent certificates technically trivial for anyone with access to the public key. This is the core of the risk: not the compromise of a server, but the possibility that a threat actor can issue apparently valid certificates for any domain or software.

Chrome, Mozilla, Apple, and Microsoft: Who Blocked What

Vendor responses were differentiated by certificate type. Chrome, Mozilla, and Apple blocked the six intermediate TLS CAs, preventing browsers from trusting sites served by chains containing them. Microsoft acted on the two intermediate code-signing CAs. Google specifically removed emSign ECC Root CA – G3 from the Chrome Root Store, while Mozilla revoked trust in the signing root.

eMudhra revoked the eight certificates and halted issuance under the G3 root. According to the source, the company claims only one of the eight compromised intermediates was actually used in production and that no certificates were issued to websites or end users. This claim remains unverifiable by independent sources in the available set.

Why Enterprise Trust Stores Remain the Weak Link

Blocking in consumer browsers is only half the battle. Enterprise trust stores, build systems that verify software signatures, IoT devices with static root stores, and applications compiled with unpatched Go can continue to consider certificates issued by the compromised intermediates valid. Go 1.27.3 and 1.26.10 explicitly block certificate chains containing the eight compromised keys through CVE-2026-111943, but earlier versions do not.

This creates a scenario of persistent and potentially invisible exposure: a compromised certificate can remain functional in environments that do not receive automatic root-store updates or that run legacy Go runtimes, without triggering alerts in traditional detections.

What to Do Now

Security teams must verify the presence of compromised certificates in their infrastructure with three concrete actions. First: run the QQL queries published on October 23, 2026 in Qualys Certificate View to search for TLS certificates by SHA-256 fingerprint or serial number of the eight compromised intermediates. Second: launch a scan in VMDR or Cloud Agent with QID 5019897 to identify vulnerable Go versions (pre-1.27.3/1.26.10) and QID 48395 to enumerate complete certificate chains that still present the eMudhra intermediates. Third: isolate systems running unpatched Go and plan upgrades to 1.27.3 or 1.26.10, which block chains containing the compromised keys.

The potential impact is twofold: risk of man-in-the-middle for TLS certificates still present in unpatched trust stores, and risk of execution of fraudulently signed software for code-signing certificates. The source does not specify the nature of exposed data nor provide a mandatory remediation timeline for organizations.

What Remains Unclear

Gray areas persist in the public dossier. The CVSS score is not reported in the text provided by the primary source. It is not specified whether CVE-2026-111943 and CVE-2026-111944 represent two distinct aspects of the same incident or separate technical variants: the text mentions both without clearly delimiting their scope. It is also not documented whether other security vendors have released analogous detection tools to those from Qualys.

The original discovery of the flaw is attributed to an unnamed researcher in the source. It is unclear whether Qualys developed the detection independently or in coordination with the initial disclosure.

FAQ

Did Qualys discover the vulnerability?

No. The original discovery is attributed to an unnamed researcher in the source. Qualys released detection tools and operational queries for its platform.

Are all eMudhra certificates compromised?

No. Only eight specific intermediate CAs are affected. Root CAs and other intermediates are not involved.

Has a real-world attack been confirmed?

No. eMudhra claims no fraudulent certificates were issued, but this assertion is not independently verifiable in the available source set.

Why does the risk persist after revocation?

Because static trust stores, isolated systems, and unpatched legacy Go applications can continue to consider compromised certificates valid without generating visible alerts.

Sources

• blog.qualys.com