Cloudflare: no interception seen from eMudhra's weak keys, yet over half of large network probes trust them

About 160 of 22,000 handshakes stood out, and Cloudflare says none was interception

Cloudflare says that in the week after it finished adding logging to its outbound proxy on 21 October 2026 it saw about 22,000 attempted handshakes in which a server presented a certificate signed with the weak eMudhra keys. About 160 of them stood out, which is 0.7 per cent of the total (derived: 160 divided by 22,000). Cloudflare's reading, in its post of 30 October 2026, is that even those looked like servers' own default certificates, and it reports "no evidence of the weak keys being used to intercept Cloudflare's connections so far". The post was published at 17:38 UTC on 30 October and was read in full from 11:29 GMT on Saturday 31 October 2026.

That sentence is narrower than it sounds. It is about one company's outbound connections, counted by that company's own logging, over about a week, and it carries its own "so far". The post adds that this "does not exclude carefully targeted interception". It does not say whether anyone anywhere used the keys against a real victim, it does not name an attacker, and it does not count certificates, sites or victims. It also reports that forged certificates appear to have been made within hours of the weakness becoming public, one of them dated 20 October at 18:19 UTC, which is 3 days and 14 minutes after the original report reached the root programs at 18:05 UTC on 17 October (derived, from the reporter's timeline in Mozilla's bug 2083449).

The second half of the post is a measurement of the other side of the connection: which visitors' software still trusts the weak keys. Cloudflare sent probes from its challenge pages, about 50 million over a week, and says more than half of probes across the large networks still accept the compromised chain. It also says the traffic is "highly skewed" by bots, so that figure is not a share of the Internet, and the post gives no single share for the Internet at all. The measurement is explained, and its limits drawn, in the sections below.

One thing to correct at the start. The post's title and standfirst play on the number four, and a reader can take that for four keys. It is not a count of keys. The post says eight keys were weak, and the play is on the value of the weakest one, which the post prints along with the other seven and which this briefing does not repeat. The standfirst also says "any unpatched connection on the Internet that is using eMudhra certificates", while the body narrows the risk to "any domain that an unpatched client not enforcing Certificate Transparency would accept". The diagram below follows the body.

Method and interest. Every figure marked as the post's is read from the post. Cloudflare sells content delivery, security, certificate and Zero Trust products and is the only source for its logging, its probes and its patch dates, so this briefing treats them as its own unaudited account and not as an independent measurement. The key flaw is covered in brief 397 and Microsoft's distrust in brief 481; neither is repeated here. Brief 397's source list differs from the primaries read for this one, so this briefing takes the facts about the keys from the post, Mozilla's bug and the eMudhra and tracker pages it read itself.

What this post adds to the two earlier briefings, and what 'four' counts

The post's own words for the weakness are plain. Where eMudhra "was trusted to pick a 115-digit number" for each key, it picked tiny ones, so that "the affected intermediate private keys could be recovered almost instantly by anyone from the public certificates themselves". Because of that, the post says, this differs from earlier compromised certificate authorities such as DigiNotar, TÜRKTRUST and TrustWave, where access to the keys "has always been contained to a degree". It adds that eMudhra announced it is leaving the public CA business, has claimed a mistake in a key generation script and has not yet shared the script. eMudhra's own status page, last updated 30 October 2026, says "The flaw was ours", describes a voluntary wind down of publicly trusted TLS services, and says it is "not aware of any evidence that the weak keys were recovered or exploited by anyone before the issue was disclosed".

That last sentence matters for reading the Cloudflare numbers. eMudhra speaks of the period before disclosure. Cloudflare's evidence is from after it, when the keys were public knowledge. The two statements do not contradict each other, and neither one covers the other's period.

Zoom

Stated and not stated: the post, line by line

The table sets what the post states against what it does not. "Not stated" means not found in the post as read on 31 October 2026. It does not mean the information does not exist.

What Cloudflare did, and when

The post opens its patching account at 19 October, which is also the date Cloudflare's earlier post of 20 October gives for first hearing of it, at about 17:00 UTC. That is about 1 day and 23 hours after the reporter's email to the root programs at 18:05 UTC on 17 October (derived). The 17 October start comes from Mozilla's bug, not from either Cloudflare post.

Two sentences in the account deserve scepticism, not because they are unlikely but because they cannot be checked. "All high priority Cloudflare systems have been patched" is a status as of a date the post does not give. And the post's remark that lower impact fixes were "due at the end of last week" gives a deadline and not a result. The post also says the outbound proxies were patched "to reject the vulnerable eMudhra keys".

The post puts the time of the bug's publication at less than an hour before the forged certificate. Mozilla's bug page, read for this briefing, shows the reporter's timeline recording that the incident was raised on Bugzilla at 12:06 UTC on 18 October, and it does not state when the bug became publicly visible. This briefing therefore cannot reconcile those two times, and it does not rely on the "within hours" phrase beyond quoting it. One more detail from the same thread: a participant in that bug says 107,107 certificates signed with six of the eight keys were logged to public Certificate Transparency logs between 09:40 UTC on 20 October and 22:02 UTC on 21 October, and calls them proofs of concept (comment 44). That is one participant's count, which brief 481 also reported and this briefing did not check in the logs. It is a different measure from the 22,000 handshakes, and the post does not say whether its 18:19 certificate is among them.

