Cloudflare Finds Evidence of eMudhra Certificate Forgery as Unpatched Clients Remain Exposed

On October 19, 2026, Cloudflare learned that eMudhra had issued eight intermediate certificate authority (CA) keys with dangerously weak values. Instead of generating strong cryptographic keys, the affected values were 4, 56, 66, 115, 155, 156, 230 and 237.

The weakness was unusually severe. The private signing keys could be recovered almost instantly from the corresponding public certificates, potentially allowing anyone to create certificates for arbitrary domains that unpatched clients might trust.

Cloudflare initially published guidance on its immediate mitigation measures and actions required from customers. In a follow-up investigation, the company has now shared evidence of attempted exploitation, progress in patching its own infrastructure and observations about visitors who may still trust the compromised certificate chains.

The findings include approximately 22,000 attempted TLS handshakes involving the weak eMudhra keys. Cloudflare also identified around 160 certificates with domain names unrelated to the requested server names. However, the company has not found evidence that the weak keys were used to intercept its connections.

Why the eMudhra Weak-Key Incident Is Different

Certificate authorities play a central role in Internet security. They issue digital certificates that help browsers and other clients verify the identity of websites and establish trusted connections.

The eMudhra incident involved eight intermediate CA private keys with extremely weak values. According to Cloudflare, the affected keys could be independently recovered from their public certificates.

This creates a serious trust problem. Anyone who obtains the private signing keys can generate certificates for domains they do not control. A client that still trusts the affected certificate chain and does not enforce Certificate Transparency could accept such a certificate, depending on its validation rules and configuration.

Cloudflare described the incident as fundamentally different from previous CA compromises, including DigiNotar, TÜRKTRUST and TrustWave. In those earlier cases, access to compromised signing keys was more limited. In the eMudhra incident, the affected intermediate keys could be recovered by anyone.

eMudhra announced that it was exiting the public CA business and attributed the weakness to a mistake in a key-generation script. However, the company had not shared that script in the announcement discussed by Cloudflare.

Cloudflare also noted an issue involving certificate revocation lists (CRLs). A CRL was initially signed with what might have been a correctly generated key, then corrected to use the weak key.

The company said further questions remain about the incident, including the roles of auditors and cross-signers.

Cloudflare Patched Its High-Priority Systems

Cloudflare began remediation on October 19, the day it learned about the weak keys.

The priority was high-impact infrastructure, including customer origin-facing proxies using Pingora. These proxies handle most of Cloudflare's outbound connections.

Cloudflare updated these systems within hours to reject certificates signed using the vulnerable eMudhra keys.

At the same time, the company used AI-assisted source-code analysis to identify other systems that trusted the affected keys. Cloudflare said it completed the analysis within four hours, creating preliminary remediation tickets for the identified systems.

Teams were asked to confirm or adjust the analysis. High-impact systems were prioritised for immediate patching, while lower-impact remediation was scheduled for the end of the following week.

At the time of publication, Cloudflare reported that all high-priority systems had been patched. A small number of confirmed low-impact tickets were still being addressed.

Cloudflare Observed Around 22,000 Attempted Handshakes

To investigate possible exploitation, Cloudflare added logging to Pingora, its outbound proxy service.

Because Pingora handles the vast majority of outgoing TLS connections from Cloudflare machines, the logging was designed to detect when a customer server or another endpoint presented a certificate signed using one of the weak eMudhra keys.

The logging rollout was completed on October 21.

During the following week, Cloudflare recorded approximately 22,000 attempted TLS handshakes involving the affected keys.

The company explained that roughly two-thirds of these attempts involved test sites, including emudhra.we-have-a-problem.com, which had been referenced in its earlier developer guidance.

Almost all of the remaining attempts involved origin servers that appeared to have configured certificates using the weak intermediate CA.

Cloudflare said every handshake configured to verify the certificate was rejected because its systems had already been patched.

Around 160 Certificates Raised Additional Concerns

Among the observed handshakes, approximately 160 stood out.

The certificates presented in these connections contained Subject Alternative Names (SANs) identifying domains belonging to other organisations. These names did not match the Server Name Indication (SNI) requested during the TLS handshake.

Some of the domain names were associated with consumer Internet of Things devices.

Cloudflare also found that the forged certificates had been created after the weak keys became public. Some were valid for more than two years, exceeding the maximum validity period permitted for public CA-issued certificates.

However, Cloudflare's analysis did not establish that these certificates were being used to intercept its connections.

The certificates appeared to be default certificates configured on the servers themselves. They named domains unrelated to the requested connections and would therefore have failed hostname verification. In several cases, the same certificate was presented to connections from multiple Cloudflare locations, suggesting that the certificate originated from the server rather than from an attacker positioned on an individual network path.

Cloudflare reported that at least one forged certificate was dated October 20 at 18:19 UTC, less than an hour after Mozilla's bug report became public.

This provides evidence that the weak keys were used to create certificates shortly after the vulnerability became public. However, Cloudflare said it had not found evidence of the keys being used to intercept its connections.

The company also cautioned that carefully targeted interception could not be ruled out. Its investigation had not identified indirect signals of such system compromise at the time of publication.

Older Browsers and Embedded Clients Still Accept the Weak Chain

Cloudflare also investigated how many visitors might still trust certificates signed using the compromised eMudhra keys.

