A security flaw involving eight digital certificates linked to certificate authority eMudhra has prompted emergency action from Google, Mozilla, Cloudflare and other technology providers. The compromised private keys could allow attackers to create fraudulent HTTPS certificates for websites they do not control, potentially enabling impersonation of trusted services.
Although major browsers have moved to block the affected certificates, the response highlights a problem that is less visible to ordinary users: not every application relies on the same system for checking whether a website's certificate can be trusted.
The issue was reported to Google's Chrome Root Program on 17 October 2026, with the company deploying a block within hours. Mozilla also moved to protect Firefox users, while subsequent updates have addressed other software environments.
However, protection in a browser does not automatically mean that every application on a device, server or development system has received the same safeguards. Developers and administrators may need to update the software and certificate stores their services actually use.
The incident does not mean that all HTTPS connections are compromised, nor do the public disclosures reviewed establish that attackers successfully exploited the affected keys against users.
The concern is that software which continues to trust the compromised certificates could remain vulnerable under the right conditions. The practical question is whether each application has received the relevant protection, rather than simply whether its user has an updated browser.
How the eMudhra Certificate Compromise Threatens HTTPS Security
According to Google's disclosure, the private keys associated with the eight intermediate certificates were generated with insufficient randomness, making them recoverable. The certificates included six associated with TLS website authentication and two used for code signing, which serve different purposes.
Certificate authorities help establish trust between websites and visitors. When a browser connects to a website over HTTPS, it checks the site's certificate and whether it can be traced through a recognised chain of certificates to a trusted authority.
Intermediate certificates sit between a root certificate and certificates issued to individual websites.
If an attacker obtains an intermediate certificate's private key, they may be able to create fraudulent certificates for domains they do not own. If a vulnerable client accepts one of those certificates and the attacker can intercept the connection, the attacker could impersonate the website and potentially read or alter traffic.
Google said it blocked the affected intermediate keys in Chrome through a Certificate Revocation List Set, or CRLSet, update on 17 October.
This allowed Chrome to reject certificates associated with the compromised keys without requiring users to download a conventional browser update or restart the application.
Google also distributed equivalent protection to Android devices through Google Play Services, reporting that most Android devices had received the update.
Mozilla separately confirmed that Firefox received protection through OneCRL, its centralised certificate-revocation mechanism. Its security disclosure also announced Firefox releases for users whose custom configurations might prevent them from receiving the usual update.
Google reported that no TLS certificates chaining to the six affected web-authentication intermediates had appeared in Certificate Transparency logs before its blocking action. Chrome enforces Certificate Transparency for publicly trusted certificates by default, helping prevent fraudulent certificates from being accepted through that route.
However, this does not establish that every application is protected, because not all clients enforce the same checks. Nor does Google's statement establish that no certificates were created or appeared in logs after the blocking action.
eMudhra has also published its account of the incident. In an update on 21 October, the company said seven of the eight affected intermediate certificates had never been used in production, while the one that had been deployed had not issued any certificates.
It also said the incident did not involve compromised root private keys or a breach of its infrastructure. These are the company's statements, and its account should be distinguished from independently established findings as investigations continue.
Which Apps Need Updates and How Users Can Check Protection
Cloudflare's 20 October incident update illustrates the work required to protect different services. The company deployed protections across its systems and issued updates for Cloudflare One clients, the 1.1.1.1 app and Cloudflare Tunnel, also known as cloudflared.
It reported that its final server-side mitigations were fully deployed at 19:20 UTC on 20 October, equivalent to 3:20 pm Eastern Daylight Time. That marked the completion of its mitigation work, not a separate overnight attack.
Developers using Node.js also need to pay attention to the software version they run. The Node.js security releases published on 21 October included certificate updates addressing the eMudhra compromise.
The listed releases were Node.js 22.23.4, 24.22.1 and 26.12.1. Organisations should check their deployed versions and dependencies rather than assume an application is protected because its underlying computer has been updated.
Applications and command-line tools that use separately bundled certificates, language runtimes or custom trust configurations may need additional checks.
For ordinary users, keeping browsers and operating systems up to date remains sensible. Android users can restart their devices to prompt the relevant Google Play Services update, according to Google. People using specialist networking applications should also install updates supplied by those providers.
Administrators should review certificate stores used by servers, containers, automated services and API clients, then apply the relevant vendor fixes. Where necessary, they should rebuild container images or restart services so that updated trust settings take effect.
A browser test alone cannot establish that every program on a device is protected. Mozilla security engineer Dennis Jackson has published a test site and related guidance to help users examine different certificate-verification paths.
Any test result applies only to the client and verification path being tested, so developers should check their actual application configuration as well. A successful browser test does not prove that a background service or command-line tool uses the same verification process.
One precaution is essential: do not disable certificate verification to get around a warning or connection failure. Those checks help prevent impersonation, and switching them off removes an important security safeguard.
Google has also announced that it plans to remove the emSign ECC Root CA - G3 certificate from the Chrome Root Store, with the change expected to reach all devices relying on that store on 27 October 2026, Pacific Daylight Time.
Some legitimate websites using certificates that depend on this root may stop working in Chrome until their operators replace them with certificates from another hierarchy trusted by Chrome.
The change concerns Chrome's trust store and does not mean that the root certificate will be removed from every system or that all affected websites will fail in every browser.
The incident shows why organisations and users need to consider the software handling each connection, not just the browser they use to access the web. Installing verified updates, checking application-specific trust settings and retaining certificate verification are essential steps towards reducing the risk.
Frequently Asked Questions
- What is the eMudhra certificate security flaw?A security flaw involving eight digital certificates linked to eMudhra, which could allow attackers to create fraudulent HTTPS certificates.
- How can users protect themselves from compromised certificates?Users should keep their browsers and operating systems updated, restart devices for updates, and ensure all applications have the latest security patches.
- What should developers do to ensure application security?Developers should review and update certificate stores, apply vendor fixes, and verify application-specific trust settings.
