Eight Compromised eMudhra CA Keys: What Happened and What Organizations Should Do Now

What happened

On 17 October 2026, a researcher identified only as Wayne reported to the browser root programs that he held the private keys of eight eMudhra intermediate CA certificates. As proof, he signed the message "We have a problem here - Wayne" with each key. The Chrome Root Program received the report at 18:05 UTC and blocked the six TLS intermediates by 19:45 UTC. Mozilla received it at 20:06 UTC and blocked all eight in Firefox by 22:59 UTC. eMudhra revoked the eight certificates on 18 October, Apple blocked them on 19 October and Microsoft followed on 20 October.

Mozilla made the compromise public on 20 October in its dev-security-policy forum, together with a disclosure site listing the affected certificates and patched software versions.

The affected intermediates are:

• EM DV TLS CA - G3B and EM DV TLS CA - G3C
• EM OV TLS CA - G3B and EM OV TLS CA - G3C
• EM EV TLS CA - G3B and EM EV TLS CA - G3C
• EM OV CS CA - G3B and EM OV CS CA - G3C (code signing)

Each one also exists as a second certificate with the same key, cross-signed by Sectigo's long-established AAA Certificate Services root. Removing eMudhra's own roots from a trust store is therefore not enough on its own. A system that still trusts the Sectigo root can still validate the cross-signed copies.

In a preliminary report on Mozilla's bug tracker, eMudhra attributed the weak keys to a flaw in the script used during a key ceremony on 30 April 2025, combined with human error. A test step created a second, weaker set of keys, and those keys were used by mistake to request the certificates. eMudhra states that no certificates were ever issued from these intermediates and that the code-signing CAs were never put into production. Mozilla and Chrome are now removing eMudhra's emSign ECC Root CA - G3 from their root stores.

Why this is bigger than a browser problem

Browsers recovered quickly because they receive revocation updates directly. Much of the software that relies on TLS does not. Command-line tools, scripts, containers, embedded devices and applications built with Go, Python, Node.js, Rust or Electron often validate certificates against a bundled or operating-system root list and never check revocation. These systems will trust a certificate issued from the compromised keys until someone updates them, and many will not be updated for a long time.

Using a forged TLS certificate requires an adversary-in-the-middle position: control of a network the victim uses, a compromised router, a rogue Wi-Fi access point, or access at the level of an internet service provider or government. That limits who can exploit it, but the groups that can are the ones most organizations worry about. Traffic from VPN clients, update agents, APIs and machine-to-machine connections is the most exposed, because none of it passes through a browser.

The code-signing risk

The two code-signing keys need separate attention. A code-signing certificate issued from either of them would let an attacker sign malware that chains to a trusted root, without intercepting any traffic. Operating systems, application allow lists and security tools all treat software from a verified publisher with more confidence, which is exactly why attackers want signatures.

Attackers have chased that trust for as long as TrendAI™ researchers have studied it. Our Forward-Looking Threat Research team's 2018 analysis of 3 million software downloads found the same certificate issuers behind both legitimate and malicious software, with certificates either stolen or resold in the underground. In June and July 2022, QAKBOT's operators rotated through no fewer than seven legitimate code-signing certificates, and the same year we tied three stolen code-signing certificates to the kernel drivers in a Purple Fox campaign. In 2023, BlackCat ransomware affiliates used a kernel driver that terminates security agents, which they had signed using a cross-signing certificate that was stolen or had leaked. That summer, the RedLine and Vidar info stealers arrived in over 30 samples carrying extended validation (EV) signatures, the class of code-signing certificate with the strictest identity checks. In 2025, the EvilAI campaign signed its fake AI and productivity tools through companies registered in 2024 and 2025, a pattern consistent with setting up throwaway companies to obtain new certificates once old ones are revoked.

Each of those cases involved one certificate at a time. The eMudhra compromise sits a level higher. Anyone holding these keys could issue as many code-signing certificates as they wanted, in any company's name, and the keys were weak enough to be recovered from the public certificates.

Revocation may also not close the gap completely. The certificate revocation lists record 18 and 19 October 2026 as the revocation dates for the code-signing intermediates, while the weak keys date from April 2025. Our 2023 RedLine investigation showed why that matters: when a revocation date is set to the day a problem was reported, signatures timestamped before that day can continue to verify. In that case, the CA moved the date back at our request.

eMudhra states that the code-signing intermediates never went into production, so legitimate software signed under them should be rare or absent. That makes any binary that chains to them worth investigating.

"This attack will have long-term systemic impacts on businesses. All impacted businesses must immediately conduct threat hunting. This underscores how PKI security must be enhanced and layered agentic security implemented."

Tom Kellermann, VP of AI Security & Threat Research, TrendAI™

What organizations should do now

1. Update trust stores everywhere, not only on desktops. Patch operating systems and browsers first, then the ca-certificates package on Linux servers and container base images, language runtimes and libraries, and any application that bundles its own roots. Patched versions so far include Go 1.27.3 and 1.26.10 (CVE-2026-111943), Nodejs 22.23.4, 22.23.1, Python certifi 2026.10.19, NSS 3.131.1, Rust webpki-roots 1.0.10, Electron 44.9.1, 43.8.1, and 42.11.16, the curl CA bundle, and the ca-certificates packages for Ubuntu, Debian, Arch, Gentoo, Alpine, Chainguard and Homebrew. Fixes for Bun and FreeBSD fixes are still pending at the time of writing. On Mac OS, the build `curl -get Python3 OpenSSL` checks certificates against a separate file /etc/ssl/cert.pem, that has not yet been updated, even though the operating system itself blocks the intermediates. The disclosure site keeps a current list of patched versions and gives workarounds for Linux and MacOS.
2. Rebuild what was built with the old roots. Go compiles its trust handling into each program, so Go applications need to be recompiled with a patched release. Container images keep the trust store they were built with, so rebuild them from an updated base image and redeploy. Updating the host is not enough in either case. For third-party applications that bundle their own roots, such as Electron apps, the fix has to come from the vendor.
3. Test what still trusts the keys. The disclosure site runs 12 test hosts that serve certificates from the six TLS intermediates, through both the eMudhra and the Sectigo chains. Test both chains from each server, container or device you check, for example curl https://dv-g3b-emudhra.we-have-a-problem.com/ and curl https://dv-g3b-aaa-emudhra.we-have-a-problem.com/. A certificate error is the result you want. Passing one test and failing the other means the system has only half the fix. For systems you cannot test directly, the site also publishes the certificate chains for offline checks.
4. Distrust the intermediates at TLS inspection gateways. A gateway that decrypts traffic validates the website's certificate on the user's behalf and shows the browser a certificate it signed itself. If the gateway still trusts these intermediates, it will pass a forged certificate on to users as trusted, and the browser's own protection never comes into play. Fixing the gateway protects every user behind it while the devices themselves are being patched. Import all 16 certificates listed in the disclosure site's impacted-intermediates.json file (each of the eight intermediates in both its eMudhra and its Sectigo version) as explicitly untrusted. Distrusting only eight leaves the Sectigo path open. Then set the gateway to block, rather than warn on, certificates that fail validation. A gateway's general setting to block invalid certificates does not help on its own, because certificates issued from these keys pass validation until the gateway distrusts the intermediates. Finally, connect to the test hosts through the gateway and confirm the outcome in the gateway's own logs. Users see the gateway's certificate either way, so the browser will not show whether the fix worked.
5. Hunt for misuse, starting with the systems where compromise would do the most damage. Few organizations can hunt across every system at once, and they do not need to. Start from an up-to-date inventory of assets and identities, including internet-facing assets, and hunt first where a forged certificate or a signed malicious binary would lead to catastrophic damage. For identity and privilege, that means Active Directory and Microsoft Entra ID domain controllers, privileged access management (PAM) jump hosts, and cloud IAM roles with administrative privileges. For crown jewel data, it means production databases holding personal or health information, financial processing pipelines, core source code repositories, and CI/CD build runners. For the infrastructure backbone, it means DNS infrastructure, hypervisors and Kubernetes control planes, and key management systems. Within those groups, look first at systems that still trust the compromised intermediates: unpatched trust stores, outdated runtimes, embedded devices, and traffic that leaves the network without passing through an updated browser or gateway. Search TLS inspection, proxy and network sensor logs for certificate chains that include any of the eight intermediates. Passive sensors can only see certificates in TLS 1.2 connections or in traffic that is decrypted, because TLS 1.3 encrypts the certificate. Search endpoints and file inventories for any binary that chains to EM OV CS CA - G3B or G3C by either root, and treat a valid signature as one signal among several rather than proof that a file is safe. Matching on the public key hash catches both versions of each intermediate, and the hashes are listed in the appendix. Check Certificate Transparency logs for unexpected certificates issued for your own domains, keeping in mind that an attacker using a forged certificate has no reason to log it.
6. Review who you trust by default. Check whether systems you manage still trust Sectigo's AAA Certificate Services root for websites. Chrome and Firefox stopped trusting it for that purpose in April 2025, but other trust stores have not.

