Summary: On September 8, 2026, security researcher Gadi Evron of Knostic reported that very long prompts sent to GLM-5.3 on Cloudflare Workers AI could return fragments of other users’ requests. Cloudflare took the model offline within hours, fixed both a config error and an SGLang engine bug, and restored service the next day. The postmortem is a useful study in how disaggregated inference can fail quietly.
What actually leaked
Between August 27 and September 9, 2026, 155 responses to prompts longer than 681,280 tokens contained data from other customers’ sessions on the same model. Cloudflare’s incident report says the affected requests look consistent with ordinary long-context use, with no evidence of deliberate exploitation, and that no other Workers AI model was affected.
The failure needed two problems stacked on top of each other. Either one alone would probably have stayed harmless.
The misconfiguration and the engine bug
First, the configuration. Cloudflare deployed GLM-5.3 with a 1,048,576-token context window, but the KV cache pool on the prefill GPUs only had room for 681,280 tokens. SGLang sizes that pool at startup from leftover GPU memory — it’s not a config value — and nothing forces it to match the advertised context length. Cloudflare knew about the mismatch but assumed the engine would return an error for prompts that didn’t fit. Their long-context tests returned HTTP 200s, so the assumption held until it didn’t.
Second, the SGLang bug. In disaggregated prefill/decode mode, an over-length prompt was internally marked rejected and swapped for a one-token placeholder. But the admission queues checked whether a request was finished, not whether it was rejected. So prefill ran a trivial forward pass on the placeholder, sent one page of KV across, and signaled transfer complete. The decode node had reserved pages for the full prompt, saw the completion signal, and generated a response attending over stale pages that still held earlier users’ data. The client got a coherent 200 response — just one that attended to someone else’s tokens.
The fix, in two layers
Cloudflare’s remediation is worth copying as a pattern:
- Make the pool hold the full context. The corrected GLM-5.3 config gives a prefill KV pool of about 2.04 million tokens — roughly double the context length — so the rejection path is never reached for a valid request.
- Make the rejection path safe anyway. Pool sizing is fragile; any change to quantization, tensor parallelism, or model version shifts it. So they also patched SGLang so a rejected request is retired with its original error before any KV transfer, plus a decode-side check that transferred tokens match reserved tokens. SGLang v0.5.20 through v0.5.22 carry the fixes, and Cloudflare recommends operators run v0.5.22 or later.
Both changes were validated against the researcher’s reproduction script and canary-marker tests before the model went back to public traffic.
What this means if you serve models
The testing gap is the part that hits hardest: Cloudflare validated HTTP codes and throughput at long contexts, but not output coherence. A successful status code told them nothing about whether generation was attending to the right memory. If you operate disaggregated serving, check KV pool size against context length directly from the running engine before shipping a deployment change — don’t infer health from response codes.
It’s also a reminder that shared KV cache pages are only safe when ownership tracking is airtight. We’ve covered how prefix-aware routing shifts serving behavior when prompts overlap, and this incident lives in the same corner of the stack: reuse is where the performance comes from and where the risk concentrates.
GLM-5.3 remains a strong open-weight coding model — we looked at its launch and cyber benchmarks — and the exposure here was operational, not a flaw in the model itself. The practical takeaway: treat your engine’s reported KV pool size as a launch gate, pin SGLang to v0.5.22+, and add output-coherence checks to your long-context test suite.