GLM 5.3 KV cache exposure in Workers AI: what happened

Cloudflare says the GLM-5.3 model on Workers AI returned text from other customers in a small number of responses for very long prompts. According to the Cloudflare Blog, the issue appeared between August 27 and September 9, 2026, affected 155 responses, and was fixed after Cloudflare disabled the model, adjusted its configuration, and patched the inference engine.

How the GLM 5.3 KV cache exposure occurred

Cloudflare explains that GLM-5.3 ran in a disaggregated setup where a pool of prefill GPUs builds the model's KV cache for a prompt, and decode GPUs generate the response from that cache. The inference engine, SGLang, sizes a shared KV cache pool at startup from whatever GPU memory remains after the model loads, while the model's advertised context length is a separate configuration value. On Cloudflare's prefill nodes the KV pool held 681,280 tokens while the model's context length was 1,048,576 tokens. Cloudflare says they were aware of the mismatch before launch.

When a prompt exceeded the pool capacity, SGLang's scheduler rejected it and substituted a one-token placeholder so the request could continue through batching. In disaggregated mode, the prefill node sent the placeholder's KV pages and signaled "transfer complete" to the decode node. The decode node then assumed it had the full KV state for that request and generated a response while attending over leftover KV pages that still contained data from prior requests. The result was that responses to prompts longer than 681,280 tokens could include data from other users' recent GLM-5.3 sessions.

Cloudflare notes two overlapping causes: a configuration mismatch that allowed valid-looking long-request tests to pass, and a bug in SGLang's handling of the rejection path when prefill and decode are separate.

What Cloudflare changed to stop the leak

Cloudflare took the model offline the morning after reproducing the report and restored service only after making two classes of fixes. First, they changed configuration so the prefill KV pool always holds the full context. On their deployment that freed enough GPU memory so the pool now holds roughly twice the model's context length. That change prevents the rejection path tied to pool shortage from being hit for valid requests.

Second, they patched the inference engine to make the rejection path safe. Instead of letting a request with a pending rejection progress to KV transfer, Cloudflare retired such requests earlier in the admission queue and had the decode node verify that the number of tokens transferred matches what it reserved. Cloudflare validated these changes against the researcher's reproduction script and their own canary tests before restoring the model. They published this coordinated disclosure alongside upstream SGLang changes that the maintainers merged.

Why this matters for small teams and public sector sites

The bug shows two practical failure modes that matter beyond this one model. First, configuration gaps between an engine's runtime allocations and a model's advertised context can let problematic requests slip through basic status-code checks. Second, inference engines that reuse GPU memory pages for performance need correct ownership and lifetime tracking, especially in disaggregated deployments.

For most users this was a low-volume incident affecting very large prompts, but if you rely on long-context models or host sensitive data in prompts, the risk is clear: cross-request leakage can happen when the runtime does not enforce context and memory boundaries.

Practical steps to check your AI deployments

• Verify vendor notices and coordinated disclosures, and apply any recommended inference engine or model configuration updates. For this issue, Cloudflare and SGLang published coordinated posts describing the fixes.
• Confirm that a deployed model's configured context length matches whatever pool or buffer the runtime exposes, and fail fast if they disagree rather than relying only on HTTP success codes.
• Run end-to-end tests with very long prompts to validate not just status codes and throughput, but the coherence and ownership of returned text.
• Monitor metrics that reveal KV pool size and token accounting; treat mismatches as a deployment blocker.
• Limit the use of sensitive data in prompts when possible, and review who has access to model outputs and logs.

If you run WordPress or Formidable Forms integrations that call hosted models and want a hand checking configurations or tests, Get help from a Formidable Masterminds developer.

What to watch next

Cloudflare says they proposed and tracked upstream fixes in SGLang and that maintainers merged related changes. If you operate LLM inference at scale, watch vendor and upstream engine updates for similar fixes to rejection and admission logic. Prioritize tests that exercise rare code paths, such as requests that hit rejection or overflow conditions, because those paths are where memory ownership bugs tend to appear.

This incident is a reminder that high-performance inference architecture often trades memory safety for speed, and that safety requires matching configuration, robust error paths, and validation at runtime. For teams that depend on long-context models, those checks are the practical next step.