How TrendAI™ can help

The work for most organizations follows the order of the recommendations above: find what is exposed, hunt there, and close the gap. TrendAI Vision One™ supports each step.

Decide where to hunt. TrendAI Vision One™ Cyber Risk Exposure Management (CREM) maintains an attack surface view of the organization's devices, accounts, applications, cloud assets and internet-facing assets. It assigns each asset a criticality level, and security teams can raise the criticality of systems they know matter most, such as domain controllers, key management systems or build servers. That gives a ranked list of the identity, data and infrastructure systems to hunt first.

Hunt where it matters. XDR Data Explorer in TrendAI Vision One™ Agentic SIEM & XDR can query the fields needed for both halves of this hunt. Network Sensor, Virtual Network Sensor and Deep Discovery Inspector record the certificate issuer name and fingerprint for TLS traffic they can see, so analysts can search for certificates issued by any of the six TLS intermediates. Endpoint Sensor records the signer of each process and file, so analysts can search for binaries signed under EM OV CS CA - G3B or G3C. Internet Access logs a connection blocked for an untrusted server certificate as its own event type, which shows any attempt that reached the gateway after the intermediates were marked Untrusted.

Detect it on the network. Deep Discovery Inspector rule FAR584 detects the compromised certificates by their SHA-1 hash. Deep Discovery Inspector's built-in CA store includes emSign ECC Root CA-G3, the eMudhra root that Mozilla and Chrome are now removing, and a critical patch that updates the CA store is staged for release [10/22].

Close the gap at the gateway. Organizations running TLS inspection with TrendAI Vision One™ Internet Access can upload all 16 certificates as Untrusted under the root and intermediate CA certificates settings, and change the action for certificates that fail validation from the default Warn to Block. Tipping Point Threat Protection System (TPS) customers using SSL inspection should distrust the affected default CAs through the CLI until a firmware update removes them from the built-in store and the installable CA bundle. Until then, a forged certificate passes validation, so the option to block valid server certificates does not trigger, and a forged certificate for a domain excluded from inspection would not be inspected. Customers who send logs over TLS to a remote syslog server should make sure the server is not verified against one of the affected CAs and should leave inbound protected server certificate chain validation against the default CA list disabled.

Hand it off. For teams without the capacity to run this themselves, TrendAI Vision One™ Services – Managed Detection and Response (MDR) provides 24/7 detection, investigation, and response by TrendAI™ analysts who work across the same Vision One telemetry. Organizations that want to know whether they were targeted can request a TrendAI™ compromise assessment, and those who believe they have been breached should contact TrendAI™ incident response.

Appendix: identifiers for hunting

Every intermediate appears twice, as two certificates with the same public key, one under eMudhra's emSign root and the other under Sectigo's AAA Certificate Services root. Matching on the public key hash catches both. Values are taken from the disclosure site's impacted-intermediates.json file, retrieved 20 October 2026.