Cloudflare Served Other Customers' GLM-5.3 Data in 155 Responses Over Two Weeks. It Knew the KV Pool Was Too Small Before Launch.
Cloudflare disclosed on October 26 that from August 27 to September 9 its Workers AI GLM-5.3 endpoint returned fragments of other customers' recent requests in 155 responses, all to prompts longer than 681,280 tokens. The model advertised a 1,048,576-token context while its prefill KV pool held 681,280, a mismatch Cloudflare says it knew about and expected to produce an error, and an SGLang disaggregated prefill-decode bug let decode read stale cache. A Knostic researcher reported it September 8; the model was offline within 40 minutes and restored September 9. Disclosure came about seven weeks after the fix. We read Cloudflare's post, LMSYS's post, and the status page.
By T.W. Ghost
Cloudflare published a post-incident report today, October 26, 2026, coordinated with the SGLang team at LMSYS. From August 27 to September 9, the @cf/zai-org/glm-5.3 model on Workers AI returned data from other customers' recent requests in 155 responses. Every affected response was to a prompt longer than 681,280 tokens, and every one of them came back as a normal HTTP 200.
The cause has two halves, and Cloudflare owns the first in writing. The model was advertised with a 1,048,576-token context window while the prefill KV cache pool was sized for 681,280 tokens. Cloudflare says it knew about that mismatch before launch and expected oversized prompts to fail with an error. They did not fail. An SGLang bug in disaggregated prefill and decode swapped in a one-token placeholder and let the decode stage read stale cache that belonged to someone else. Gadi Evron of Knostic reported the behavior through HackerOne on September 8; the model was taken offline within 40 minutes and restored on September 9. The public disclosure landed about seven weeks later. We read Cloudflare's post, LMSYS's companion post, and the status-page incident. Here is what held up.
The Incident, by the Numbers
| Cloudflare Workers AI, GLM-5.3 | |
|---|---|
| Window | August 27 to September 9, 2026 |
| Affected responses | 155, all to prompts over 681,280 tokens |
| Advertised context | 1,048,576 tokens |
| Prefill KV pool | 681,280 tokens; mismatch known before launch (Cloudflare) |
| Contributing bug | SGLang disaggregated prefill-decode placeholder let decode read stale cache |
| Reported | September 8, Gadi Evron (Knostic), via HackerOne |
| Response | Offline within 40 minutes; restored September 9 |
| Disclosed | October 26, about seven weeks after remediation |
| SGLang fix | v0.5.21, or v0.5.22 for MORI (LMSYS) |
| Other Workers AI models | None affected (Cloudflare) |
| Deliberate exploitation | No evidence (Cloudflare) |
The failure Cloudflare planned for was the wrong one. An undersized pool that throws is a capacity bug. An undersized pool that silently hands the next tenant your context is a confidentiality bug, and the difference was a placeholder token in an inference framework Cloudflare did not write.
Two hundred means nothing here. Affected responses were not errors, warnings, or truncations. A caller who sent a very long prompt got a plausible answer with someone else's data in it. There was nothing in the response to detect.
Seven weeks is the disclosure gap, not the exposure gap. The exposure ran two weeks and ended within 40 minutes of the report. The time between the fix and the public post is the number affected customers will want explained, and the post does not say whether they were told directly.
Who Else Runs This Code
GLM-5.3 is the open-weight model behind a lot of October's cheap hosting, including the Token Pass tier and the multi-provider setups hit in the OpenCode Console breach. The SGLang bug does not care who the host is. LMSYS says the family of issues is fixed through v0.5.21, or v0.5.22 for MORI deployments, and anyone serving a long-context model with disaggregated prefill and decode on an older SGLang has the same exposure Cloudflare had, whether or not they ever touched Workers AI.
Verified vs Unconfirmed: The Scorecard
| Claim | Verdict |
|---|---|
| Aug 27 to Sep 9; 155 responses; prompts over 681,280 tokens | Verified (Cloudflare post) |
| 1,048,576 advertised vs 681,280 pool; known before launch | Verified (Cloudflare's own statement) |
| SGLang disaggregated prefill-decode bug contributed | Verified (Cloudflare and LMSYS posts) |
| HackerOne report Sep 8 by Gadi Evron, Knostic; offline in 40 minutes; restored Sep 9 | Verified (Cloudflare post) |
| No evidence of deliberate exploitation; no other Workers AI model affected | Vendor statement (Cloudflare) |
| SGLang fixed in v0.5.21, v0.5.22 for MORI | Verified (LMSYS post) |
| Direct notification of affected customers | Unverified (not stated) |
| Blast radius beyond 155 after excluding Cloudflare and researcher traffic | Unverified |
What To Do
If you sent prompts over 681,280 tokens to GLM-5.3 on Workers AI in that window, assume the content may have reached another tenant and rotate any secret that appeared in those prompts.
If you self-host with SGLang disaggregated prefill and decode, upgrade past the versions LMSYS names before you serve another long-context request.
The frontier is elsewhere: the model did nothing wrong; the serving stack did, and the same stack runs under most of the open-weight hosting we price on this site. Our model comparison has the current standings side by side.
Sources
- Cloudflare: KV cache exposure and remediation
- LMSYS: SGLang security note on the Cloudflare incident
- Cloudflare status: incident jsvvrtk5hvym
*Not sure whether your hosted open-weight model shares a cache with strangers? Take the free 2-minute quiz and get matched. Then read the other October security story about keys instead of cache: the OpenCode Console breach.*