For about two weeks, some answers from the GLM 5.3 model on Cloudflare's Workers AI contained pieces of other people's requests. Cloudflare says 155 responses were affected, all to very long prompts, and that it found no evidence anyone exploited the bug on purpose.1
The cause was a sizing mismatch in Cloudflare's setup meeting a bug in SGLang, the open-source engine it uses to run the model. Cloudflare has published a detailed postmortem together with the SGLang team, and the fixes are in SGLang releases any operator can install.
What happened at Cloudflare Workers AI
Cloudflare's postmortem opens with the scope:
Between August 27 and September 9, a small number of customers using the GLM 5.3 Workers AI model received responses that contained data from other customers' requests made to the same model shortly before theirs. In total, 155 responses were affected, all to prompts longer than 681,280 tokens.
What leaked was pieces of other users' prompts and partial generations. Cloudflare says the affected requests matched ordinary long-context use in timing and volume, not someone triggering the bug over and over, and that no other model it hosts was affected.1
A security researcher, Gadi Evron of Knostic, reported the problem through Cloudflare's HackerOne program. Cloudflare reproduced it the next morning, took the model offline within 40 minutes of declaring an incident, and restored it that evening with a corrected configuration and a patched engine. Its announcement:
Quoted from X
Cloudflare (@Cloudflare), :
A configuration mismatch in GLM 5.3 on Workers AI triggered an SGLang bug that exposed KV cache pages across requests. Here is how we addressed the issue. blog.cloudflare.com/…
The timeline shows how fast the containment was, and how long the upstream work took.

One note for anyone searching: this has nothing to do with Workers KV, Cloudflare's key-value storage product. The "KV" here is the model's key-value cache in GPU memory.
What is a KV cache, and how did it leak?
A KV cache is a model's working memory for one request. As a language model reads your prompt, it computes keys and values for every token and keeps them, so it doesn't redo that math for each word it writes. On a busy server, that memory is a shared pool of fixed-size pages handed out to requests as they arrive.
To stay fast, engines don't wipe a page between requests; the next request writes over it. Cloudflare notes this is common among inference engines, and it works as long as the engine tracks which request owns which page.1 This bug broke that tracking.
Workers AI ran GLM 5.3 in a split, or disaggregated, setup: one group of GPUs (prefill) reads the prompt and builds its cache, then hands it to another group (decode) that writes the answer. Here is what went wrong:
- Cloudflare advertised a 1,048,576-token context window, but the prefill GPUs' cache pool had room for 681,280 tokens. It knew about the gap before launch and expected the engine to reject what didn't fit; its long-context tests came back successful.
- When a prompt didn't fit, SGLang marked it rejected and swapped it for a one-token placeholder. In split mode, the handoff to decode went ahead anyway.3
- Decode had reserved pages for the full prompt, but only one had been written. The rest still held what earlier requests had left there.
- Decode read those pages and answered. The client got HTTP 200 and a normal-looking reply, with fragments of other users' requests in it.
On a single machine, the same rejection path worked and returned an error.3 It took the split setup and the undersized pool together to leak anything. Another user had already reported the same bug to SGLang earlier in the summer; Cloudflare found that issue while investigating.1
Could this have happened to anyone?
Largely, yes. Inference engines are complex, SGLang is widely used, and the bug sat in a path that only runs in one kind of deployment. Cloudflare's own testing gap is an ordinary one: it checked status codes and speed at long contexts, not whether the answers made sense.1
Cloudflare doesn't claim the problem is solved for good:
Configuration checks and lifecycle fixes reduce the number of ways a page can be misused. They do not make misuse impossible, and this incident is a reminder that the next bug will have a shape we have not seen.
What stands out is the response: a candid postmortem that names Cloudflare's own mistakes, and fixes that went upstream so every operator gets them. One fix was already on SGLang's main branch, and the maintainers at RadixArk merged a second that follows Cloudflare's draft patch.3 Cloudflare says it is now working with them on checks that would stop a request from reading pages it doesn't own, whatever shape the next bug takes.
What to do now
- If you use Workers AI: GLM 5.3 is fixed and back online. Only prompts longer than 681,280 tokens were affected. If you sent prompts that long to GLM 5.3 in that window, the postmortem is the record and Cloudflare's support is the place to ask.
- If you run SGLang with split prefill and decode: update to v0.5.22 or later, as Cloudflare recommends.1
- Check your cache pool against your context length on every prefill and decode node, after every change to weights, quantization or parallelism, and lower the context length if the pool is smaller. "This is the check we did not enforce," Cloudflare writes.
- If you use any AI service: your prompts pass through software you can't see. It's worth asking what a provider publishes about what it runs, and how it would tell you when something breaks.
We've added the incident to our AI privacy timeline, which tracks events like this across services.
Sources
- Cloudflare (Kevin Flansburg and Michelle Chen), Cross-request KV cache exposure in the GLM-5.3 Workers AI model, and our remediation with SGLang, October 26, 2026. Scope, cause, timeline, fixes and recommendations for operators.
- Cloudflare, post on X, October 26, 2026.
- SGLang Team, SGLang security update: improving request isolation, October 26, 2026. The engine bug, the single-node behavior and the upstream fixes.


