Cloudflare’s AI leaked other customers’ data in 155 replies: a KV cache sized for 681K tokens behind a 1M-token window

For two weeks this summer, some Cloudflare AI customers received answers containing fragments of strangers’ requests. The company disclosed the incident on October 26: 155 responses from its hosted GLM-5.3 model carried data belonging to other customers.

The leak was narrow — only very long prompts, only one model — but the mechanism is the story. A memory pool sized below the advertised context window met an inference-engine bug that turned a rejected request into a successful-looking answer, and a test suite that checked status codes but never read the output let it ship.

What happened#

GLM-5.3, a Z.ai text-generation model built for agentic coding work, is served through Workers AI as @cf/zai-org/glm-5.3. Between August 27 and September 9, 2026, a small number of customers using it received responses that contained data from other customers’ requests to the same model, made shortly before theirs. Cloudflare counted 155 affected responses, and every one of them went to a prompt longer than 681,280 tokens.

That threshold is the fingerprint of the bug: ordinary-length prompts were never at risk, which is also why the problem survived for two weeks. From the outside they looked like successful long-context answers; only the content was wrong — and content was the one thing nobody checked.

Two failures that had to overlap#

Two overlapping issues caused it, neither of which would have leaked data alone. The first was a configuration mismatch: GLM-5.3 was deployed with a 1,048,576-token context window, but the key-value (KV) cache pool on its prefill GPUs could hold only 681,280 tokens. Cloudflare says it knew about the mismatch before launch. It expected the engine to error on prompts it could not fit, and its long-context tests came back successful, so the gap was not treated as a live problem.

The second was a bug in SGLang, the open-source inference engine, in its disaggregated prefill-and-decode mode — the setup that splits prompt processing from token generation. A prompt that did not fit the pool was internally marked as rejected and swapped for a one-token placeholder. But instead of aborting and returning a client error, prefill generated KV cache for the placeholder and handed it to the decode node with a “transfer complete” signal. Decode assumed the full prompt had overwritten earlier requests’ cache; in fact most of it was intact, so the model answered from stale pages holding other users’ data. The client, meanwhile, received HTTP 200 instead of HTTP 400.

The test that passed while the product failed#

The most quotable line in Cloudflare’s report is an admission about its own testing. Its pre-launch long-context checks validated HTTP response codes and engine performance, but not the quality or coherence of the output. The company calls that a critical gap: a cache serving someone else’s data still returns a 200, so every check that only looked at the status line passed.

The incident came to light from the outside: security researcher Gadi Evron of Knostic reported it through Cloudflare’s HackerOne program on September 8. Cloudflare reproduced the issue the next morning and took the model offline within 40 minutes of declaring an incident. A corrected configuration and patched engine restored service the same day. According to Knostic’s account, the stray fragments included things like invoice numbers, source code and file paths — the kind of working material that coding-agent users routinely paste into long prompts.

Excluding its own tests and the researcher’s requests, Cloudflare says the rest matched ordinary long-context use, and it found no evidence of deliberate exploitation. The leak, in other words, needed no attacker: normal usage, at sufficient length, was enough.

Why this reaches beyond one provider#

Disaggregated prefill and decode is now the standard way to serve long-context models at scale, a warning for the whole hosted-inference market. In that architecture the KV cache is not just a performance buffer; it is a tenant-isolation boundary, and nothing in the default stack enforces it for you. A sizing mismatch on one side and a mishandled rejection on the other are enough to cross it silently.

Self-hosted SGLang users are directly in scope. Cloudflare and the SGLang maintainers published coordinated fixes, with the complete fix landing in SGLang v0.5.22 on October 19; operators on earlier disaggregated releases should upgrade and re-test. The practical lesson generalises: do not assume the engine will reject what does not fit; test at and above your advertised limits, and inspect the answers, not just the status codes. A 200 response is evidence that something replied, not that it replied to you.

What to watch#

Three things will show whether this disclosure changes behaviour or just embarrasses one provider. First, whether other hosted-inference vendors audit their own disaggregated stacks and publish what they find — the bug class is architectural, not Cloudflare-specific. Second, whether enterprise customers start demanding isolation tests at context limits as part of procurement. And third, whether Cloudflare’s approach — a coordinated post with the engine maintainers, a hard count of affected responses, and a plain admission of the testing gap — becomes the template for the next disclosure of this kind. The next one is a matter of time; the question is who finds it — a researcher, or a customer reading their own output.