Cloudflare has published one of the most candid security disclosures the hosted-AI industry has seen: between August 27 and September 9, 2026, the GLM-5.3 model running on its Workers AI platform returned 155 responses that contained fragments of other customers' prompts. The company found no evidence of deliberate exploitation, said no other model on the platform was affected, and restored the model on September 9 after a configuration change and an engine patch. The public explanation followed on October 26, after upstream fixes had been merged.
The flaw surfaced through a responsible report on September 8 from Gadi Evron of security firm Knostic, filed via Cloudflare's HackerOne program. Very long prompts were occasionally coming back with text that belonged to other people's sessions. Cloudflare reproduced the problem the next morning and pulled the model offline within 40 minutes of declaring an incident. GLM-5.3 is the open-weight flagship from China's Z.ai, and it had launched on Workers AI only weeks earlier.
The root cause was a mismatch between what Cloudflare advertised and what its GPUs could hold. The platform offered a 1,048,576-token context window for GLM-5.3, but the memory pool on its prefill GPUs had room for only 681,280 tokens. The open-source SGLang inference engine was supposed to reject anything longer. Instead, a bug in how SGLang coordinates work between prefill and decode GPUs let rejected requests slip through the handoff. The decoder then read memory pages the new request never filled in — pages that still held leftovers from earlier users. Customers got a normal-looking answer instead of an error.
Cloudflare was unusually blunt about what it missed. KV cache pages are not wiped between requests, because doing so would cost speed, and the company notes this is common across inference engines — the burden falls on the engine's bookkeeping. Its pre-launch tests checked response codes and latency, but never whether the model output actually made sense. "This is the check we did not enforce," the disclosure states. The company had also prototyped per-page memory tagging that would have caught the misread at under 1 percent throughput cost, tested it in mid-August, then disabled it over reliability concerns.
The remediation went beyond a hotfix. Cloudflare enlarged the memory pool to about 2.04 million tokens, roughly double the model's context length, so a valid prompt always fits. It patched the engine so a rejected request terminates with its original error before any cached data moves between GPUs. It applied the same hardening to every model it serves with SGLang, added a deployment check that compares pool size against context length on the running engine, and worked with the SGLang maintainers on upstream fixes that landed in versions 0.5.20 through 0.5.22. Operators running self-hosted SGLang are urged to update to 0.5.22 or later.
The episode matters well beyond one model. Hosted inference has quietly become a software supply chain of its own, where a bug in an open-source engine is inherited by a large provider and passed on to every tenant. Organizations sending regulated or confidential data through AI APIs rarely ask vendors how shared GPU memory is isolated between customers — the question that, until now, had no obvious reason to exist. Data protection lawyers will also note the exposure window: customers who sent long prompts to GLM-5.3 in late August learned only this week that fragments of their data could have appeared in someone else's reply.
Cloudflare says it wants to use formal verification to prove a bug of this class "cannot occur again," while admitting the proofs will have gaps. That is the right instinct, and the industry should hold it to the timeline. The cheaper lesson is already actionable for anyone building on hosted models today: keep secrets out of prompts, be careful with very long inputs on freshly launched models, and when you test a new inference deployment, inspect what the model actually says — not just whether the HTTP status came back green.
Comments (0)
Log in to join the discussion
Log InNo comments yet