SNACK: 3-line summary
- Cloudflare’s eMudhra follow-up reports forged certificates appearing less than an hour after public disclosure.
- Its challenge-page sample showed embedded-browser patching gaps, though the traffic was heavily skewed by suspected bots.
- Cloudflare found no evidence that its connections were intercepted; users and operators should check updates beyond the main browser.
Cloudflare’s October 30 follow-up on eMudhra’s weak signing keys reports forged certificates and lingering exposure in embedded browsers. The findings give users a reason to check the components that open pages inside apps, even when their main browser is current.
Snackgirls react
AIKO: A familiar HTTPS indicator doesn’t tell me which trust store made the decision. I’d like to trace that choice across the browser and the components inside apps.
Nea: If I opened a character wiki inside a chat app, I’d probably be thinking about the lore. I’d like to know which browser component would be handling that page.
Forgeries appeared within an hour
Cloudflare learned about eMudhra’s eight weak signing keys on October 19. Its new report says one forged certificate was dated less than an hour after Mozilla’s bug report became public on October 20.
With its outbound TLS logging fully deployed on October 21, Cloudflare went on to observe about 22,000 connection attempts presenting certificates signed with the weak keys. About two-thirds were visits to test sites; most of the remainder appeared to involve servers using certificates they had issued for themselves. These were not 22,000 confirmed attacks.
About 160 attempts stood out because the certificates named other organizations’ domains rather than the requested hostname. They looked like the servers’ default certificates and would have failed hostname verification. Cloudflare found no evidence that the keys had been used to intercept its connections, although carefully targeted interception could not be ruled out.
WebView lagged in a bot-heavy sample
Cloudflare sent pairs of probe connections from a subset of its security challenge pages, recording about 50 million probes over the preceding week. That is a count of measurements, not 50 million distinct people, devices or victims.
In Cloudflare’s sample, embedded browsers such as Android WebView still accepted the compromised certificate chain in 30–40% of the relevant measured traffic. The sample was heavily skewed by suspected bots and included only clients that executed JavaScript, so that figure does not describe all Android phones. Cloudflare said up-to-date modern browsers were mostly patched, while older browsers and bots lagged.
Changes to the measurements also matter when reading the charts: an unrelated rollback interrupted probing between October 23 and 27, and later changes affected the certificate chains and sampling rate. On October 29, a bot-detection change moved traffic between categories, creating an apparent improvement that did not represent patching. The network breakdown shares the same bot-heavy sampling limitation.
Check what handles each connection
Check official updates for your browser, operating system and apps, including Android System WebView where applicable. An up-to-date Chrome installation does not establish that every app’s embedded browser is also patched.
Service operators should also check the certificate trust stores their software actually uses, including command-line tools and other applications. A browser update does not establish that those separate components have received the necessary changes.
At the time of the report, Cloudflare said all its high-priority systems were patched, with a small number of low-impact fixes still in progress. For customers using products such as WARP or Tunnel, the follow-up points to product-specific guidance in its earlier incident post.
Sources and checked date: October 31, 2026
Comments
0No login needed. Edit or delete your comment from the same browser.
All comments 0
한국어 · English · 日本語No comments yet. Start the conversation.