AdGuard Blog: eMudhra certificate incident: How AdGuard responded

Gandalf_The_Grey

Level 86
Verified
Honorary Member
Top Poster
Content Creator
Well-known
Forum Veteran
A security incident involving the certificate authority eMudhra prompted browser and operating system vendors to block several of its certificates. Because AdGuard also checks server certificates to filter HTTPS traffic, we needed to address the issue in our apps, too.

We acted quickly and released emergency updates. Here’s what happened, what we changed, and what you need to do to stay protected.
eMudhra is a certificate authority whose certificates were trusted by major browsers and operating systems. Certificate authorities play an important role in HTTPS: they help browsers verify that a website is really the site it claims to be.

On October 17, 2026, a security researcher reported that the private keys of eight eMudhra intermediate certificates were compromised. The keys had been generated with extremely weak randomness, so they could be recovered from the public certificates in under a second. Someone who obtained these keys could use them to issue fraudulent certificates and impersonate websites that browsers would otherwise trust. As of publication, there have been no public reports of these keys being exploited in attacks.

Browser vendors acted quickly. Google and Mozilla revoked trust in the affected certificates within hours of the report, followed by Apple and Microsoft. The root cause was a flaw in eMudhra’s key generation process. AdGuard was not involved, but the incident required us to adjust how AdGuard handles HTTPS traffic.

When HTTPS filtering is enabled, AdGuard checks server certificates itself so it can inspect encrypted traffic and block ads and trackers. We need to make these checks at least as strict as those performed by browsers, and, when necessary, take a more conservative approach.
We added the compromised eMudhra certificates to our blocklist and rolled out emergency updates for all AdGuard apps that support HTTPS filtering.

The fixes are available in these versions:
  • AdGuard for Windows: 8.0.3
  • AdGuard for Android: 4.15.1
  • AdGuard for Mac: 2.20.2
  • AdGuard for Linux: 1.5
Our team worked hard to deliver these fixes as quickly as possible, with several team members working late into the night to get the updates ready. We want to thank everyone who contributed to the response. Protecting our users’ security and privacy is a responsibility we take seriously, especially when it comes to certificate validation.
 
(link omitted)


Thanks for posting this, Gandalf. AdGuard handled this correctly, and the update is more important than an ordinary filter-engine patch.

With HTTPS filtering enabled, the browser sees a certificate generated locally by AdGuard, while AdGuard validates the website’s original certificate. Consequently, browser distrust updates cannot automatically protect that upstream validation path. AdGuard therefore needed its own blocklist update. For affected chains, it now declines to inspect the connection and leaves validation to the browser; the harmless side effect is that some ads may escape filtering.

A useful distinction: the intermediate keys were “compromised” because they could be reconstructed from public information, not because eMudhra necessarily suffered an intrusion. The capability to forge certificates was real, but there are no public reports of exploitation. eMudhra also says those intermediates issued no end-entity certificates. Google blocked the keys through CRLSet, while Mozilla used OneCRL, both without users needing a normal browser update or restart (Google, Mozilla, eMudhra).

For AdGuard users:

  • Update to Windows 8.0.3, Android 4.15.1, Mac 2.20.2, Linux 1.5, or anything newer.
  • Keep the browser current as well.
  • Windows v7 users need 7.22.10, which is a one-off fix and is not delivered through the built-in updater; use AdGuard’s official GitHub release linked in the AdGuard advisory.
  • There is no reason to remove AdGuard’s local certificate, reinstall everything, or change passwords merely because of this incident.

It is also a neat demonstration of the responsibility created by HTTPS inspection: once software stands between the browser and the server, “at least as strict as the browser” is not a nice aspiration—it is the minimum acceptable standard.

Sources
 

Recently browsing

Members who viewed this thread in the last 5 minutes

Back
Top