Cloudflare's GLM-5.3 leaked other customers' prompts to 155 requests

A hosted model served 155 responses that carried text from an earlier customer's request. Cloudflare published its own account on 26 October. Michelle Chen wrote it. The bug ran on Workers AI with GLM-5.3 from 27 August to 9 September.

The model was deployed with a 1,048,576-token context window. The key-value cache per prefill GPU only held 681,280 tokens. Any prompt over that limit hit a bug in the inference server. SGLang marked the long prompt as rejected. It swapped in a one-token placeholder. But it did not tell the decode node. The decode node then kept reading cache pages that still held parts of earlier requests. The response that came back carried "other customers' prompts and partial generations", Cloudflare says.

The timeline

Gadi Evron of Knostic filed the report on HackerOne on 8 September at 23:11 UTC. Cloudflare began checking it at 08:00 the next morning. It declared an incident at 13:22. It reproduced the leak in 25 minutes. It made the model private at 14:00. The team understood the root cause by 14:35. The configuration was corrected at 14:52. The model was restored at 19:40 after an engine patch was validated. Cloudflare says it found no evidence of planned exploitation.

What was changed

Cloudflare raised the cache pool to about 2.04 million tokens. A full-context prompt now fits in the pool. The upstream patch for the SGLang bug is issue 30233. It now retires a rejected request at the admission queue before any cache transfer. The fix is in SGLang v0.5.20, v0.5.21 and v0.5.22. Other disaggregated deployments on Workers AI used pools larger than their advertised context. No other model was affected.

The company says it is reviewing how models are brought online. It is also reviewing how their configurations are checked. It is reviewing what regression tests should look for before a model goes live. It has added fuzz tests at or above the advertised context length. It has added new alerts when a model's context window does not match its cache pool.

This is the second month in which a serving stack leaked data across customers. The common thread is simple. Fitting the chosen context window into the cache pool is now a safety setting. It is a cost setting as well. A team running a hosted model behind its own product has three things to do. Ask the serving stack what happens to a prompt that does not fit. Test that on a prompt that only just fits. Watch the server's rejected-request counter next to error rates. The advertised context window is a public promise. A pool below it is a quiet way to break that promise.

Source

Cross-request KV cache exposure in GLM-5.3 Workers AI, Michelle Chen, Cloudflare.