Eight eMudhra certificates are compromised and every trust store needs an update

A certificate authority used by browsers, operating systems and Cloudflare itself was compromised, and every piece of software that keeps its own list of trusted certificates has catching up to do. Cloudflare disclosed on 20 October that private keys for eight eMudhra intermediate certificates were weak enough that an attacker could create a forged certificate for any domain.

Cloudflare said it became aware of the compromise at about 17:00 UTC on 19 October. The post was signed by Christopher Patton, Bas Westerbaan, Trishna and Jeremy Hartman. Its security review had not found active exploitation on Cloudflare services.

What Cloudflare shipped

Cloudflare released updates to its own clients and deployed server-side changes before it published the disclosure. The Cloudflare One Client and the 1.1.1.1 app have new builds on every platform, with the iOS version of the Cloudflare One Agent still pending App Store review at the time of the post. Cloudflare Tunnel, the daemon called cloudflared, moved to 2026.10.2. Mitigations for the CDN and the Zero Trust products finished rolling out at 19:20 UTC on 20 October.

What customers have to do

Users of the Cloudflare One Client need v2.5.6 on Android, v1.12.16 on iOS, and 2026.8.2115.0 on Windows, macOS and Linux. The 1.1.1.1 app needs v6.38.10 on Android, v6.31.7 on iOS, and the same 2026.8.2115.0 build on desktop. Teams running Cloudflare Tunnel in a container need to pull the fixed image and redeploy.

Customers using Cloudflare's Full (strict) encryption mode need to check that their custom origin certificates were not issued through one of the affected eMudhra intermediates, because Cloudflare's own Automatic SSL/TLS process is being updated to flag those. Teams running their own trust store for mutual TLS have to review it as well. Containers that enable Cloudflare's HTTPS egress interception move certificate validation to Cloudflare's infrastructure and are already protected.

The developer part

Cloudflare's advice to developers is to look beneath the SDK. A library that calls another service may delegate certificate validation to an HTTP library, to the language runtime, to the operating system or to a custom trust configuration, so updating the SDK alone may not change the policy underneath it. Mozilla cryptography engineer Dennis Jackson has crowdsourced a list of commonly used packages that have been patched, and runs a test site that offers browser checks and non-browser verification steps.

Cloudflare noted that a passing browser test does not prove a background service is protected, and neither does a curl check if the application uses a different verifier. Patching may surface certificate errors in dashboards, and the fix is to update the dependency rather than disable verification, because disabling it removes the authentication protection the updates restore.

The incident shows the cost of treating a trust store as a static list. Cloudflare said it was interested in projects such as upki that give a trust store the ability to be updated with revocation and certificate-transparency information quickly, because the gap between a browser flipping a switch and a service with hundreds of applications doing the same is where exposure sits during an incident like this.

Source

8 eMudhra certificates are compromised. Here's what you need to know by Christopher Patton, Bas Westerbaan, Trishna and Jeremy Hartman at the Cloudflare Blog.