Cato CTRL Threat Brief: eMudhra Certificate Compromise Highlights the Value of Protection Delivered by an AI-Native SASE Platform
Executive summary
Eight eMudhra intermediate certificate authority (CA) private keys were compromised after being generated with insufficient randomness. Attackers could use these keys to forge certificates and impersonate legitimate websites or services to clients that still trust them. An attacker able to intercept a connection could potentially read or modify sensitive traffic.
We have deployed a certificate-trust update through our centrally managed PoP architecture, removing affected eMudhra certificates from the trust store used for TLS inspection. Delivering the update through the Cato Cloud removed the need for customers to patch security appliances at individual locations.
What happened?
Intermediate CAs sign certificates used to authenticate websites and services. Compromising their private keys can enable attackers to issue fraudulent certificates for domains they do not control. Organizations can therefore face exposure even when their legitimate certificates come from another provider.
Google and Mozilla received reports on October 17, 2026, and distributed emergency certificate blocks that day.
Mozilla also released updates associated with CVE-2026-113470. These include the certificate block list directly in Firefox and Thunderbird, protecting installations even when automatic block-list updates are disabled or unavailable.
Google found that no website certificates issued through the six affected TLS intermediates had appeared in Certificate Transparency (CT) logs before its emergency block took effect. CT logs are public records of certificates. Browsers that enforce CT, including Chrome, require valid proof that a certificate has been submitted to these logs before accepting it. Those browsers would therefore have rejected fraudulent certificates from the affected intermediates even before receiving the emergency blocks.
However, this protection does not extend to all software. Some applications, older browsers, or configurations without CT enforcement may have accepted unlogged fraudulent certificates if they still trusted the affected intermediates. The absence of certificates from those intermediates in CT logs before Googleβs block therefore does not prove that no attacks occurred.
eMudhra says its root private keys and other intermediate CAs are unaffected. Its investigation remains ongoing.
Business risks
The exposure extends beyond employee browsers. Applications, API integrations, containers, and embedded devices may use independent trust stores or lack effective certificate-revocation checks.
Potential business consequences include:
- Credential theft and data exposure: Intercepted connections could expose passwords, session tokens, and confidential information.
- Transaction manipulation: Attackers impersonating trusted services could alter business communications or API responses.
- Service disruption: Emergency trust removal can also reject legitimate certificates. Google announced a broader root-removal rollout expected on October 27, requiring affected website operators to replace their certificates.
- Operational costs: Identifying and updating separate trust stores across applications and infrastructure creates work and opportunities for missed remediation.
These are potential impacts, not evidence of observed exploitation.
Our response: centralized control, global enforcement
The Cato AI-native SASE Platform converges networking and security in a cloud-native service delivered through globally distributed points of presence (PoPs). Our Single Pass Cloud Engine provides integrated security enforcement, while centralized management allows us to deliver updates across our cloud infrastructure. This reduces the coordination and maintenance work customers would otherwise undertake across distributed security appliances.
Centralized operations also support controlled deployment. Our established PoP change-management practices include phased rollouts, validation, monitoring, and rollback capabilities to manage operational risk as the platform evolves.
What this means for our customers
We have centrally deployed a certificate-trust update across our globally distributed PoPs, removing affected eMudhra certificates from the trust store used for TLS inspection. Customers do not need to make configuration changes to receive this update.
Analysis of our data lake showed that the certificate chains affected by this update appeared in only a very small proportion of the network flows examined. Based on this limited usage, we expect minimal connectivity impact for customers.
For details about the update and potential connectivity impact, see the security update.
For locations or connections that access the internet outside our platform, organizations should apply the relevant vendor updates or extend our platformβs coverage so those connections are subject to our certificate-validation controls.