{"id":56631,"date":"2026-10-28T12:41:06","date_gmt":"2026-10-28T16:41:06","guid":{"rendered":"https:\/\/www.kaspersky.com\/blog\/?p=56631"},"modified":"2026-10-30T12:42:44","modified_gmt":"2026-10-30T16:42:44","slug":"emudhra-tls-revocation-enterprise-risks-mitigations","status":"publish","type":"post","link":"https:\/\/www.kaspersky.com\/blog\/emudhra-tls-revocation-enterprise-risks-mitigations\/56631\/","title":{"rendered":"The eMudhra certificate incident: how organizations can respond"},"content":{"rendered":"

Certificates both protect TLS connections and digitally sign applications, and forged ones turn up in real-world attacks from time to time. We\u2019ve seen forged or stolen certificates abused by the DarkHotel APT<\/a> and the Flame<\/a> malware, and in 2011 we saw attack attempts after the certificate authority Comodo<\/a> was compromised. Pulling off this trick usually takes serious expertise. But attacking eMudhra certificates in 2026 doesn\u2019t take much effort at all. An attacker just has to guess a number from 1 to 255. Private keys for intermediate certificate authorities are normally gigantic numbers. But in this case, eight of them were the following: 4, 56, 66, 115, 155, 156, 230, and 237. They could be guessed using the public keys (available in public certificates) in under a second. As a result, a hypothetical attacker could issue certificates for anything by signing them with one of the compromised private keys.<\/p>\n

Six of these keys were meant for issuing TLS certificates, and the other two were for code signing. All eight intermediate certificate authorities (CAs) were also cross-signed by the Sectigo CA. This means clients with different trust chains could trust a forged certificate.<\/p>\n

The major browsers have already blocked the dangerous certificate chains. But IT and security teams still need to assess and remediate the risk in many other systems across their organizations. Scripts for scheduled data-processing, corporate NGFWs, monitoring servers, applications with built-in certificate stores, and devices that don\u2019t get regular updates may accept forged certificates and be vulnerable to man-in-the-middle (MitM) attacks. The keys needed for this are already built into publicly available interception tools.<\/p>\n

Timeline of the eMudhra certificate authority incident<\/h2>\n

The problematic keys came from a batch of 24 intermediate CAs that eMudhra created on April 30, 2025. Instead of cryptographically random values for a 384-bit elliptic curve, eight of the keys turned out to be small numbers. According to eMudhra\u2019s own description<\/a>, a \u201ckey wrap\/unwrap step\u201d during key generation created a second, weak set of keys. Because keys are created and stored in a dedicated device called a hardware security module (HSM), a weak key is hard to notice on its own. It\u2019s still unclear what error caused the keys to be generated twice and the weak set to be used; the investigation is ongoing.<\/p>\n

In May 2025, the Sectigo CA signed all eight intermediate certificates. Then, on October 17, 2026, an independent researcher notified the security teams at Mozilla, Google, and Apple, as well as the CA itself, that the keys were recoverable. On October 20, Mozilla publicly disclosed the incident. This means that for almost a year and a half the keys could have been recovered and certificates forged.<\/p>\n

On October 22, eMudhra announced that it was exiting the global SSL\/TLS certificate business<\/a>.<\/p>\n

What an attacker can do<\/h2>\n

Using the vulnerable intermediate CAs, an attacker can sign a forged certificate for someone else\u2019s domain. Clients that still trust that chain and have no other safeguards will take the forgery for the real server.<\/p>\n

A certificate alone isn\u2019t enough to intercept HTTPS traffic. The attacker also needs a way to tamper with the victim\u2019s traffic or redirect the connection. That\u2019s possible, for example, in a compromised office network, on a Wi-Fi access point the attacker controls, or by interfering with routing and DNS. And all of this does happen in the wild, as the DarkHotel attacks, among others, have shown.<\/p>\n

There\u2019s one more danger: two of the keys can be used for code signing. In theory, that would let an attacker deliver malware that appears to come from a trusted vendor and doesn\u2019t trigger scary OS warnings during installation.<\/p>\n

Was it exploited?<\/h2>\n

Experts from various companies who analyzed the after-effects of the incident haven\u2019t found any malicious attacks that used these certificates. eMudhra and CERT-In have also reported finding no abuse. The Chrome team found no certificates from the six CAs in public Certificate Transparency logs.<\/p>\n

This means that systems where browsers check certificates through Certificate Transparency (CT) were most likely not attacked. But many devices and applications \u2014 especially servers and IoT devices, don\u2019t check CT at all, so we can\u2019t say anything about them. Today, malicious actors no longer need to write their own hacking tools to pull off an attack like this. Version 12.3 of mitmproxy \u2014 a popular tool among security researchers \u2014 already has built-in support for compromised keys.<\/p>\n

Where the risk has been eliminated, and where that isn\u2019t guaranteed<\/h2>\n

Major platforms quickly revoked the compromised certificates. As early as October 17, Chrome did so through CRLSets, and Firefox \u2014 through OneCRL. On October 18, eMudhra itself revoked the certificates, citing \u201cCA Compromise\u201d. Apple took action on October 19, and the Sectigo CA also revoked the cross-signed copies. Microsoft revoked the certificates on October 20. Depending on the settings of a specific application and OS, revocation may have taken effect even without an application update, since blocklists are often updated separately.<\/p>\n

At the same time, a more radical measure is under way: withdrawing trust from the root CA. Chrome has announced the planned removal of \u201cemSign ECC Root CA \u2013 G3\u201d from the browser. Certificates issued under the \u201cemSign Root CA \u2013 G1\u201d root, and the root itself, aren\u2019t affected. According to eMudhra\u2019s estimate, about 30\u00a0000 certificates will need to be migrated.<\/p>\n

But certificate revocation only works where the client can find out about the revocation to then be able to actually act upon it. Many applications check the signature, server name, and certificate validity period, but don\u2019t retrieve or update blocklists. Here are the typical cases:<\/p>\n

Outdated and LTS systems.<\/strong> LTS (long-term support) status alone doesn\u2019t mean a system is vulnerable. By definition, a system with this status receives support. But old containers, frozen OS images, and systems that are no longer updated can keep trusting revoked CAs for a long time. It all depends on updates to ca-certificates and TLS libraries, and the settings of the specific application.<\/p>\n

Automated systems and servers.<\/strong> On emudhra.we-have-a-problem.com<\/a> \u2014 a site created by enthusiasts where you can check any client software for misplaced trust \u2014 curl and Zabbix dominate the list of the most vulnerable systems. For HTTP checks, Zabbix usually uses libcurl and the certificate store configured for it. Similar behavior is also documented in the built-in curl in macOS<\/a>. At the OS level and in Safari, the certificate is revoked, but curl reads a plain \/etc\/ssl\/cert.pem file, and that\u2019s precisely where the fix has to be made. This is a good example: even when system-level trust and revocation mechanisms work, individual applications \u2014 including ones that ship with the OS by default \u2014 can remain vulnerable.<\/p>\n

Python, Ruby, Go, Java, and containers.<\/strong> An application may use its own set of root CAs, which isn\u2019t updated along with the OS. Endor Labs found more than 25 popular packages<\/a> that contain the affected root.<\/p>\n

Slack, GitHub Desktop, and other apps built on the Electron framework.<\/strong> These apps ship with their own Electron\/Chromium<\/a>, so updating a separately installed Chrome doesn\u2019t update Slack. The certificate revocations are already in the new Electron version, but now every developer has to rebuild and distribute their app, and every user has to install the update. That said, not every Electron app is necessarily vulnerable. The outcome depends on the version, how the app updates its blocklists, and which network stack it uses.<\/p>\n

Mobile browsers and IoT devices.<\/strong> Mobile Chrome, Firefox, and Safari get certificate revocation data as quickly as their desktop counterparts do. With the stock browsers from smartphone makers, this isn\u2019t the case. In a published test<\/a>, Samsung Browser 31.0.0.64 accepted all six test chains from emSign while rejecting the ones from Sectigo. For HarmonyOS 6 and 7, researchers found<\/a> the affected CAs in Huawei\u2019s published list of root CAs, and those CAs can\u2019t be revoked manually.<\/p>\n

For unsupported devices, home appliances, and old firmware, a certificate store update may never be released. In those cases, the problem could linger for years.<\/p>\n

Impact on TLS inspection in a corporate network<\/h2>\n

When an NGFW or web gateway inspects encrypted traffic, it maintains two connections: one with the client and the other with the external server. The client receives a certificate signed by the corporate CA, while the gateway itself verifies the authenticity of the external server.<\/p>\n

If the gateway accepts a forged eMudhra certificate, even an updated browser on an employee\u2019s computer won\u2019t see the dangerous chain. Instead, it will receive the familiar corporate certificate. In this scenario, the security tool itself hides the problem from the client. That said, carrying out such an attack would also require intercepting traffic.<\/p>\n

To fix the validation policy and certificate lists on the inspection device itself, follow the vendor\u2019s instructions\u00a0\u2014 if the vendor has published any, that is.<\/p>\n

At Cisco<\/a>, the status of the issue is documented in detail for all products. Most of them are still listed as \u201cunder investigation\u201d, but mitigation measures<\/a> are recommended for vulnerable devices.<\/p>\n

Sophos<\/a> and Check Point<\/a> promise device software updates and, in the meantime, advise removing the certificates manually. Neither company has published a security advisory, but employees of each posted recommendations on its support forum.<\/p>\n

For Fortinet devices, instructions for checking and removing emSign certificates can be found here<\/a>. Palo Alto offered only general advice<\/a> instead of specifics for its own products.<\/p>\n

Of course, a properly configured gateway can indeed temporarily protect outdated client devices that trust the dangerous certificates.<\/p>\n

To check specific devices, services, containers, and virtual machines, you can use a dedicated website<\/a>. One possible scenario for proactively hunting for threats that exploit or have previously exploited weak keys is described here<\/a>.<\/p>\n\n","protected":false},"excerpt":{"rendered":"

How a certificate’s private key ended up being equal to 4, and why browser updates alone won’t protect you from vulnerable eMudhra certificates. <\/p>\n","protected":false},"author":2722,"featured_media":56632,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1999,3051,3052],"tags":[1278,2980,16,597,261,21,4691,398,422,131,2917],"class_list":["post-56631","post","type-post","status-publish","format-standard","has-post-thumbnail","category-business","category-enterprise","category-smb","tag-browsers","tag-certificates","tag-chrome","tag-cryptography","tag-encryption","tag-firefox","tag-ngfw","tag-patches","tag-threats","tag-tips","tag-tls"],"hreflang":[{"hreflang":"x-default","url":"https:\/\/www.kaspersky.com\/blog\/emudhra-tls-revocation-enterprise-risks-mitigations\/56631\/"},{"hreflang":"ru","url":"https:\/\/www.kaspersky.ru\/blog\/emudhra-tls-revocation-enterprise-risks-mitigations\/42912\/"},{"hreflang":"ru-kz","url":"https:\/\/blog.kaspersky.kz\/emudhra-tls-revocation-enterprise-risks-mitigations\/31172\/"}],"acf":[],"banners":"","maintag":{"url":"https:\/\/www.kaspersky.com\/blog\/tag\/tls\/","name":"TLS"},"_links":{"self":[{"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts\/56631","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/users\/2722"}],"replies":[{"embeddable":true,"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/comments?post=56631"}],"version-history":[{"count":2,"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts\/56631\/revisions"}],"predecessor-version":[{"id":56634,"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts\/56631\/revisions\/56634"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/media\/56632"}],"wp:attachment":[{"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/media?parent=56631"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/categories?post=56631"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/tags?post=56631"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}