Cloudflare Workers AI leaked prompts across customers

If you send long prompts to a hosted model, your data shares a machine with strangers. Cloudflare has now shown what happens when that sharing breaks.

Cloudflare says that between Aug. 27 and Sept. 9, some customers of its Workers AI service received responses from the GLM 5.3 model that contained data from other customers' requests made shortly before theirs. It published the report on Oct. 26 as a coordinated disclosure with the researcher who found it and with RadixArk, the maintainers of SGLang, the open-source inference engine it uses.

The count:

155 responses, all to prompts longer than 681,280 tokens.

Cloudflare says it found no evidence of deliberate exploitation and that no other model on Workers AI was affected.

Two mistakes met in the middle

The first was a configuration Cloudflare knew about. It deployed GLM 5.3 with a 1,048,576 token context window, but the KV cache pool on its prefill GPUs held only 681,280 tokens. Cloudflare says it was aware of the mismatch before launch and expected the engine to return an error for any prompt too large to process.

The second was a bug in SGLang. Large models are often served in two stages: one set of GPUs reads the prompt (prefill), another writes the answer (decode). The model's working memory of what it has read, the KV cache, moves between them.

When a prompt was too long, Cloudflare says, SGLang marked the request rejected and swapped in a one-token placeholder. Prefill still sent cache data to decode, and decode assumed the old cache had been overwritten. It hadn't. The answer was built partly on pages still holding other users' sessions.

Think of a shared whiteboard nobody erased. The next person's notes went on top of the last person's.

The timeline and the fix

A security researcher, Gadi Evron, reported the issue through Cloudflare's HackerOne program on Sept. 8, Cloudflare says. It reproduced it the next day, made the model private at 14:00 UTC on Sept. 9 and restored it at 19:40 UTC.

The core fix had two parts. Cloudflare matched the GLM 5.3 configuration to GLM 5.2, giving the prefill pool about 2.04 million tokens, roughly twice the context length. It also patched SGLang so rejected requests return an error before any cache transfer. Cloudflare lists upstream fixes in SGLang v0.5.20, v0.5.21 and v0.5.22, and says a related SGLang issue had been filed by another user on July 6.

The post does not say whether Cloudflare told the affected customers.

What to do about it

Shared inference means shared memory. Every provider that serves many customers from the same GPUs reuses that memory between requests, and the only question is how carefully it gets cleared.

If you send sensitive data to hosted models, three questions are worth asking:

• How does each inference provider isolate KV cache between customers, and does it split prefill and decode across machines?
• What happens when a prompt is longer than the provider can serve? An error is what you want.
• Were you among the affected in any incident your provider discloses?

If you run SGLang yourself in disaggregated mode, Cloudflare's advice is to upgrade to v0.5.22 or later, check the KV pool size against the context length on every prefill and decode node, and turn on corruption detection where the model supports it.

Watch who else checks their pools

Cloudflare says it is working with the SGLang maintainers on per-page integrity checks and on formal verification of how cache moves between machines. Other providers running the same engine now have a public checklist.

Ask yours this week.