Cloudflare Leaked One Customer’s Prompts Into Another’s AI Replies for 13 Days, and the Trigger Was a Cache Ceiling It Knew About
Cloudflare says 155 responses from GLM-5.3 on Workers AI contained other customers' KV cache data between 27 August and 9 September 2026. The trigger was a cache pool it knew was too small.
Cloudflare has confirmed that its Workers AI platform returned fragments of one customer’s session to other customers, 155 times, over 13 days. The affected model was GLM-5.3, and the trigger was a cache pool smaller than the context window Cloudflare advertised.
Cloudflare disclosed it on 26 October 2026, more than six weeks after the fix. Exposure ran from the model’s 27 August launch to 9 September, when a researcher’s report forced Cloudflare to take GLM-5.3 offline and rebuild the serving stack around it.
Every affected response went to a prompt longer than 681,280 tokens. It was not a general breach of the platform, but it was not a theoretical bug either.
Quick answer: Cloudflare did leak data between customers on Workers AI, but the blast radius was narrow. 155 responses to very long prompts on one model contained KV cache pages left behind by earlier requests. Cloudflare says it found no deliberate exploitation, fixed the engine, and published the post mortem alongside the SGLang maintainers on 26 October 2026.
What actually leaked
The KV cache is the working memory a model uses to hold a prompt while it generates a reply. On GPU it is a pool of fixed size pages, and pages are reused rather than wiped between requests, so the engine must track who owns each page.
In this incident that tracking broke. Responses to very long prompts were built partly from pages that still held earlier customers’ prompts and partial generations. The reply arrived as a normal HTTP 200, with a matching prompt token count and text that read coherently enough to look like an answer.
The report came from Gadi Evron of Knostic, filed through Cloudflare’s HackerOne programme at 23:11 UTC on 8 September. Cloudflare reproduced it with two independent accounts within 25 minutes of declaring an incident the next day, pulled the model at 14:00 UTC, and restored it at 19:40 UTC. The Cloudflare post mortem has the full timeline.
Two bugs, one cache ceiling
Cloudflare served GLM-5.3 with a context window of 1,048,576 tokens, but the prefill GPU pool could hold only 681,280 tokens. The pool is sized automatically at startup from leftover GPU memory, and nothing forces it to match the context length the model advertises.
The company knew about the mismatch before launch. It expected SGLang, the open source inference engine underneath, to reject anything that did not fit.
SGLang did reject those requests, but in disaggregated prefill and decode mode the rejection did not stop the handoff. The prompt was swapped for a one token placeholder, prefill generated a trivial cache for that placeholder, and the decode node was told the transfer was complete. Decode then reserved and read pages that this request never wrote.
That bug was not new. It had been reported to SGLang as issue #30233 on 6 July 2026 by another user. Cloudflare says it found that report while investigating its own incident.
| Item | Before the fix | After the fix |
|---|---|---|
| Configured context window | 1,048,576 tokens | 1,048,576 tokens |
| Prefill KV cache pool | 681,280 tokens | About 2.04 million tokens |
| Pool against context | About 65% of context | About twice the context |
| Prompt above the pool | HTTP 200 with stale pages | Rejected before the handoff |
| Rejection handling | Admitted to the decode queue | Retired at admission |
| SGLang release | Before v0.5.20 | v0.5.22 or later |
| Other Workers AI models | Not affected | Not affected |
The part Cloudflare admits
The mismatch was a known risk that testing did not catch. Cloudflare says its long context benchmarks checked HTTP status codes, streaming behaviour and throughput, but never checked whether the words coming back made sense.
“We only validated HTTP response codes and engine performance at long contexts, without validating model output and coherence,” the report states. The company now measures pool size against context length on the running engine before any deployment ships.
How wide is 155 responses?
Wide enough to matter, narrow enough to stay out of most people’s way. The threshold was 681,280 tokens. A typical chat message is a few hundred tokens, so normal users never reached it.
Agentic coding sessions do reach it. GLM-5.3 is built for long, tool driven development work, and a session that reads a large repository and keeps the transcript can climb past that.
Cloudflare says the timing and volume of the affected requests matched ordinary long context use, not someone hammering the endpoint. The SGLang disclosure published the same day confirms the mechanism and the fix window.
The fix, and what is still missing
Cloudflare fixed both layers. It raised the prefill pool to roughly 2.04 million tokens, twice the context window, so a valid request can no longer hit the rejection path. It also patched the engine so a rejected request is retired before any allocation or transfer.
The engine fixes went upstream across three releases. SGLang v0.5.20 carried the core fix, v0.5.21 added earlier rejection at admission, and v0.5.22, released on 19 October, closed a batch of related KV cache lifetime races. Cloudflare recommends every operator running disaggregated SGLang move to v0.5.22 or later.
Three harder guards remain unfinished. Per transfer checksums do not cover every architecture. Cloudflare’s page level tagging prototype, which would fail a request that reads a page it does not own, cost under 1% in throughput and tail latency in August tests but was disabled for reliability issues.
Formal verification of the transfer protocol is the long term plan. Configuration checks reduce the number of ways a page can be misused, they do not make misuse impossible.
Confirmed vs not confirmed
| Claim | Status |
|---|---|
| 155 responses contained other customers’ data | Confirmed by Cloudflare |
| Exposure ran from 27 August to 9 September 2026 | Confirmed in the timeline |
| All affected prompts exceeded 681,280 tokens | Confirmed by Cloudflare |
| GLM-5.3 was the only model affected | Confirmed by Cloudflare |
| Cloudflare knew the pool was undersized before launch | Confirmed in the report |
| Researcher was Gadi Evron of Knostic | Confirmed by Cloudflare |
| Number of customers affected | Not confirmed, described only as small |
| What specific data appeared in the 155 replies | Not confirmed, no examples published |
| Whether each affected customer was notified | Not confirmed |
| Deliberate exploitation | No evidence found, which is not proof it did not happen |
| Page level tagging in production | Not shipped, prototype only |
What it means for Indian developers
Most Indian teams use Workers AI because it removes GPU operations from the equation. This incident is a reminder that multi tenancy is still your problem even when someone else runs the hardware. The cache your prompt lands in was used by a stranger seconds earlier.
For teams handling personal data, the DPDP Act 2023 makes the question sharper. Inference on Cloudflare’s global network is a cross border transfer, and a leak that returns another customer’s data has to be assessed for notification. Ask vendors for their cache isolation model in writing, not just their uptime numbers.
Measure KV pool against context length on every node. Run deferred release on both prefill and decode. Bound transfer batches so one timed out call cannot leave writes in flight. Turn on checksums and canaries where the model supports them.
If you self host SGLang, pin to v0.5.22 and stop trusting status codes as a test signal. The same lesson shows up in DeepSeek’s DeepInfer release, where the KV cache and load balancers were left out of the open source package entirely.
The isolation tax looks affordable at under 1%. Cloudflare’s real problem was not the cost of the guard. It was shipping without one, on a configuration it already knew was mismatched. For a wider view of Cloudflare’s platform, see our coverage of Clef and Clef-flash on Workers AI.
FAQ
Did Cloudflare customers see other people’s prompts?
Yes, in 155 responses between 27 August and 9 September 2026. Replies could include earlier customers’ prompts and partial generations.
Was GLM-5.3 the only affected model?
Cloudflare says yes. Every other Workers AI deployment had a KV pool larger than its context length, so no request reached the rejection path.
Is the bug fixed in open source SGLang?
The core fix shipped in v0.5.20, with follow ups through v0.5.22. Operators on older builds, especially those running disaggregated prefill and decode, should upgrade and verify pool size.
Should you stop using long context models on shared APIs?
No blanket rule follows. Ask how the provider isolates cache pages, whether it runs checksums, and whether its tests check output as well as status codes.
Did anyone exploit the leak deliberately?
Cloudflare found no evidence of that. It says the requests matched ordinary long context use in timing and volume, though absence of evidence is not proof.
Sources
- Cloudflare, “Cross-request KV cache exposure in the GLM-5.3 Workers AI model, and our remediation with SGLang”, 26 October 2026. blog.cloudflare.com
- LMSYS Org and SGLang Team, “SGLang security update: improving request isolation”, 26 October 2026. lmsys.org
- SGLang issue #30233, reported 6 July 2026. github.com
- SGLang pull request #38935, rejection at admission, merged for v0.5.21. github.com
- Cloudflare HackerOne programme, disclosure channel for Workers AI issues. hackerone.com