- Cloudflare says eMudhra's weak keys let anyone forge certificates that unpatched clients not enforcing Certificate Transparency accept. It has seen no evidence of interception so far.
- In Cloudflare's bot-heavy probe traffic, modern browsers were mostly patched. On large networks, over half of probes still accepted the compromised chain.
- Ask your team which systems keep their own list of trusted certificate authorities, and who updates that list.
A lock whose combination was the number 4
On October 19, 2026, Cloudflare learned that eight signing keys held by eMudhra were badly weak. eMudhra is a certificate authority, a company that browsers and servers trust to vouch for websites. Each key should have been a 115-digit number. Cloudflare says one of them was the number 4.
The other seven keys were just as tiny. According to Cloudflare, the largest was 237. Numbers that small are easy to find by guessing.
Cloudflare calls the incident unprecedented. It says earlier compromised authorities, such as DigiNotar, TÜRKTRUST and TrustWave, gave only a limited set of attackers the power to forge certificates. Here, Cloudflare says anyone can recover the keys almost instantly from the public certificates.
How the failure works
A certificate authority's private key is its stamp of approval. Whoever holds the stamp can issue a certificate for any website name. A client that trusts the authority will accept it.
Here anyone can rebuild the stamp. Cloudflare says forged certificates for any domain would work on clients that are unpatched. Those clients would also need to skip Certificate Transparency checks. Certificate Transparency is a system of public logs of issued certificates.
eMudhra says it is leaving the public certificate business. It blames a mistake in a key generation script. Cloudflare says the script has not been shared.
Cloudflare adds that eMudhra signed a revocation list with what may have been a properly made key. A revocation list is a published list of cancelled certificates. The list was then corrected to use the weak key. Cloudflare says much is still unexplained, including the roles of auditors and cross-signers.
Cloudflare moved fast on its own systems
Cloudflare began patching high-impact systems on October 19. These included the Pingora proxies, which handle most of its outbound connections. Those were patched within hours to reject the weak keys.
At the same time, Cloudflare ran an AI-assisted review of its source code to find every other system that trusts the keys. It had a full list within four hours. Each system got a ticket. High-impact items were to be patched immediately. Lower-impact items were due by the end of the previous week, according to Cloudflare's October 30 post. The company says a few confirmed tickets of minor impact are still being worked.
Logging of connections that use the weak keys finished rolling out on October 21. A week later, Cloudflare had counted about 22,000 attempted connections that used them. Two-thirds were fetches of test sites. Nearly all the rest went to servers that seemed to have made certificates for themselves from the weak intermediate key. Every connection set up to verify certificates was refused.
About 160 connections stood out. Their certificates named other organizations' domains, some tied to consumer IoT devices. One of those certificates carried an issue time of 18:19 UTC on October 20. That was under an hour after Mozilla made its bug report public.
In Cloudflare's assessment, someone forged certificates with the weak keys within hours of the flaw going public. It does not read these as interception. The names did not match the sites being contacted. Several servers also showed the same certificate to many Cloudflare locations, which suggests they were the servers' own defaults. Cloudflare found no evidence of interception so far. It adds that this does not rule out carefully targeted attacks.
Outside Cloudflare, patching is slower
Cloudflare could not test visitors directly without breaking their connections. Instead, it added two probe connections to a fraction of its challenge pages. These are the checks that separate people from bots. One endpoint used an eMudhra-signed certificate. The other used a normal certificate as a control.
Over a week, Cloudflare recorded 50 million probes. Up-to-date modern browsers were mostly patched. Bots and old browsers were not. Embedded browsers such as Android WebView lagged, with 30 to 40 percent still accepting the weak chain.
On the largest networks, over half of the probes still accepted the bad chain. Traffic flagged as bots and traffic not flagged both showed this. Cloudflare saw some patching over the first weekend, then a flat trend.
The limits matter. Cloudflare says the traffic is skewed toward unconfirmed bots. Only clients that run JavaScript send probes. It also changed the test setup several times. A bot detection change on October 29 can look like patching. Cloudflare's own verdict is that bots are software that needs updates. If they represent software overall, it says, "the picture is quite dire indeed."
The lesson: a trust list is a patch target
This shows that a list of trusted authorities is not a fixed fact. It is software, and it ages like software.
Cloudflare patched the Pingora proxies within hours. In parallel, its code review found the other systems that trust the keys within four hours. Our argument is that this kind of response depends on knowing where trust lives. The source does not claim that link itself.
Cloudflare's bot data suggests the long tail may include software no one tracks. That is our inference. The probes cannot see clients that do not run JavaScript.
Cloudflare points to projects like upki. They treat a trust store as something that can be updated fast with revocation data and certificate transparency keys. In effect, an authority's failure should not wait for the next software release.
What leaders should ask
First, ask your team which systems make outbound TLS connections, and who owns each one's trust list. Cloudflare's approach is a useful model: one ticket per system, with high-impact ones fixed first.
Second, ask about embedded and older clients. Cloudflare saw bots, old browsers and embedded browsers such as Android WebView lagging. Internal tools are our own suggestion to check. Cloudflare's probes could not observe them.
Third, ask whether your clients enforce Certificate Transparency. Cloudflare says unpatched clients that skip that check are the ones that would accept forged certificates. Developers on macOS should follow Dennis Jackson's crowdsourced patching instructions. Cloudflare customers using WARP or Tunnel should read Cloudflare's earlier guidance.
One of the broken keys was the number 4. In Cloudflare's probes, patching clients was far slower, and that gap is the risk to plan for.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Cloudflare.
Follow this story: every update on eMudhra certificate compromise
