Cloudflare learned at roughly 17:00 UTC on October 19, 2026 that the private keys behind eight eMudhra intermediate certificates had been compromised. Browsers, operating systems and Cloudflare itself all trusted these certificates. Because the keys are weak, an attacker can mint a forged certificate for any domain and present it to impersonate servers, intercepting or altering traffic.
Cloudflare moved first on its own critical services, patching them ahead of public disclosure. Its security review has found no active exploitation of the flaw against Cloudflare services.
What Cloudflare has shipped
Updated clients are available for the Cloudflare One Clients (WARP, also called the 1.1.1.1 app) and for Cloudflare Tunnel (cloudflared). Mitigations are deployed across Cloudflare's CDN, Developer and Zero Trust products. Customers running Cloudflare Zero Trust with Gateway on an up-to-date client are protected automatically.
The remediation targeted anything that uses public certificates to authenticate remote endpoints — proxies reaching origins, applications calling external APIs. Shared trust stores, base images and other common foundations were updated at the same time so services inheriting trust from them got a uniform fix, followed by the reloads, restarts and image deployments needed to make it active. Applications carrying bundled or custom trust stores were assessed and updated separately. The flaw is in certificate-based authentication, not in the TLS encryption algorithms themselves.
Further remediation is still underway. Some customers will have to act on software or trust configurations they operate, particularly on origin servers.
Customer actions and developer guidance
| Users of these software or services | Action the customer should take |
| Cloudflare One/WARP | Cloudflare One Client: Upgrade to: v2.5.6 (Android), v1.12.16 (iOS), Windows Desktop (2026.8.2115.0), macOS (2026.8.2115.0), Linux (2026.8.2115.0) 1.1.1.1 app: Upgrade to: v6.38.10 (Android), v6.31.7 (iOS), Windows Desktop (2026.8.2115.0), macOS (2026.8.2115.0), Linux (2026.8.2115.0) |
| Cloudflare Tunnel (cloudflared) | Upgrade to 2026.10.2. For container deployments, update and redeploy the fixed image |
| Customer-configured TLS client authentication | Review and update your mutual TLS trust store/uploaded CAs used to verify client certificates |
| Customer Origin TLS Servers configuration | Review your custom origin certificates and server configurations if using Full (strict) encryption mode or Strict mode. We are updating Automatic SSL/TLS to automatically notify you if you still use these distrusted certificates, which would cause breakages. |
| Cloudflare Containers | Customers using Cloudflare Containers, including Sandboxes, should review their container images and application dependencies for affected certificate trust stores and apply updates based on your deployed image. Customers can also enable HTTPS egress interception to route outbound HTTPS requests through Cloudflare, moving remote-server certificate validation from the application to Cloudflare-managed infrastructure. This allows Cloudflare’s trust-store mitigations to protect intercepted connections. Containers that have this enabled are already protected. |
SDK updates can be misleading. An API client may hand certificate verification to an HTTP library, a language runtime, the OS or a custom trust configuration, so patching the SDK alone may leave the underlying policy unchanged. Once patched, certificate errors may surface in dashboards — do not fix them by turning off verification, since that would strip the authentication protection the updates exist to restore.
Mozilla's Dennis Jackson has crowdsourced a list of commonly used packages that have been patched. Readers should upgrade promptly and check the dependency tree, as some affected packages are indirect dependencies. Apply the dependency updates, rebuild the affected images, and check whether applications need a reload, restart or redeployment.
Jackson's test site offers browser checks, non-browser testing instructions and package update details. Its results describe the verification path under test, not every application on a device. Validate through the application's own TLS path: a passing browser test does not show that a background service is protected, and neither does a curl test if the application uses a different verifier.
Timeline
Date and Time | Event |
October 19, approximately 17:00 UTC | Cloudflare becomes aware of the compromise and begins assessment. |
October 20, 02:00 UTC | Cloudflare One Client and WARP app security updates published across platforms (except Cloudflare One Agent on iOS, for which app review is still pending). |
October 20 09:15 UTC | Cloudflare Tunnel (cloudflared) security update published. |
October 20 19:20 UTC | CDN and server-side Zero Trust mitigations fully deployed. |
Why browsers had it easier
The impact is uneven. Browser maintainers could remediate by flipping a switch — they have just one application to update rather than hundreds, and most browsers use quick-revocation mechanisms such as Chrome CRLSets. Cloudflare uses a similar mechanism in some of its own products. To extend the approach to more Cloudflare systems and the wider industry, Cloudflare points to projects like upki, built on the understanding that a trust store cannot be a static list of root certificate authorities but has to take fast updates covering revocation and certificate transparency keys.
