eMudhra Intermediate CA Compromise

Overview

• Vendor: eMudhra

• Issue: Intermediate Certificate Authority (CA) private-key compromise.

• Tracking: Ecosystem-specific CVEs are listed under Incident Breakdown. These do not represent a single CVE assigned to the eMudhra incident.

Private keys associated with eight eMudhra intermediate CA certificates have been compromised: six used for Transport Layer Security (TLS) and two for code signing. Google reports that the keys were generated with insufficient randomness. This allows attackers to forge HTTPS certificates that clients may accept if they still trust the affected CAs.

Browser protection does not establish that every system in your organisation is protected. Firefox and Chrome deployed browser-specific blocking mechanisms. Servers, applications, containers and appliances may use separate trust stores or handle revocation differently. Assess these systems independently.

Disclosure status: Mozilla reported no certificates from the compromised intermediates in Certificate Transparency logs at the time of its disclosure. This does not rule out unlogged certificates being used against clients that do not enforce Certificate Transparency.

Sources: Mozilla Disclosure of Affected Certificates and Google Guidance on the eMudhra Intermediate CA Compromise.

Affected Systems

Exposure depends on the certificate chains a client trusts and how it validates certificates and enforces revocation. Prioritise systems with independently maintained or bundled trust stores:

• Firewalls and proxies performing TLS inspection.

• Servers, command-line tools and automated services.

• Application runtimes, API clients and bundled certificate stores.

• Container images and deployed workloads.

• Appliances and firmware with separate certificate-update processes.

These are systems to assess, not a statement that every listed system is affected. Confirm whether each client can still accept a certificate chain using a compromised key.

Red Hat's bulletin identifies potential exposure in RHEL-based products and container images. Consult the relevant operating system, application and appliance vendor for affected products, versions and available updates.

Source: Red Hat RHSB-2026-012: Affected Products and Remediation.

Incident Breakdown

Compromised Intermediate CA Keys

• Description: Private keys associated with eight intermediate CA certificates were compromised. Mozilla also lists cross-signed certificates that provide additional trust paths using the same compromised keys.

• Impact: An attacker could issue fraudulent TLS certificates to impersonate a website. If a client accepts the certificate, this could allow interception or modification of encrypted traffic.

• Conditions: The client must accept a chain using a compromised key. The attacker must also be able to intercept or redirect the connection.

• Notes: The CA key compromise does not, by itself, establish that your systems have been attacked or compromised. Browser blocking does not confirm protection for clients using separate trust stores.

• Sources: Mozilla Disclosure and Cross-Signed Certificate List and Google Protection and Root-Removal Guidance.

Ecosystem-Specific Tracking Identifiers

This is a CA private-key compromise rather than a conventional software vulnerability. Red Hat lists the following identifiers to track preventative trust-store updates:

• CVE-2026-114406: RHEL ca-certificates.

• CVE-2026-111943: Go / Golang.

• CVE-2026-91403: Java.

• CVE-2026-113812: Perl Mozilla::CA.

Consult the relevant vendor advisory for applicability and available updates. Do not treat these identifiers as a single incident-wide CVE or assume that all installations of these technologies are affected.

Source: Red Hat RHSB-2026-012: Tracking Identifiers and Update Guidance.

Mitigation

Identify the Trust Stores in Use

• Confirm whether each relevant service uses the operating system's trust store, a runtime-specific store or bundled certificates.

• Include servers, automated services, application runtimes, containers, proxies and appliances in the assessment.

• Do not assume that a browser or operating system update also updates every application.

Apply Vendor-Supported Updates

• Follow current guidance from operating system, application and appliance vendors.

• Apply relevant trust-store, software and firmware updates.

• For affected RHEL deployments, follow Red Hat's guidance to update the ca-certificates package as updates become available.

Source: Red Hat Remediation Guidance.

Rebuild and Redeploy Affected Workloads

• Where affected certificates are bundled into container images or application packages, rebuild and redeploy using updated dependencies or base images.

• Verify the deployed workload. Updating the host alone may not address certificates embedded in an application or container.

Verify Certificate Rejection

• Confirm that the actual applications and services in use reject affected certificate chains.

• Include cross-signed variants in testing. Blocking one certificate may not address every trust path using the same compromised key.

Source: Mozilla Affected Certificates and Cross-Signed Variants.

Check for Legitimate Service Disruption

Website operators should check whether their certificates chain to emSign ECC Root CA - G3. Google has published root-removal guidance and instructs affected operators to obtain and install a replacement certificate from another trusted public key infrastructure (PKI) hierarchy. Check the current rollout status and vendor guidance when planning replacement.

Do not disable certificate validation or indiscriminately delete root certificates. Broad root distrust can interrupt legitimate services. Where targeted blocking is unavailable, assess vendor-recommended alternatives and their operational impact before making changes.

Source: Google Root-Removal and Certificate Replacement Guidance.

Summary for IT Teams

• Systems: Clients that may still accept certificate chains using the compromised eMudhra intermediate CA keys, including systems with separate or bundled trust stores.

• Potential Impact: Fraudulent TLS certificates may allow website impersonation and traffic interception where the client accepts the chain and an attacker can intercept or redirect the connection.

• Action Required: Identify relevant trust stores, check vendor applicability, apply supported updates and rebuild affected workloads. Verify that applications reject affected chains, including cross-signed variants. Review legitimate certificates that chain to emSign ECC Root CA - G3.

Reference

• Mozilla Disclosure: Affected eMudhra Certificates and Cross-Signed Variants

• Google Security Blog: Chrome and Android Protections and Root-Removal Guidance

• Red Hat RHSB-2026-012: Affected Products, Remediation and Tracking Identifiers

• Mozilla Security Blog: Protecting Firefox Users Following the eMudhra Compromise

• BleepingComputer: eMudhra Certificate Compromise Overview

• Endor Labs: Non-Browser Trust-Store Exposure

Need Help?

If your organisation needs assistance assessing exposure, planning remediation or investigating potential compromise, contact the Secure ISS SOC team on 1300 769 460 or email soc@secure-iss.com.