Cloudflare Workers AI's GLM-5.3 model returned other customers' data in 155 responses

In brief

Cloudflare has disclosed that its hosted GLM-5.3 model on Workers AI (@cf/zai-org/glm-5.3) sometimes answered one customer with data from another customer's earlier request. In a post published on 26 October, Cloudflare said 155 responses were affected between 27 August and 9 September 2026. All of them were responses to prompts longer than 681,280 tokens.

Cloudflare says it confirmed that no other Workers AI model was affected. After excluding its own testing and the researcher's, it found no evidence of deliberate exploitation.

How it happened

Cloudflare describes two overlapping problems.

• A configuration gap. The model was deployed with a 1,048,576-token context window, but the prefill GPUs' KV cache pool held only 681,280 tokens. Cloudflare says it knew about the mismatch before launch but expected the engine to reject prompts it could not process.
• An SGLang bug. In disaggregated prefill/decode serving, the open-source SGLang engine marked an over-length prompt as rejected but did not abort it. The decode node then generated a response from stale cache pages that still held earlier requests' data. The SGLang maintainers' post says single-node deployments returned an error instead.

Two timelines

The parties agree on how it was reported. Gadi Evron of Knostic submitted the report through Cloudflare's HackerOne program on 8 September. Knostic says it first traced an anomaly seen through OpenRouter to Cloudflare on 7 September.

Their timelines differ on when the issue was fixed.

• Cloudflare says it reproduced the issue on 9 September and took the model offline within 40 minutes of declaring an incident. It says it restored the model the same day with a corrected configuration and a patched engine.
• Knostic says Cloudflare acknowledged the report on 9 September and told Knostic on 24 September that it had validated the issue and deployed a fix.

SGLang says its default protection for this class of bug arrived in v0.5.21, released on 2 October, for Mooncake and NIXL deployments.

What teams should do (ByteNib editorial analysis)

For teams sending long prompts to hosted models:

1. Treat very long context as a separate risk tier. This bug only appeared above 681,280 tokens, which ordinary tests rarely reach. Ask providers how they isolate requests near the context limit.
2. Ask whether the stack uses disaggregated serving and which engine version. Self-hosted SGLang users should follow the maintainers' upgrade guidance.
3. Watch for responses that don't match the prompt. Off-topic output may be a leak, not a hallucination. Log and report it.
4. Keep secrets out of shared inference where you can. Redact or tokenise sensitive data before it goes into very large prompts.
5. Check whether you were affected. GLM-5.3 customers who sent very long prompts in the affected window should ask Cloudflare.

Sources and scope

• Cloudflare blog, "Cross-request KV cache exposure in the GLM-5.3 Workers AI model, and our remediation with SGLang", 26 October 2026: https://blog.cloudflare.com/kv-cache-exposure-remediation/
• LMSYS/SGLang, "SGLang security update: improving request isolation", 26 October 2026: https://www.lmsys.org/blog/2026-10-26-cf-security/
• Knostic, "Cross-Tenant Data Leak in Cloudflare Workers AI (GLM-5.3)": https://www.knostic.ai/blog/hallucination-or-cross-tenant-when-an-llm-answers-with-another-users-context

Figures and dates come from these three sources and are attributed where they differ. The takeaways are ByteNib editorial analysis.

Drafted with AI assistance and reviewed by the editor before publication.

Continue exploring: Cybersecurity analysis, the related implementation tutorial, and the structured learning path.