Eight compromised eMudhra certificate keys could let someone forge the HTTPS identity of a website. Google and Mozilla say they blocked the affected keys within hours of receiving reports on October 17. Their October 20 announcements expose a less obvious problem: protection delivered to a browser does not automatically reach every application that uses a different certificate trust store.
For ordinary users, the response is to keep browsers current and let their security updates run. Google also says Android users can restart their devices to trigger the relevant protection update. For website operators, there is a separate deadline: Chrome plans to remove the affected upstream root on October 27, potentially breaking legitimate sites that still depend on it.
The keys that vouched for other websites
A website normally presents a TLS certificate to show that the encrypted connection belongs to the domain in the address bar. That certificate sits in a chain: an intermediate certificate authority signs it, and a trusted root ultimately vouches for the intermediate. A client checks that chain before accepting the site’s identity.
The eMudhra incident affected the private keys of eight intermediate CA certificates. Google’s security teams say the keys were generated with insufficient randomness. That makes this a failure in the machinery used to establish trust: someone able to recover such a key could issue a convincing certificate for a domain they do not own.
That alone does not redirect every connection on the internet. To read or change a victim’s traffic in the scenario Mozilla describes, an attacker also needs to intercept the connection, and the victim’s client must still accept the compromised authority. The announcements establish a dangerous impersonation capability; they do not establish that every eMudhra customer, browser user, or past HTTPS session was compromised.
The browser block arrived before the public explanation
Google received the report at 18:05 UTC on October 17. By 19:45 UTC, Chrome had corroborated it and added the affected public-key fingerprints to CRLSet, its distributed certificate-blocking mechanism. Blocking the key matters because the same compromised key cannot escape the block simply by appearing in another certificate.
Mozilla received its report at 20:06 UTC. It used OneCRL, its centrally distributed revocation list, and says distribution was complete by 22:59 UTC for Firefox users with standard configurations. Neither company’s initial browser protection required an update or restart.
Those timings explain an apparent contradiction: an emergency browser release can appear after many users have already been protected. On October 20, Mozilla announced Firefox 158.0.1 for desktop and Android, alongside ESR 115.43.1 and ESR 153.5.1, to reach the minority whose custom settings could have prevented the OneCRL delivery. Keeping Firefox current covers that additional route.
On October 21 at 08:29 UTC, Mozilla released Firefox for Android 158.0.2 to fix a startup delay in applying the bundled OneCRL blocklist on some clients. Android users should install that update; the earlier October 20 release remains part of the response timeline.
A protected browser leaves a second question
Applications do not necessarily share a browser’s certificate decisions. A command-line client, a bundled runtime, or another program may use its own CA collection or a copy derived from Mozilla’s store. A successful browser block therefore answers a question about that browser, rather than proving that every program on the device has received the same protection.
Mozilla is also removing the signing root from NSS 3.131.1 to help software that uses its trust store without receiving OneCRL. Google likewise removed emSign ECC Root CA - G3 from the Chrome Root Store for consumers that do not receive CRLSet updates. These broader trust-store changes close a distribution gap that the quick browser response cannot close by itself.
Google says Android devices and Googlebooks received an equivalent protection update through Google Play Services around 22:00 UTC on Monday, October 19. Most Android devices had already received it when Google published its account; restarting the device can trigger an immediate update. That statement should not be stretched into a guarantee about every third-party app’s independently managed certificate bundle.
October 24 update: Electron apps need a patched runtime
Electron’s October 22 advisory, reviewed on October 23, makes the separate-app problem concrete. Its fix blocks the compromised eMudhra intermediates in both Chromium networking and Node.js tls, https and fetch. Earlier builds could accept an impersonated TLS server when an attacker had a certificate issued through the compromised intermediates and could intercept the app’s network traffic. Apps making no network connections are outside this stated exposure. [5]
The listed fixed releases are 42.11.16, 43.8.1 and 44.9.1, plus the prerelease 45.0.0-beta.6. App maintainers need to ship a build using a patched Electron release; users should install that app update through its trusted distribution channel. Updating a separate browser does not replace the runtime inside an installed application. Electron lists no app-side workaround, so do not disable certificate verification to make a connection work.
October 23 follow-up: a smart speaker trusts the wrong server
The eQuasar project supplies a concrete example of the separate-device problem. Its author reports enabling ADB, a debugging interface that provides a device shell, on a Yandex Station Mini 2 running firmware 0.369.. The setup requires control of local DNS routing to send the speaker to a substitute server. That server presents a certificate for Yandex’s service and returns a cloud-configuration response enabling network debugging. The important boundary is the speaker’s decision to trust that response, independently of the browser on its owner’s computer. [3]
The repository’s public certificate chain makes the eMudhra connection checkable. Its intermediate is EM OV TLS CA - G3C, cross-signed under AAA Certificate Services. We verified the supplied leaf certificate’s signature against that intermediate and matched the intermediate’s public-key fingerprint to Mozilla’s published compromised-key list. This verifies the certificate link; it does not independently reproduce the result on a speaker. [4]
The author’s stated test covers that model and build, rather than every Yandex speaker or current firmware. The repository is not evidence of mass attacks, an internet-wide remote takeover, or a bypass of subscription checks. Keep device firmware updates enabled and protect the router’s DNS settings; updating Chrome or Firefox alone cannot establish whether a separate smart device rejects this chain. Blocking device updates to preserve a modification would work against that protection.
October 26 update: eMudhra acknowledges a script error
In a new leadership statement, eMudhra attributes the weak issuing-CA keys to a script error and apologizes for the failure. It says the affected intermediates were revoked within 14 hours of confirming the problem. According to its investigation to date, those intermediates had not issued publicly trusted end-entity certificates, and its infrastructure and customer data were not compromised. These are the company’s findings about its own issuance and systems, not an independent finding that nobody could have recovered or used the weak keys. [6]
The company says it will publish a full root-cause analysis through the Common CA Database (CCADB) process and commission an independent review of the incident and its controls. That leaves a concrete question open: why the controls failed to catch the weak keys. Its assurance does not replace the separate browser, application and website-certificate work described here; a client still needs to reject a chain that an unauthorized holder of a recovered key could construct.
October 27 is a website certificate deadline
Removing a root affects legitimate certificates too. Google’s announced rollout of the G3 root removal is expected on Tuesday morning, October 27, Pacific daylight time, with earlier delivery on prerelease Chrome channels. A site’s certificate can be genuine and still stop working if its chain depends on that root.
Google tells affected website operators to obtain and install a new TLS certificate under another hierarchy included in the Chrome Root Store. The useful check is the complete deployed certificate chain, including intermediates and root, rather than the certificate’s expiry date alone. If hosting or a certificate provider manages that deployment, ask it to confirm the replacement chain before the cutoff.
Users who encounter a certificate error should not bypass validation or install a new root offered by an unsolicited message. The existing connection-not-private troubleshooting guide explains other possible causes of such warnings. Obtain browser updates through the browser or its official distribution channel; fake Chrome update pages are a separate malware trap.
The practical distinction is between three jobs: browsers block the compromised keys, application maintainers update their own trust decisions, and site owners replace legitimate chains that will lose trust. Completing one does not demonstrate that the other two are complete.
References
- Chrome and Android Security Teams. “Protecting Chrome and Android Users from Compromised eMudhra Intermediate CA Certificates.” Google, October 20, 2026; accessed October 21, 2026. Response timeline and root-removal guidance.
- Firefox Security Team. “Protecting Firefox users following the compromise of eMudhra intermediate certificates.” Mozilla Security Blog, October 20, 2026; updated October 21, 2026; official copy on Planet Mozilla, accessed October 21, 2026. Firefox, OneCRL and NSS protection.
- bitracker / iwakura. eQuasar: project description, configuration and public certificate chain. Repository revision 02f3c583a7, October 22, 2026; accessed October 23, 2026.
- Dennis Jackson, Mozilla. eMudhra Intermediates Compromise. oss-security, October 20, 2026; accessed October 23, 2026.
- Electron maintainers. Mitigation for compromised eMudhra intermediate certificates. Security advisory GHSA-jr5w-w6x2-84p9, October 22, 2026; GitHub review October 23; accessed October 24, 2026.
- eMudhra Leadership Team. A Note from eMudhra Leadership. October 26, 2026, in the certificate-incident statement; accessed October 26, 2026.
