Cloudflare says it found forged eMudhra certificates
Cloudflare says about 22,000 weak-key connection attempts included about 160 naming unrelated domains, with no evidence its connections were intercepted. It reports 30–40% acceptance among embedded-browser probes in a bot-heavy, JavaScript-only sample and urges updates.

In this article
Cloudflare, the sole source for these findings, said in its October 30 update that it had observed certificates forged using eMudhra’s weak signing keys, but found no evidence that anyone had used them to intercept its connections. Its separate browser tests showed that some software still accepted the compromised certificate chain.
The network operator began patching on 19 October after learning that 8 intermediate signing keys belonging to eMudhra were compromised. eMudhra is a certificate authority: it issues digital certificates that software checks to verify a server’s identity. The affected certificates were widely trusted by browsers, operating systems and Cloudflare’s own systems. Cloudflare said its main proxies connecting to customers’ servers were patched within hours.
Cloudflare said anyone could recover those private signing keys almost instantly from the public certificates and use them to create certificates for any domain. Unpatched clients that still trust the keys and do not enforce Certificate Transparency could accept the forgeries. Certificate Transparency uses public certificate logs, with signed timestamps providing evidence of submission; enforcing that requirement can block forgeries lacking the required proof. The weakness affects server authentication, not the encryption algorithms protecting a connection.
What the connection attempts show
Cloudflare recorded about 22,000 attempted TLS handshakes presenting certificates signed with the weak keys after its Pingora logging finished rolling out on 21 October. A TLS handshake is the opening exchange used to establish an encrypted connection and check the server’s identity. Pingora handles the vast majority of Cloudflare’s outbound TLS connections, rather than every connection.
Two-thirds of the attempts fetched test websites. Almost all of the remaining third reached origin servers—the customers’ servers Cloudflare connects to—that appeared to have configured their own certificates using the weak intermediate keys. Every handshake configured to verify the certificate was rejected because Cloudflare had already patched its systems.
About 160 handshakes presented certificates naming other organizations’ domains, unrelated to the hostname requested in the connection. That is a count of handshakes, not distinct certificates. Some names related to consumer internet-connected devices. Cloudflare said these looked like the servers’ default certificates: the mismatched names would have failed hostname verification, and several servers presented the same certificate to connections from many Cloudflare locations.
One forged certificate was dated 20 October at 18:19 UTC [22:19 Yerevan time], less than an hour after Mozilla’s bug report became public. Cloudflare treated that timestamp as evidence of forgery soon after disclosure, not interception. The company said its observations could not exclude carefully targeted interception, although it had also seen no indirect signals of system compromise.
What the browser tests measure
Cloudflare tested certificate acceptance indirectly by adding paired connection probes to a fraction of its challenge pages. Initially, one endpoint presented an eMudhra-signed certificate and the other used a normally signed certificate as a control. The company recorded which connections succeeded.
The measurements covered 50 million probes over the preceding week, but the sample was highly skewed toward suspected bots and included only clients that executed JavaScript. Within that sample, Cloudflare said 30–40% of embedded-browser probes, including browsers such as Android WebView, still accepted the compromised chain. That rate does not measure all embedded-browser users or internet users. Updated modern browsers were mostly patched, while older browsers and bots lagged.
An unrelated rollback interrupted the probes from 23 October to 27 October. Cloudflare also changed certificate chains, removed Certificate Transparency timestamps and increased the share of challenge pages receiving probes. An October 29 bot-detection change moved traffic between classifications and could look like patching in the graphs even though it was reclassification. Cloudflare said it saw evidence of patching over the first weekend, despite the monitoring gap, but little movement afterward.
Updates and trust checks still needed
Cloudflare said all its high-priority systems were patched, while work continued on a small number of confirmed low-impact remediation tickets. Its earlier October 20 guidance announced client and Tunnel updates alongside mitigations across its content-delivery, developer and Zero Trust products.
For customers, Cloudflare recommends updating Cloudflare One/WARP clients to the fixed platform-specific releases and Cloudflare Tunnel to 2026.10.2. Container deployments should update and redeploy the fixed image. Customers should also review custom origin certificates, strict-mode server settings and trust stores—the lists of certificate authorities their software accepts—including those used to verify client certificates and those bundled into application dependencies.
Cloudflare advises testing the certificate checks each application actually uses. A browser and a background service may rely on different libraries, operating-system settings or custom trust stores, so a passing browser test does not establish that every application on the device is protected. The company warns against disabling certificate verification to clear errors after patching, because that removes the authentication protection the updates restore.
Cloudflare said eMudhra had announced its exit from the public certificate-authority business and attributed the weak keys to a mistake in a key-generation script. eMudhra had not shared the script, and Cloudflare said questions remained about the auditors and the certificate authorities that cross-signed its certificates, extending trust to them.
Cloudflare proposes extending quick-revocation mechanisms already used in some products to more systems. Those mechanisms would let software rapidly update which certificates and authorities it trusts, including revocation and Certificate Transparency information. Cloudflare said lower-impact remediation had been due by the end of the preceding week, but a small number of confirmed low-impact tickets remained in progress.
Earlier in Technology
InfrastructureAmazon spends $77.3 billion on capital projects in third quarter
Cloud revenue rose 39% to $45.98 billion, while capital spending topped last year’s $35.1 billion and analysts' $58.7 billion estimate. CEO Andy Jassy reiterates a roughly $220 billion cash-spending forecast for 2026, mostly for Amazon Web Services.
3 min
SoftwareBinance says it has reserved over $6,340,000,000 after $6.3 billion theft
Binance says 80% of the stolen assets have been secured, which does not mean customers have been repaid. The exchange promises public verification of user funds.
2 min
CompaniesInfineon plans €1.1 billion chip investment in Villach
The investment through 2034 would fund high-volume production of gallium nitride power chips on 300mm wafers.
2 min
