Cloudflare has published a detailed incident report describing how a cache-handling bug in its serverless AI platform caused at least 155 users of a GLM-5.3 model deployment to receive responses containing fragments of other customers' prompts and outputs. The report, published October 26 as a coordinated disclosure alongside the SGLang open-source inference engine project, offers a rare public look inside the plumbing of multi-tenant LLM serving — and a warning about the security assumptions of GPU memory.
How the Leak Was Found For more context on this story, see our ongoing AI trends.
According to Cloudflare, security researcher Gadi Evron of Knostic alerted the company on September 8, 2026, through its HackerOne bug bounty program. Evron reported that very long prompts sent to the GLM-5.3 model on Cloudflare's Workers AI platform sometimes returned text that belonged to other users' sessions. Cloudflare reproduced the issue the following morning and disabled the model the same day, restoring it on September 9 after deploying fixes.
The affected model was @cf/zai-org/glm-5.3 — the agentic coding model from Z.ai that Cloudflare serves through Workers AI, the company's serverless inference platform. Cloudflare confirmed that no other model hosted on the platform was affected.
What Actually Happened
The incident traces back to two overlapping problems, one operational and one in the engine itself.
First, the misconfiguration. Cloudflare deployed GLM-5.3 with a 1,048,576-token context window, but the key-value (KV) cache pool on its prefill GPUs only had room for 681,280 tokens. The company acknowledged it was aware of this mismatch before launch and expected the inference engine to reject over-length requests safely.
Second, the engine bug. In disaggregated prefill/decode mode — the architecture Workers AI uses, in which one pool of GPUs processes the prompt and hands the resulting KV cache to a separate pool of GPUs that generate the response — SGLang handled the over-length request incorrectly. A prompt that did not fit the pool was internally marked as rejected and replaced with a one-token placeholder. But instead of aborting the request and returning a client error, the prefill stage generated KV cache for the placeholder prompt and transferred it to the decode node, which then produced a response that mixed in leftover data from previous requests sharing the same memory pages.
The result: between August 27 and September 9, a small number of customers using the model received responses containing data from other customers' requests made shortly before theirs. In total, 155 responses were affected — all, Cloudflare found, to prompts longer than 681,280 tokens.
No Evidence of Deliberate Exploitation
Cloudflare stated that after excluding its own testing and the researcher's validation requests, the affected requests were consistent in timing and volume with ordinary long-context use, and the company found no evidence that anyone deliberately exploited the bug. Because every affected request exceeded the undersized pool's capacity, the exposure window was tightly bounded — a silver lining that stems from the very misconfiguration that caused the problem.
The Fix: Bigger Pools and a Safer Failure Path
The remediation worked on both layers of the failure. Cloudflare reconfigured its GLM-5.3 deployment to match its GLM-5.2 configuration, freeing enough GPU memory that the prefill KV pool now holds about 2.04 million tokens — roughly double the model's 1,048,576-token context length. A prompt that fits the context window now always fits the pool.
But the company also stressed that relying on pool sizing alone is fragile: changes to quantization, tensor parallelism, CUDA graph sizes, or a future model version can silently change the pool size. So it also patched SGLang's rejection path itself, ensuring that a rejected request aborts cleanly instead of generating and transferring cache for a placeholder. Both changes were validated against the researcher's reproduction script and Cloudflare's own canary-marker tests before the model was restored, and the fixes have been contributed upstream to the SGLang maintainers.
Why Shared GPU Memory Is a Security Question
The report explains a practice that will surprise many application developers: inference engines generally do not zero out KV cache pages between requests, because the next request simply overwrites them. This is a deliberate performance trade-off, common across inference engines, but as this incident shows, any path that lets a response be generated before those pages are fully overwritten turns a performance optimization into a data-leak vector.
The disclosure landed with the developer community: the story reached 123 points on Hacker News within hours, with discussion focusing on how the failure mode — a request that should have failed loudly instead proceeding silently on corrupted state — mirrors classic lessons from distributed systems engineering.
A Broader Lesson for AI Infrastructure
The incident is a reminder that the security perimeter for AI applications now extends deep into inference infrastructure. Multi-tenant model serving concentrates many customers' data through shared accelerators, shared cache pools, and increasingly exotic architectures like disaggregated prefill and remote direct memory access. A subtle mismatch between a model's advertised context window and the physical capacity provisioned to serve it was enough to breach tenant isolation.
For enterprises building on serverless AI platforms, the takeaway from Cloudflare's report is twofold: tenant isolation bugs in LLM serving are real and have already happened in production, and the vendors' response time — under 24 hours from report to disable, one day to fix and restore — is the standard of diligence to demand from any provider handling sensitive prompts.
---
Stay Ahead of AIGet the latest AI news, analysis, and breakthroughs — all in one place.
Read more AI news →
