The eMudhra certificate compromise has pushed browser makers, operating-system vendors and internet companies into emergency fixes this week. The private keys behind eight intermediate certificates issued by eMudhra, an India-based certificate authority, were found to be weak enough to recover, which in theory let anyone create a fake HTTPS certificate for any website. Major browsers say they have already blocked the certificates. Developers and system administrators may still need to update software that keeps its own list of trusted certificates.
Key points
- Mozilla says it received a report on October 17 that the private keys of eight eMudhra intermediate certificates had been compromised, and it blocked them for standard Firefox users within about three hours.
- Cloudflare says its review has not found active exploitation on its own services, and that the problem concerns certificate authentication, not the encryption algorithms used by TLS.
- Software that bundles its own trust store, or does not check revocation, may keep trusting the bad certificates until it is updated.
What happened
Websites prove their identity with certificates that chain back to a trusted certificate authority. Intermediate certificates sit in the middle of that chain and are used to sign the certificates that websites actually present. If an attacker obtains an intermediate’s private key, they can sign certificates that browsers would accept as genuine.
According to Mozilla, it was told at 20:06 UTC on Saturday, October 17, 2026, that the private keys of eight eMudhra intermediate certificates had been compromised. Cloudflare’s own write-up says that “because the keys themselves are weak, an attacker can create a forged certificate for any domain,” which could allow someone in a position to intercept traffic to impersonate a server and read or alter data.
BleepingComputer, citing Mozilla’s incident report, says all eight certificates used P-384 keys generated in April 2025 whose private values were below 256, so a key could be found by testing about 256 possibilities. The publication reports that eMudhra blamed an error in a key-generation script, said most of the affected intermediates were never used in production, and said it had found no evidence that they were used to issue certificates to end users. eMudhra has revoked the eight certificates and stopped issuing new certificates under the affected G3 root, the report says.
What browsers and vendors have done
Mozilla says it blocked the certificates through OneCRL, its central revocation list, and that the update reached all Firefox users with standard settings by 22:59 UTC on October 17, without needing a restart. On October 20 it released Firefox 158.0.1 for desktop and Android, Firefox ESR 115.43.1 and Firefox ESR 153.5.1 for users whose custom settings blocked that update. NSS 3.131.1, Mozilla’s security library, removes the root certificate that signed the affected intermediates.
BleepingComputer reports that Google Chrome blocked the six affected intermediates that could issue TLS certificates on October 17, and that Apple added protections on October 19. The Go programming language team released versions 1.27.3 and 1.26.10, and many Linux distributions and developer packages, including Ubuntu’s ca-certificates, Python’s certifi and the curl CA bundle, have shipped updates. At the time of that report, fixes for Debian, FreeBSD, Node.js and Bun were still listed as pending.
Cloudflare says it patched critical services before public disclosure and published updates for its WARP and 1.1.1.1 apps and for Cloudflare Tunnel (cloudflared version 2026.10.2). It advises developers to look beneath their SDKs, because certificate checks may be handled by an HTTP library, language runtime or operating system. It also warns against “fixing” certificate errors by turning verification off, which would remove the protection the updates restore.
What has not been confirmed
No vendor whose statement we reviewed has confirmed that the weak keys were used in a real attack. Cloudflare says only that it has not identified active exploitation on its services, and eMudhra, as reported by BleepingComputer, says there is no evidence of misuse while acknowledging the keys could have been recovered since April 2025. The full list of affected applications is still changing, so a clean result in one app does not prove that every program on a device is protected.
Why it matters
For most people, the practical step is simple: keep browsers, phones and computers up to date and restart them when prompted. Firefox, Chrome and Apple users on standard settings are covered by the blocks described above. The bigger risk sits with servers, containers, command-line tools and apps that carry their own certificate bundles. Administrators should update CA bundles and language runtimes, rebuild container images and restart services so the new trust lists load. BleepingComputer notes a warning from Mozilla engineer Dennis Jackson that the built-in curl on macOS may keep trusting the certificates because its bundle does not check revocation data.
The incident also shows why fast revocation systems matter: browsers could react within hours, while static trust lists inside other software take longer to fix. For more security and gadget coverage, browse our Technology news.
Sources
- Mozilla Security Blog, October 20, 2026: Protecting Firefox users following the compromise of eMudhra intermediate certificates
- Cloudflare blog, October 20, 2026: 8 eMudhra certificates are compromised
- BleepingComputer: Mozilla, Google, Apple block compromised eMudhra CA certificates
Reported October 21, 2026 (India Standard Time), using AI-assisted drafting and source checks. Original AI-assisted editorial illustration by Taaza Khabar, generated October 21, 2026; conceptual scene, not a photograph of the event.
Leave a Reply