News

eMudhra: eight intermediate TLS certificate private keys compromised, what to update

Weak private keys on eight eMudhra TLS/code-signing intermediates: risk of forged certificates. Cloudflare has already patched WARP and cloudflared, now sysadmins must check their origins.

UptimeMag editorial team · 21 October 2026 · 2 min read

eMudhra: chiavi private di 8 certificati intermedi TLS compromesse, cosa aggiornare

Cloudflare announced on 20 October 2026 that it had learned, the previous day at 17:00 UTC, of the compromise of private keys associated with eight intermediate certificates issued by eMudhra. Private keys associated with eight eMudhra intermediate certificate authority certificates were compromised, potentially allowing unauthorized parties to create certificates that could appear trustworthy to vulnerable clients. For anyone managing servers, VPNs, reverse proxies or control panels with external-facing TLS, this news directly affects the trust in certificates used daily.

What happened

The anomaly was discovered by an independent researcher. On 17 October 2026, the browser root programs received a report from an independent researcher named Wayne stating that the private keys of eight eMudhra intermediate certificates had been compromised. The problem was not theft, but faulty generation: the keys were generated incorrectly, to the point that anyone can recover them from the certificates themselves. Specifically, the eight compromised private keys were 4, 56, 66, 115, 155, 156, 230 and 237: a private key on the P-384 elliptic curve normally has approximately 384 bits of entropy, but these had between 3 and 8.

eMudhra attributed the defect's origin to a technical step in the key generation ceremony: the eight intermediates were created under its ECC root in a key generation ceremony on 30 April 2025, using FIPS 140-2 Level 3 certified hardware modules, and a defect in that ceremony affected a key wrap and unwrap step.

Cloudflare's response

Cloudflare first updated the services that authenticate to remote endpoints via public certificates, then the shared trust stores. In parallel, it released patches for clients:

Product Action
Cloudflare One Client / WARP Update to Android v2.5.7, iOS v1.12.7, Windows/macOS/Linux 2026.8.2115.0
1.1.1.1 App Update to Android v6.38.11, iOS v6.31.8, Windows/macOS/Linux 2026.8.2115.0
Cloudflare Tunnel (cloudflared) Update to 2026.10.2, redeploy container images
Origin with Full (strict) or Strict Verify custom origin certificates
Containers/Sandboxes Check images and enable intercepted HTTPS egress

The timeline published by Cloudflare indicates three points: security updates for Cloudflare One Client and WARP app released on all platforms on 20 October at 02:00 UTC, the cloudflared update at 09:15 UTC that same day, and completion of mitigations on CDN and Zero Trust server-side at 19:20 UTC.

What server administrators must do

Anyone using Cloudflare in Full (strict) or Strict mode must check their origin certificates and replace them if issued by the compromised intermediates. More generally, on every stack that validates TLS certificates (HTTP libraries, language runtimes, operating system), the trust store version must be verified. Among the server-side packages affected by the incident, according to the list compiled by Mozilla and picked up by multiple security vendors: Go 1.27.3 and 1.26.10, NSS 3.131.1, Python certifi 2026.10.19, Node.js 22.23.4/24.22.1/26.12.1, plus the ca-certificates packages for Ubuntu, Debian and Alpine updated between 16 and 20 October. Cloudflare warns against disabling certificate verification to bypass errors that appear after the update: that would remove exactly the protection that the patch was meant to restore.

Written with the help of artificial intelligence and checked by the editors (EU AI Act, art. 50).