Directly testing whether a visitor trusts a weak certificate could disrupt the connection. Instead, Cloudflare used a measurement method based on its challenge pages.

The company added two probe connections to a fraction of challenge pages. One connected to ca1.cloudflarecaptcha.com, while the other connected to ca2.cloudflarecaptcha.com.

Initially, the first endpoint presented an eMudhra-signed certificate. The second used a regularly signed certificate as a control. Cloudflare then recorded whether the connections succeeded.

Over the following week, the company collected approximately 50 million probes.

However, Cloudflare highlighted an important limitation: traffic reaching challenge pages is highly skewed and includes many unconfirmed bots. Only clients that execute JavaScript, such as browsers, send the probes. The results therefore cannot be treated as a representative measurement of all Internet users or devices.

Probe Configuration Changes Affected the Measurements

Cloudflare documented several changes to its testing setup:

• October 23, 15:30 UTC: The control endpoint was changed to also serve an eMudhra certificate, but without signed certificate timestamps (SCTs).

• October 23, 16:30 UTC: The challenge platform rolled back to an earlier version because of an unrelated issue. Probes resumed on October 27 at 10:00 UTC.

• October 27, 16:37 UTC: Cloudflare noticed that the G3 cross-sign was missing and added it to both endpoints. SCTs were removed from both.

• October 27, 16:49 UTC: The second endpoint was switched to chain up to the AAA Certificate Services root.

• October 27, 18:18 UTC: Probe coverage increased from 1% to 10% of challenge pages served on non-paying customer zones.

These changes are important when interpreting the measurements because certificate-chain configuration and probe coverage affect which clients are included and whether they accept the presented certificates.

Modern Browsers Show Better Patching Progress, but Gaps Remain

Cloudflare reported that up-to-date modern browsers were mostly patched, while older browsers and bots continued to show acceptance of the weak certificate chain.

Embedded browsers, including Android WebView, showed a notable gap, with approximately 30% to 40% still accepting the affected chain in the observed sample.

Cloudflare saw evidence of patching over the first weekend, although its monitoring had a gap during that period. Afterward, the company observed little movement in the overall results.

A change in bot detection also affected the interpretation of the data.

On October 29 at around 18:00 UTC, Cloudflare deployed a detection that identified a large influx of bot traffic presenting itself as Chrome 150-154 on macOS. This initially appeared to indicate improved patching in the top-level browser data. However, the same user agents showed a corresponding increase in acceptance among traffic with detected bot signals.

Chrome 150-154 on Linux was a notable exception. Its acceptance rate continued to decline, which was consistent with further patching in that group. Cloudflare described this evidence as suggestive rather than conclusive because the traffic mix was heavily affected by bots and changing classifications.

Large Networks Still Show Significant Exposure

Cloudflare also analysed the results by Autonomous System Number (ASN), which identifies networks on the Internet.

Across the large networks included in the analysis, more than half of the probes still accepted the compromised certificate chain. This was observed both among traffic without detected bot signals and among traffic with bot signals.

The company saw some patching over the weekend, but the trend was largely flat afterward.

Cloudflare reiterated that the sample was skewed by unconfirmed bots. It nevertheless noted that bots are software systems that also require security updates.

What Organisations and Developers Should Do

Cloudflare's recommendation is straightforward: patch systems that still trust the compromised certificate chain.

The company points readers to a crowdsourced website maintained by Dennis Jackson, which provides instructions for updating affected systems. Cloudflare particularly highlights the need for macOS developers to follow the available guidance.

Cloudflare customers should also review its earlier guidance on actions required when using products such as WARP and Tunnel.

For organisations, the findings highlight why certificate trust stores need to be maintained across more than just desktop browsers. Older browsers, embedded clients, bots and other software that establish TLS connections can also require security updates.

The challenge is not limited to identifying vulnerable systems. Organisations need to understand which applications and devices rely on the affected certificate chain and ensure that updates reach those environments.

Cloudflare Highlights the Need for Faster Certificate Trust Updates

Looking ahead, Cloudflare pointed to its existing quick-revocation mechanism in some products and its interest in extending this capability to more systems.

The company also highlighted projects such as upki, which approach trust stores as systems that need to support timely updates rather than remaining static lists of trusted root certificate authorities.

Such systems could incorporate information related to certificate revocation and Certificate Transparency keys.

The broader issue is the speed at which trust decisions can be updated after a certificate authority compromise. A weak or compromised signing key can create risks beyond the systems operated by the CA itself. Every client that continues to trust the affected certificate chain may remain exposed until its trust configuration is updated.

Conclusion

Cloudflare's follow-up investigation provides evidence that eMudhra's weak intermediate CA keys were used to create forged certificates shortly after the weakness became public. The company recorded approximately 22,000 attempted TLS handshakes involving the affected keys and identified around 160 certificates with suspicious domain names.

However, Cloudflare reported no evidence that the keys had been used to intercept its connections. Its patched systems rejected the certificate chains, while its visitor measurements showed that older browsers, bots and embedded clients continued to accept them in the observed sample.

The findings underline the importance of timely certificate updates across browsers, embedded software and other TLS clients. Patching the certificate authority itself is not enough. Systems that continue to trust compromised keys must also update their trust configuration.