Security/ cloudflare · workers-ai · sglang · llm-security

Cloudflare AI Model Leaked Other Users' Data in 155 Responses

A mismatch between cache size and context window, plus an SGLang bug, let very long prompts pull in other customers' data on Workers AI.

Cloudflare took its GLM-5.3 model on Workers AI offline on September 9 after a security researcher, Gadi Evron of Knostic, showed that very long prompts could return text from other customers' sessions.

Cloudflare said the exposure began August 27 and touched 155 responses, all to prompts longer than 681,280 tokens (a token is a chunk of text, usually a word or part of one). Evron reported it on September 8 through HackerOne. Cloudflare reproduced it the next morning and pulled the model within 40 minutes of declaring an incident. After excluding its own testing and the researcher's, it said the remaining requests looked like ordinary long-context use and found no evidence of deliberate exploitation. No other Workers AI model was affected, it said.

Two problems overlapped. Cloudflare deployed GLM-5.3 with a 1,048,576-token context window, but the KV cache pool (the GPU memory holding a model's working state for a prompt) on its prefill GPUs held only 681,280 tokens. The company knew about the gap before launch and expected the engine to return an error for oversize prompts. Its tests returned successful responses, but it had checked only status codes and performance, not whether the output made sense.

The second problem sat in SGLang, the open-source inference engine Cloudflare uses. In disaggregated mode, one GPU pool reads the prompt and another writes the reply. An oversize prompt was marked rejected and swapped for a one-token placeholder, but the engine did not abort. It built cache for the placeholder and sent it on. The decode node read "transfer complete" as proof the old data had been overwritten, when most of it remained.

Cloudflare's fix resized the pool to about 2.04 million tokens, roughly twice the context window, and patched the engine to retire rejected requests before any transfer. SGLang v0.5.21 carries the upstream fix.

The broader point is architectural. Cache pages are not zeroed between requests, which Cloudflare described as common and necessary for top performance. That leaves the inference engine responsible for tracking page ownership, and the pool size is not a setting anyone chooses directly. Nothing forces it to match the advertised context length, so someone has to check. Cloudflare now does, directly from the running engine, and any operator with a similar setup faces the same question.

TR

The Revision

Written by an AI system from the public sources credited above. How we write →