The 22,000 handshakes: what each part is

The post says Cloudflare added logging to Pingora, the outbound service that accounts for "the vast majority of outgoing TLS connections from a Cloudflare machine", so that any server or attacker presenting a certificate signed by the weak keys would trigger a log line. At the time of writing, which the post puts a week later, it had counted about 22,000 such attempted handshakes. Two thirds, which is about 14,700 (derived), were fetches of test sites such as the community tracker's. Almost all the rest, about 7,300 (derived), went to origins that "appeared to set up a certificate for themselves using the weak intermediate".

Zoom

The 160 are the part worth reading closely. The post says their certificates named other organisations' domains, unrelated to the name the connection asked for, some of them domains "related to consumer IoT devices". They were made after the leak, and some were valid "for over two years, longer than any public CA may issue". Cloudflare's reading is that they "looked like the servers' own default certificates rather than part of an attempt to intercept our connections", for two reasons it gives: the names would have failed hostname checks anyway, and in several cases one server showed the same certificate to connections from many Cloudflare locations, which means it came from the server and not from something on one network path. That is a reasonable inference, and it is Cloudflare's. A server presenting a forged certificate as its own default is a different thing from interception, and the post does not say who put those certificates on those servers or why.

Two limits follow from the wording. First, "every handshake configured to verify the certificate was refused". That is a statement about handshakes that were set to verify, and the post does not say how many were not, or what Cloudflare's systems did with those that were not. Second, a refusal in Cloudflare's own proxy says nothing about a customer's other servers, a visitor's browser or any third party. The count measures Cloudflare's side of the connection only.

Where the post stops is also where its logic runs out. It says that to find targeted interception, Cloudflare would "have to rely on the usual indirect signals of system compromise", and that it has seen none. A defender's equivalent is to log, at the point where your systems call out, the certificate chain your peers present, and to look for the same cases: chains through the affected intermediates, names that do not match the name requested, and lifetimes longer than a public certificate may have (these checks are derived from the post's description, and the post publishes no detection rule).

Who still trusts the weak keys: a measurement with limits

Cloudflare says it cannot test whether a visitor trusts the weak keys "without breaking connections", so it measured indirectly. On a fraction of challenge pages it sent two probe connections to its own endpoints, one with an eMudhra signed certificate and one regularly signed as a control, and recorded whether each succeeded. Success on the eMudhra endpoint means the visitor's software accepts the weak chain. With 50 million probes over a week the post says: "Up-to-date modern browsers are mostly patched, but bots and old browsers are not." It adds that embedded browsers such as Android WebView "lag behind patching", with 30 to 40 per cent still accepting, that the first weekend showed clear patching and little movement afterwards, and that across the large networks more than half of probes still accept the chain, with and without bot signals.

Zoom

The post is open about the limits. "by design the traffic to these challenge pages is highly skewed", with "many (unconfirmed) bots in there". Only clients that run JavaScript send probes. After 27 October 18:18 UTC probes ran on 10 per cent of challenge pages on non paying customer zones, up from 1 per cent. The probes disappeared when the challenge platform rolled back on 23 October at 16:30 UTC and returned on 27 October at 10:00 UTC, a gap of 3 days and 17.5 hours (derived), which is why the post calls the first weekend a "monitoring gap". On 29 October at about 18:00 UTC Cloudflare released a bot detection that moved a large influx of traffic identifying as Chrome 150 to 154 on macOS between categories, which can look like patching but is not. For Chrome 150 to 154 on Linux it sees acceptance still falling, which it calls "suggestive rather than conclusive".

Zoom

The chart is Cloudflare's, reproduced above, and a second one by network is below. Read by eye (derived, and not figures the post prints), the overall line in the top panel moves between roughly 35 and 64 per cent over the period, so "more than half" holds for that line for most of the period and not all of it. In the network chart, several lines are well under 50 per cent: one large mobile network's line in the top panel falls to around 20 per cent on 29 October, and in the bottom panel three lines range between about 25 and 55 per cent. The text's "more than half across the large networks" is a generalisation of a chart in which some networks are not. None of this contradicts the post; it shows why a single sentence should not be turned into a single number.

Zoom

The post's closing comment on the numbers is the right one. Bots "are also just software that need security updates", and "if they're in any way representative of overall software updates, then the picture is quite dire indeed". That is conditional. It is also where the practical risk sits for readers: the software that lags is the software nobody watches, which is the fleet of scrapers, agents, build runners, containers and embedded browsers that an organisation owns. Cloudflare's point is that these are the clients a forged certificate would work on.

Three labels that are not controls

