Cloudflare Admits Its Workers AI Sent Customers Each Other’s Data
On October 26, 2026, Cloudflare published one of the most candid incident reports you’ll see from a major cloud provider. Between August 27 and September 9, 2026, its Workers AI service served 155 responses that contained data from other customers’ requests. Every affected response came from the same model — GLM-5.3, the agentic coding model from Chinese lab Z.ai, hosted as @cf/zai-org/glm-5.3 — and every one was an answer to a prompt longer than 681,280 tokens. No hack, no jailbreak, no rogue model. Just plumbing, as one analysis put it — and two failures that had to line up at exactly the wrong moment.
What Cloudflare Disclosed
The report, written by Cloudflare’s Kevin Flansburg and Michelle Chen, is unusually specific. During the exposure window, some customers calling the GLM-5.3 model received responses containing fragments of other customers’ requests made to the same model shortly before theirs. In a service used mainly for coding agents, that data could easily have included source code, documents, or internal notes — though Cloudflare doesn’t say what the leaked fragments contained.
Three important boundaries: Cloudflare found no evidence of deliberate exploitation — apart from its own tests and the researcher’s, the affected requests looked like ordinary long-context usage. No other Workers AI model was affected. And the model itself did nothing wrong; the bug was in the serving infrastructure around it.
Two Failures Had to Line Up
The leak needed two independent problems to coincide, which is why it stayed hidden for two weeks.
Failure one: a silent configuration mismatch. GLM-5.3 was deployed advertising a 1,048,576-token context window — roughly a million tokens per request. But the prefill GPUs’ KV cache pool, the GPU memory that holds a request’s working data while the model reads the prompt, had room for only 681,280 tokens. The pool size isn’t a setting anyone types in: SGLang, the open-source inference engine Cloudflare uses, computes it at startup from whatever GPU memory is left after the model weights load. Nothing forces that number to agree with the advertised context length. So the service promised about a million tokens of room while the hardware could hold roughly 65% of that.
Failure two: a bug in how SGLang handled the overflow. In disaggregated serving — where separate GPU nodes handle reading the prompt (prefill) and generating the answer (decode) — an over-length prompt was supposed to be rejected. Instead, SGLang marked it rejected but didn’t actually abort it: the prefill node generated a KV cache for a 1-token placeholder and forwarded it to the decode node, which mistakenly concluded the previous request’s cache had been overwritten. The decode node then sometimes generated a response from stale cache pages still holding earlier requests’ data.
Either failure alone would have been harmless. Together, any prompt over 681,280 tokens could come back carrying pieces of someone else’s session.
The 24-Hour Response
Credit where it’s due: once alerted, Cloudflare moved fast. Security researcher Gadi Evron of Knostic reported the issue through Cloudflare’s HackerOne program on September 8. On September 9, Cloudflare’s product security team verified the report, declared an incident at 13:22 UTC, and reproduced the leak with two independent accounts within 25 minutes. The model was set private at 14:00 — about 40 minutes after the incident declaration — the corrected configuration was rolled out to every prefill node by 14:52, and public access was restored at 19:40 UTC after validation against the researcher’s own test script.
Then Cloudflare did the slower, harder thing: it worked with the SGLang maintainers on upstream fixes rather than just patching its own deployment. Default protection for this bug class landed in SGLang v0.5.21 (released October 2), and Cloudflare recommends v0.5.22 or later for anyone self-hosting with disaggregated prefill and decode. Only after the fixes were in place did Cloudflare publish the full write-up on October 26, naming its own mistakes in detail.
Were You Affected — and What Should You Take Away?
Cloudflare’s post doesn’t say whether affected customers were individually notified. If you sent prompts longer than 681,280 tokens to GLM-5.3 on Workers AI between August 27 and September 9, it’s worth asking Cloudflare support whether your account was among the 155.
The broader lesson applies well beyond Cloudflare. Advertised context window and provisioned GPU memory are two different numbers, and nothing in the stack guaranteed they matched. Tenant isolation in shared AI infrastructure isn’t something you get for free by using a reputable provider — it’s a property that has to be explicitly designed, measured, and re-verified every time the serving stack changes. If you run inference infrastructure yourself, especially with disaggregated prefill and decode, upgrade SGLang past v0.5.22 and check your own KV pool math. The next mismatch might not get a responsible disclosure first.
Outbound links:
- Cloudflare official incident report
- Cloudflare Workers AI official docs
- Knostic researcher’s write-up
Internal links: