Cloudflare Details Cross-Request KV Cache Exposure in GLM-5.3 Workers AI
Summary
Cloudflare disclosed a confirmed cross-tenant data exposure in GLM-5.3 Workers AI: 155 responses to prompts over 681,280 tokens included data from other customers’ requests. A KV-pool mismatch and SGLang bug caused it; fixes are deployed, with no deliberate exploitation
Key points
- From August 27 to September 9, 2026, 155 responses to GLM-5.3 Workers AI prompts longer than 681,280 tokens contained data from other customers’ requests.
- The model’s 1,048,576-token context window exceeded the prefill KV pool’s 681,280-token capacity, allowing requests that could not fit the pool to reach the faulty rejection path.
- In disaggregated prefill/decode mode, SGLang passed a one-token placeholder to decode after rejecting an over-length request; decode then read stale KV pages left by earlier requests.
- Cloudflare reported no evidence of deliberate exploitation and said the identified request timing and volume were consistent with ordinary long-context use.
- Cloudflare corrected the pool configuration, patched the inference engine, tested the fixes, and restored GLM-5.3 on September 9. It said no other Workers AI model was affected.
- Cloudflare recommends operators using disaggregated SGLang compare KV pool size with context length and upgrade to v0.5.22 or later.
Article Details
- Attack Vectors
- Prompts longer than the 681,280-token prefill KV pool triggered a rejected-request path in disaggregated SGLang deployments. The decode node then read stale KV cache pages left by earlier requests, causing some GLM-5.3 responses to contain data from other customers' sessions.
- The issue affected GLM-5.3 on Workers AI from August 27 to September 9, 2026. Cloudflare reported 155 affected responses and found no evidence of deliberate exploitation.
- Defensive Notes
- Cloudflare corrected the GLM-5.3 configuration so the prefill KV pool holds about 2.04 million tokens, patched the rejection path to retire rejected requests before bootstrap, allocation, or KV transfer, and restored the model on September 9, 2026.
- Operators running disaggregated SGLang should compare KV pool size with context length on every prefill and decode node after configuration changes, and use a build that includes fixes #36988 and #38935 (v0.5.22 or later).
- The article recommends enabling deferred KV release on both roles, bounding Mooncake transfer batches, enabling supported KV checksum and canary checks, and configuring load balancers to avoid unnecessary mid-transfer aborts.
People
Vendors
Cloudflareto @cf/zai-org/glm-5.3 on Workers AI sometimes returned text that belonged to other users' sessions. Cloudflare reproduced the issue the next morning and took the model offline within 40 minutes of declaring anRadixArkMeeting with the SGLang maintainers (RadixArk CTO and core engineers) to agree on upstream fixes.Z.aiGLM is a text generation model from Z.ai that is built for agentic coding workflows; it is one of the many models available through Workers AI. Gadi Evron submitted a report on September 8 through our HackerOne program
Products
GLM-5.3alerted by a security researcher, Gadi Evron from Knostic, to a tenant isolation issue affecting the GLM-5.3 Workers AI model (@cf/zai-org/glm-5.3) starting on August 27, 2026. We have remediated the issue, and weMooncakeproduces the model's KV cache for it, then hands that cache over remote direct memory access (RDMA), via Mooncake, to a pool of decode GPUs that generate the response. We have written about this architecture before inSGLangToday we are publishing this report alongside a post from SGLang, the open-source inference engine that we use, as a coordinated disclosure. This post describes the bug that caused this issue, our response timeline, andWorkers AIby a security researcher, Gadi Evron from Knostic, to a tenant isolation issue affecting the GLM-5.3 Workers AI model (@cf/zai-org/glm-5.3) starting on August 27, 2026. We have remediated the issue, and we restored