Original announcement: Cloudflare · 2026-10-30. Read the official announcement.
Summary of the Incident
On October 19, 2026, Cloudflare disclosed that certificate authority eMudhra used critically weak private keys — including a key literally equal to the number 4 — undermining the security of TLS connections for certificates issued by eMudhra. Unlike typical CA compromises that require privileged attackers, these keys could be recovered instantly by anyone using public certificates. The weak keys allowed forgery of potentially valid TLS certificates for any domain trusted by eMudhra’s infrastructure.
Cloudflare’s Immediate Actions and Findings
Cloudflare responded quickly by patching all high-risk internal systems within hours of discovery. This included customer-facing proxies and outbound TLS connections that would otherwise trust eMudhra certificates.
- Logging was added to monitor attempts using weak eMudhra keys starting October 21.
- About 22,000 handshake attempts involving weak keys were detected in the following week.
- Approximately two-thirds of these attempts targeted test sites mentioned in Cloudflare guidance.
- About 160 attempts showed certificates with forged Subject Alternative Names unrelated to the accessed domain, indicating certificate forgery attempts.
- All such forged certificates failed hostname verification, blocking intercept attempts.
- No evidence was found that the weak keys were used to intercept or compromise Cloudflare’s core network connections.
Ongoing Risks for Internet Users and Devices
Despite Cloudflare’s internal patching, many Internet visitors and devices remain vulnerable due to trust in the compromised eMudhra keys:
- Cloudflare used challenge pages to indirectly measure which clients still accept the weak eMudhra certificates.
- Data from 50 million probes shows that modern browsers are mostly patched, but older browsers, bots, and embedded browsers such as Android WebView still trust the weak keys at rates of 30-40% in some cases.
- Network analysis indicates that more than half of probes from large networks still accept compromised chains.
- Bot traffic skews data but also reflects an important component of software needing updates.
What Developers and Organizations Should Do
Developers, sysadmins, and organizations should consider the following steps due to ongoing exposure:
- Verify trust stores and certificate validation: Check whether your systems accept eMudhra-issued certificates anchored in the weak keys.
- Apply OS and browser updates promptly: Many platforms have or will release patches removing or distrusting the weak keys.
- Revoke and replace any certificates issued by eMudhra’s weak intermediates: To prevent misuse from certificate forgery if you hold such certificates.
- Monitor network logs for anomalous TLS handshakes: Look for handshakes presenting suspicious or unexpected certificates.
- Follow guidance from Cloudflare and trusted security sources: For specific patching instructions, especially on clients like macOS and embedded devices.
Looking Ahead: Improving CA Trust Management
The eMudhra incident highlights systemic issues with static trust stores and slow revocation processes. Cloudflare and industry efforts like the upki project aim to build trust stores that can rapidly incorporate revocation and transparency data to better respond to vulnerabilities in certificate authorities.
Summary Checklist for Developers
- Confirm client and server trust stores do not accept eMudhra weak keys.
- Update all affected platforms and software promptly.
- Identify and replace any certificates chained to weak eMudhra intermediates.
- Implement enhanced monitoring for unusual TLS certificates and handshake behaviors.
- Stay alert for further developments and patches from certificate authorities and security vendors.
