Cloudflare disclosed on October 26 that a memory bug in its Workers AI serving stack sent data from other customers’ sessions into 155 responses from the GLM-5.3 model — a tenant-isolation failure in the plumbing around the model, not in the model itself. Why it matters: anyone running AI inference for multiple customers on shared GPUs now has a documented case study of how that setup can leak, and a patched engine version to move to.
October 26, 2026
What happened
Cloudflare published its incident report on October 26 as a coordinated disclosure with the researcher who found the problem and with the SGLang team, whose open-source inference engine Cloudflare uses. Security researcher Gadi Evron of Knostic reported the issue through Cloudflare’s HackerOne program on September 8. Cloudflare reproduced the leak the next morning — within 25 minutes of declaring an incident, by its account — took the model private, applied a fix, and restored it the same day, September 9.
The exposure window ran from August 27, the day GLM-5.3 launched on Workers AI, to September 9. In total, 155 responses were affected, every one of them to a prompt longer than 681,280 tokens. Cloudflare says the requests it identified, after excluding its own testing and the researcher’s, matched ordinary long-context use in timing and volume, and that it found no evidence of deliberate exploitation. It also confirmed that no other model hosted on Workers AI was affected.
How the bug worked
Two faults lined up. First, a misconfiguration Cloudflare says it knew about before launch: GLM-5.3 was deployed with a context window of 1,048,576 tokens, but the KV cache pool on its prefill GPUs — the shared GPU memory that holds the intermediate state of each request — only had room for 681,280 tokens. Cloudflare expected the engine to error on prompts that did not fit, and its long-context tests returned successful responses, so it shipped.
Second, a bug in SGLang’s disaggregated mode, where one set of GPUs processes the prompt and another generates the reply. When a prompt was too long for the pool, SGLang marked it rejected and swapped in a one-token placeholder — but in this mode the request was never actually aborted. The decode GPUs assumed the full prompt had overwritten the cache pages reserved for the request, when most of those pages still held data from earlier users. The result: a normal-looking HTTP 200 response, generated partly from someone else’s session. Cloudflare is candid about its testing gap — it validated status codes and speed at long contexts, not whether the output actually made sense.
The fix
Cloudflare enlarged the prefill pool to about 2.04 million tokens, roughly twice the model’s context length, so a valid prompt always fits. It also patched the engine so a rejected request is retired at the admission queue, with its original error, before any cache transfer happens. Those fixes, plus related hardening, are in SGLang v0.5.22, released October 19, and Cloudflare says it has applied the engine fix to every model it serves with SGLang and now checks pool size against context length before any deployment ships. It urges other operators running SGLang in a split prefill/decode setup to update to v0.5.22 or later.
Why it matters
This is the kind of AI security story that should worry buyers more than a jailbreak headline. Nothing was wrong with GLM-5.3 itself; the failure sat in configuration and engine code that many providers share, and it stayed silent — no errors, plausible-looking replies — for almost two weeks. If you send sensitive work to a hosted model, the practical takeaways are simple: ask your provider how tenant isolation is tested, not just claimed, and if you self-host on SGLang, check your version today. Everything AI, tested — and in this case, the testing is exactly what failed, and what fixed it.
Frequently asked questions
Was my data leaked by the Cloudflare GLM-5.3 bug?
Only 155 responses were affected, all between August 27 and September 9, 2026, and all to prompts longer than 681,280 tokens sent to GLM-5.3 on Workers AI. Cloudflare says it is contacting the impacted accounts and found no evidence of deliberate exploitation.
What is a KV cache, in plain terms?
It is the working memory a model builds while reading your prompt, stored on the GPU and reused as it generates. On shared infrastructure those memory pages are recycled between customers — which is fast, but means the software has to track ownership perfectly.
How do I protect myself if I run SGLang?
Update to SGLang v0.5.22 or later, especially if you run a disaggregated prefill/decode setup, and verify your KV cache pool is at least as large as your model’s advertised context window.
Sources: Cloudflare Blog, Unite.AI