Executive Summary
A critical certificate authority incident disclosed on October 17, 2026, impacts eight eMudhra intermediate CA certificates. A flaw in the key generation process could allow attackers to recover private keys and issue fraudulent TLS or code-signing certificates. The affected intermediates have been revoked and blocked by major platform vendors, including Chrome, Mozilla, Apple, and Microsoft. The issue is tracked as CVE-2026-111943 and CVE-2026-111944.
The eMudhra Certificate Authority Compromise
On October 17, 2026, a researcher reported recovering the private keys for eight eMudhra intermediate CA certificates after discovering that the underlying cryptographic keys contained only a fraction of the expected entropy. Browser and OS vendors have since blocked the certificates, and eMudhra has revoked them. Security teams now face an immediate question: Where do certificates issued by the compromised eMudhra intermediates exist within my environment?
Qualys VMDR and Qualys Certificate View already collect the data needed to answer that. This post explains how to use them, with QQL queries you can run today.
What is eMudhra?
eMudhra, a digital trust and cybersecurity provider, offers solutions spanning Public Key Infrastructure (PKI), digital certificates, identity management, and secure digital transactions. Recent security concerns involving eight of its intermediate Certificate Authority (CA) certificates highlight the importance of strong cryptographic key generation, rigorous validation, and continuous oversight of digital trust infrastructure. The incident reinforces a critical security lesson: trust in digital certificates depends not just on the technology, but on the operational controls protecting the keys behind them.
What Happened
A flaw in eMudhra’s key generation process produced a second set of weak P-384 keys during a wrap/unwrap step, and those weak keys were mistakenly used for eight intermediate CA certificates. This flaw reduced the effective entropy of the affected P-384 keys to an estimated 3 to 8 bits, making private-key recovery trivial to compute.
The weak keys came from a key generation ceremony held on April 30, 2025, for 24 subordinate CAs. Anyone holding the private key of one of these intermediates could issue a certificate that impersonates any website or service, subject to each client’s validation controls. Some key points about the incident:
- Six of the eight intermediates are TLS CAs; two are code-signing CAs.
- Browsers: Chrome, Mozilla, and Apple have blocked the TLS certificates, and Microsoft has blocked the two code-signing certificates.
- Root distrust: Google removed the emSign ECC Root CA – G3 from the Chrome Root Store, and Mozilla removed trust in the root that signed the intermediates.
- eMudhra: has revoked the eight certificates and stopped issuing new certificates under its G3 root. It states that its root CA private keys and other intermediate CAs are not affected, and that the issue is limited to its global website-security business, not Indian DSC and eSign services.
- Exploitation: eMudhra says only one of the affected intermediates was used in production, and none of them issued certificates to websites or end users.
Who is at Most Risk?
Organizations should prioritize investigation if they:
- Operate internet-facing websites, APIs, VPNs, or other TLS-enabled services.
- Use publicly trusted certificates issued through eMudhra or emSign trust hierarchies.
- Distribute signed software that relies on publicly trusted code-signing certificates.
- Develop or run applications built on the Go programming language.
- Maintain legacy systems, unmanaged endpoints, or custom trust stores that may not receive certificate distrust updates automatically.
The table below lists the certificates identified. The SHA-256 fingerprint and serial number are the most reliable identifiers when you search your inventory.
How Can Qualys VMDR and Certificate View Help Identify eMudhra Certificates?
Use Certificate View, included with VMDR, to identify certificates issued by affected eMudhra authorities and use VMDR with Cloud Agent to identify hosts running vulnerable Go installations or software requiring vendor-issued updates.
Step 1: Make Sure Coverage Is Complete
- Entitle Certificate View on your VMDR scan ranges. Confirm that the IP ranges you scan with VMDR are enabled in Certificate View.
- Add external domains. For sites hosted by web or app providers, add the FQDNs or IP addresses in Certificate View. It runs a lightweight scan across standard ports to detect TLS services and analyze their certificates.
- Use Cloud Agent where scans cannot reach. Agents report software and certificate data from endpoints, servers, and remote workers that network scans miss.
Step 2: Pinpoint the Eight Compromised Intermediates
To confirm whether any of the eight compromised intermediates appear in a chain, search for their SHA-256 fingerprints, serial numbers, or issuer names in Certificate View > Certificates.
Reference QQL Queries
By Issuer:
certificate:(issuer.name:[`EM EV TLS CA – G3B`, `EM OV TLS CA – G3B`, `EM DV TLS CA – G3B`, `EM EV TLS CA – G3C`, `EM OV TLS CA – G3C`, `EM DV TLS CA – G3C`, `EM OV CS CA – G3B`, `EM OV CS CA – G3C`])
By Serial Number:
certificate:(serialNumber:`c7c41efe92d825f05eae841a4a82c1` or serialNumber:`6cada367fb1c100088120ea202d568` or serialNumber:`a4aee678f23362b4c0e460b772f214` or serialNumber:`8009928a64107601af05fa2f19f109` or serialNumber:`296926c227a3a1526392b19482a504` or serialNumber:`588b2e3c2bb8cda13e1a1209254321` or serialNumber:`7818933f8f85b4619a2b35fba83d0a` or serialNumber:`544b7f922c31ae220a4a922916f6e6`)
The Information tab shows the fingerprints, serial number, and first and last found dates so that you can compare them with the SHA-256 values in the table.
Step 3: Find Software That Still Trusts the Affected Certificates
Certificates presented by your servers are only half of the exposure. Applications running older Go runtimes may continue to trust certificate chains containing the compromised intermediates. VMDR/Cloud Agent can help you find them.
Find Go toolchains to update
Go 1.27.3 and 1.26.10 block certificate chains that contain any of the eight compromised keys (CVE-2026-111943). Qualys has released QID 5019897 for SwCA scanning to detect affected Go versions. Before you scan, confirm your agents have the latest signatures that include this QID, so the new scan picks it up. Then open the Vulnerabilities tab and use the query below to list the impacted assets:
vulnerabilities.vulnerability.qid:5019897
Find Additional Vendor-Specific Updates
Qualys has also released QIDs to detect Go vulnerabilities associated with other vendor operating systems.
vulnerabilities.vulnerability.qid:[6056520,6056501,5019897,6056514,6056506,6056513,6056505,6601039,6684005,6684017,6056489,290608,711201,945683,964525,945699,964523,945690,6056480,6056500,6056475,6601015,6601013,6601022,45804]
Enumerate Affected eMudhra Certificate Chains
In addition to software detection, Qualys is releasing QID 48395: eMudhra Intermediate CA Certificates Enumeration. This Information Gathered (IG) QID helps identify systems presenting or using certificate chains that contain the affected eMudhra intermediate CA certificates. Once available in your subscription, you can query for assets using:
vulnerabilities.vulnerability.qid:48395
Optional Check: Find eMudhra-Issued Certificates with QQL Queries in Certificate View
Open Certificate View > Certificates, paste the query below into the search bar, and run it. It matches any certificate whose issuer organization is one of the eMudhra entities in the affected list.
certificate:(issuer.organization:`eMudhra BV` or issuer.organization:`eMudhra Inc`)
The results list each certificate with its issuer, validity dates, and the assets and ports where it was found. Use the left-pane filters, such as Expiring Certificates and Certificate Authority, to sort the results by urgency.
The two organizations that matter most for this incident are eMudhra BV and eMudhra Inc, because they are the organizations named on the eight compromised intermediates (the G3B and G3C certificates).
Tip: save the query as a dashboard widget in Certificate View, so any new eMudhra-issued certificate that appears is flagged automatically.
Note: QQL query tokens are case-sensitive. If a query returns a syntax error, check the search token list in the Certificate View help and adjust the token name.
Response and Remediation
- Replace affected certificates first. Any leaf certificate whose chain includes one of the eight intermediates should be reissued by another trusted CA and redeployed with the correct chain.
- Updates. Apply operating system security updates and upgrade Go runtimes to supported releases that reject certificate chains containing the compromised intermediates.
- Confirm revocation behavior. eMudhra has revoked the eight certificates, but clients that do not check revocation can still accept them. Validate that certificate revocation checks are functioning correctly and that revocation lists are up to date.
- Monitor continuously. Monitor dashboards after each scan cycle until results are clean.
Conclusion
The eMudhra incident is a reminder that trust depends on both the certificates you present and the authorities you trust. Certificate View gives you the issuer search and dashboards to find eMudhra-issued certificates, and VMDR and Cloud Agent inventory show which hosts and applications still need vendor updates. Qualys enables organizations to quickly discover affected assets, validate exposure, and confidently prioritize response efforts.
Start your risk-free trial of VMDR. If you are not yet using VMDR to measure, communicate, and eliminate risk, start a 30-day trial and use Certificate View to get a full view of your certificates.
Frequently asked questions:
References
- Mozilla bug report on the eMudhra intermediates
- Qualys Certificate View search tokens and API documentation
Contributors
- Russ Sanderlin, Director, Subject Matter Expert, VMDR, Qualys