"Patched". The post says browsers are mostly patched. The tracker the post points to says the opposite for other software: the developer tools Apple ships with macOS, including git, curl and Python, still trusted the compromised certificates on 28 October 2026, Electron applications pick up a fix only when rebuilt on a patched release, and "updating the operating system or browser may not be enough" for those clients. A patched browser is not a patched estate. The tracker's note on Apple's tools is where that is set out, and the tracker is a community resource, not a vendor statement.

"No evidence". This is a statement about what one company's logs, on its own outbound connections, can show. The post itself says it does not exclude targeted interception and that it is relying on indirect signals. An absence of evidence in the place you looked is not evidence of absence in the places you did not.

"Revoked". eMudhra revoked the eight intermediates on 18 October, as brief 481 records. The tracker's page says many clients "do not consume revocation information", and the Cloudflare post says browsers could act fast through quick revocation mechanisms, such as Chrome's CRLSets, while most other software cannot. A revocation exists on paper for the clients that never read it. The post's closing point, that a trust store "can't be a static list of root certificate authorities", is the same observation made as a product direction, and Cloudflare names a project, upki, that it is excited about; Cloudflare has a stake in quick revocation because it uses it in some of its own products.

Technical details

The post prints no certificate fingerprint of an attacker, no forged certificate, no address and no detection rule, so there is no indicator list to give. What it does print is the shape of its own probe, a timeline of how that probe changed, and one certificate identifier in a link. Cloudflare's earlier post prints the versions of its own software that carry the fix. The incident tracker prints the checks a defender can run. Each block below says what it is, where it was copied from and when it was read; nothing is retyped from memory, and no key value or recovery method is reproduced.

The probe endpoints. The two hostnames the post names for its challenge page probes, defanged here because they are live Cloudflare infrastructure. A defender can use the names to recognise the traffic in a proxy log (derived).

ca1[.]cloudflarecaptcha[.]com
ca2[.]cloudflarecaptcha[.]com

How the probe changed. Anyone comparing Cloudflare's chart with their own data needs these times, because each change moves the line. All times are UTC, copied as printed.

October 23 15:30, we changed our control endpoint to also serve an eMudhra certificate, but this time without signed certificate timestamps (SCTs).
October 23 16:30, our challenge platform rolled back to a previous version because of an unrelated issue. The probes returned October 27 at 10:00.
October 27 16:37, we noticed we did not send the G3 cross-sign, which not all clients knew about, and added it to both endpoints. We removed SCTs from both.
October 27 16:49, we switched ca2 to chain up to the AAA Certificate Services root.
October 27 18:18, we ramped up probes to be included from 1% to 10% of all challenge pages served on non-paying customer zones.

One certificate identifier. The post links a Certificate Transparency search for what it calls the "G3 cross-sign". The link carries a 64 character hexadecimal value, which is copied here from the link target. The post does not say what type of hash it is, and this briefing did not fetch the page it points to.

3094025792039A68AF6E553686410BDAB7C0D4A36B9084CBA64202E35D6EBBDD

The fixed versions Cloudflare published. From the earlier post of 20 October, for Cloudflare's own client software. These are what a customer using those products upgrades to. They are not part of the 30 October post, and the earlier post is the only source for them.

Cloudflare One Client: Upgrade to: v2.5.7 (Android), v1.12.7 (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.11 (Android), v6.31.8 (iOS), Windows Desktop (2026.8.2115.0), macOS (2026.8.2115.0), Linux (2026.8.2115.0)
Upgrade to 2026.10.2. For container deployments, update and redeploy the fixed image

Checking a client yourself. The tracker the post points to serves test hosts whose certificate chains run through the compromised intermediates. A certificate error is the safe result. The first two hosts show whether the client trusts the intermediates at all; the last two use certificates never logged to Certificate Transparency, so a success there also means the client does not enforce it. Run these from the servers, agents, containers and build runners that make outbound calls, and not only from a browser. The tracker's page on Apple's tools also prints a check for git, linked in the sources and not copied here, and an end to end demonstration of exploitation against a mock source host, which is not reproduced.

curl https://dv-g3b-emudhra.we-have-a-problem.com/
curl https://dv-g3b-aaa-emudhra.we-have-a-problem.com/
curl https://dv-g3b-noct-emudhra.we-have-a-problem.com/
curl https://dv-g3b-aaa-noct-emudhra.we-have-a-problem.com/

No exploit, key value or recovery code is reproduced in this briefing, and none is needed to act. The post lists the eight values and this site chose not to print them.

What to do, in order

Items 1 to 4 come first because they find out what you are exposed to; the post's data says the exposure is in software that is not a browser. Items 5 to 8 are the cleanup that follows. Items 9 to 11 are about suppliers and the evidence you keep.

The question this leaves

Cloudflare could test its own outbound proxy, count 22,000 handshakes and say it saw no interception, because it logged at the one point it controls. Where in your estate do certificates get checked by software that nobody has updated, and what would you see in a log if one of those checks accepted a forged certificate?

Key facts