Cloudflare disclosed that its Workers AI platform leaked data across customer sessions in the GLM-5.3 model between August 27 and September 9, 2026, with 155 responses affected before the company took the model offline and shipped a fix. The bug, detailed in a remediation writeup on Cloudflare's blog, hit only prompts longer than 681,280 tokens and was reported through Cloudflare's HackerOne program by security researcher Gadi Evron of Knostic.
Workers AI serves GLM-5.3 — a Z.ai text generation model built for agentic coding workflows — through SGLang, an open-source inference engine, in a disaggregated prefill/decode configuration. A pool of prefill GPUs processes the prompt and builds the model's KV cache, then hands that cache over RDMA via Mooncake to a separate pool of decode GPUs that generate the response. The KV cache itself lives in a shared pool of fixed-size GPU memory pages that are not zeroed between requests; the next request to claim a page simply overwrites it, which is standard practice for performance but puts the entire burden of tracking page ownership on the inference engine.
Cloudflare's own writeup pins the incident on two overlapping failures. First, a configuration mismatch: GLM-5.3 was deployed with a 1,048,576-token context window, but the KV cache pool on Cloudflare's prefill GPUs only had room for 681,280 tokens — a gap the company says it knew about before launch but assumed the engine would handle gracefully, since pre-launch tests returned successful HTTP codes with no error frames. Second, a bug in how SGLang handled over-length prompts in disaggregated mode: when a prompt didn't fit the pool, the scheduler was supposed to reject it, but instead replaced it with a one-token placeholder and let it drain through the normal pipeline. Prefill generated a KV cache for that placeholder and transferred it to the decode node, which assumed the transfer had overwritten the previous request's data in full. It hadn't — the decode node then generated a response while attending over stale cache pages still holding other users' prompts and partial generations, returning HTTP 200 with coherent text instead of the expected error.
Cloudflare's incident timeline shows Product Security reproduced the leak within 25 minutes of declaring an incident on September 9, took the model private within roughly 40 minutes of that declaration, and restored it the same day after rolling out a corrected configuration — raising the prefill KV pool to roughly 2.04 million tokens, about twice the context length — plus a patched engine. The company says it found no evidence of deliberate exploitation; the 155 affected responses were consistent in timing and volume with ordinary long-context use once Cloudflare's own testing and the researcher's reproduction attempts were excluded.
The underlying SGLang bug had already been filed by another user as issue #30233 on July 6, 2026, which Cloudflare says it noticed while investigating this incident. The fix for that issue landed in SGLang v0.5.20, with follow-ups in v0.5.21 and v0.5.22, and Cloudflare says it is now recommending all SGLang operators upgrade to v0.5.22 or later. Cloudflare also says it has extended deferred KV page release to cover every failure type rather than just aborts, deployed bounded Mooncake transfer batches so no single transfer call can outlast a release timeout, and changed its load balancer so a client disconnect no longer aborts a request mid-transfer.
What remains unresolved is structural, not patched. Cloudflare's post states plainly that configuration checks and lifecycle fixes "do not make misuse impossible," and that the company's August prototype for page-level integrity tagging — which cost under 1% in throughput and tail latency in testing — was disabled after reliability issues and is tied to specific attention backends and model architectures, so it isn't a general fix yet. Cloudflare says it is now working with SGLang's maintainers at RadixArk on a production version of that integrity check, and separately applying formal verification methods to model the safety of its RDMA-based KV cache transfer protocol, a project it describes as ongoing rather than complete.
For anyone running shared KV caches across tenants, the lesson is procedural: Cloudflare says the gap it missed was validating only HTTP response codes and throughput at long context lengths, not output correctness, and its own recommendation to other SGLang operators is to measure KV pool size against context length directly from the engine's startup log on every prefill and decode node, after any change to weights, quantization, or parallelism — not to infer safety from a passing status code.