Cloudflare disclosed on October 26, 2026 that a bug in its Workers AI platform let 155 responses from the GLM-5.3 model leak fragments of other customers’ prompts between August 27 and September 9, 2026. The cause was a mismatch between the model’s advertised context window and the actual size of its GPU cache, combined with a bug in the inference engine SGLang. Cloudflare says only GLM-5.3 was affected and that the model was pulled offline within 40 minutes of the incident being declared.
The bug only triggered on very long prompts, and it’s a useful case study even if you’ve never touched Workers AI, because the failure mode shows up anywhere teams run shared inference infrastructure for multiple customers or tenants. It’s also the second AI-infrastructure security disclosure of real substance this quarter, after GitLab patched a critical flaw in its AI Gateway product in early October.
What Actually Went Wrong with Workers AI
GLM-5.3 was deployed with a 1,048,576-token context window, but the GPU memory pool reserved for the key-value (KV) cache during the prefill stage only had room for 681,280 tokens. Cloudflare says it knew about the gap before launch but assumed the engine would simply reject anything too large with an error. Its pre-launch tests checked for the right HTTP status codes, not what was actually in the response body.
That assumption broke because of a second bug, this one in SGLang, the open source engine Cloudflare runs in a disaggregated prefill/decode configuration (separate GPUs handle the initial prompt processing and the token-by-token generation). When a prompt exceeded the pool, SGLang marked the request as rejected internally but never aborted it. Prefill substituted a one-token placeholder and still signaled “transfer complete” to the decode node. Decode then read from cache pages that still held leftover data from a previous customer’s request, and returned HTTP 200 as if nothing had gone wrong.
Security researcher Gadi Evron of Knostic reported the issue through Cloudflare’s HackerOne bug bounty program on September 8. Cloudflare reproduced it the next day and says all 155 affected responses involved prompts longer than 681,280 tokens, consistent with ordinary long-context use rather than deliberate probing. The company says it found no evidence anyone exploited the bug on purpose.
The Fix, and Why It Took Two Months to Publish
Cloudflare’s immediate fix was to resize the GLM-5.3 KV pool to roughly 2.04 million tokens, about double the model’s context window, matching the configuration already used for GLM-5.2. The harder fix was upstream: SGLang needed to actually abort rejected requests at the admission queue, before any cache transfer happens, rather than quietly carrying on. That patch landed as SGLang v0.5.22 on October 19, more than three months after the underlying bug was first filed against the project in July.
The gap between the September 9 fix on Cloudflare’s side and the October 26 public writeup is the coordinated disclosure window: Cloudflare worked with the SGLang maintainers to get the upstream patch released before publishing details that could help someone reproduce the bug against other operators still running the vulnerable version.
Who Should Actually Care
If you’re not running your own inference infrastructure, this one’s mostly interesting rather than urgent. But it’s directly relevant if your team self-hosts SGLang, especially in disaggregated mode, or if you’re building on AI integrations where a vendor’s long-context claims and its actual cache sizing might not match the way GLM-5.3’s didn’t. Cloudflare’s own advice for other operators is worth following regardless of vendor: check that your KV pool size can actually cover your advertised context length, upgrade to SGLang v0.5.22 or later, and turn on cache corruption detection where your engine supports it.
It’s also a reminder that “the API returned 200” isn’t the same as “the API did what you asked.” Cloudflare’s own pre-launch testing checked status codes, not content, which is exactly the kind of gap that’s easy to miss when you’re validating a new model integration under time pressure.
