How did 155 AI responses expose another customer’s data? A patched cache boundary failed
New analysis of disclosures dated 26–27 October: Cloudflare says one Workers AI model returned stale cache content from other customers in 155 responses between 27 August and 9 September. The service was patched on 9 September; the reports do not identify 155 customers or disclose the sensitivity of every leaked fragment.
The short version
- What happened
- Cloudflare says 155 GLM-5.3 responses between 27 August and 9 September contained information from other customers' recent requests; that is a response count, not a disclosed customer count.
- Who it affects
- A customer could receive fragments associated with someone else's AI request, while the original customer might not know their material crossed the boundary. The public reports do not reveal whether the fragments contained personal data or other sensitive records.
- What remains unproven
- Provider-reported production impact count
Keep in mind
Provider-reported production impact count
155 affected responses is not a customer count
No public content-level inventory of exposed fragments
No evidence of deliberate exploitation does not prove no recipient saw or retained data
Only one Cloudflare model was confirmed affected
Researcher testing used unusually long prompts
Incident was remediated on 9 September and disclosed later
Multi-source analysis · 3 linked sources. Primary analysed source date: 26 October 2026. Latest linked supporting source: 27 October 2026.
Read the full report · 4 min The evidence, methods, implications and limitations
The service returned another request's cache instead of an error
Cloudflare has disclosed that one model on Workers AI crossed a customer-isolation boundary. Between 27 August and 9 September, 155 responses from `@cf/zai-org/glm-5.3` contained material from other customers' recent requests. The provider says every affected response followed a prompt longer than 681,280 tokens. Knostic, the reporting researcher, reproduced unrelated output from an ordinary paid account and found sibling models either processed comparable requests correctly or rejected them.
The count describes responses, not people or accounts. Cloudflare has not published how many customers sent or received the material, what each fragment contained, whether recipients retained it, or how many original requests contributed data. Its traffic review found no pattern of repeated deliberate exploitation, which is narrower than proving that no exposed information was seen, copied or consequential.[1][2][3]
A configuration mismatch made an engine bug reachable
The model advertised a 1,048,576-token context, while its prefill GPU cache held 681,280 tokens. Requests between those limits were marked for rejection. In SGLang's disaggregated setup, however, the rejected prefill request could still tell a separate decode node that transfer was complete after writing only a placeholder page. The decode node then generated against reserved pages that still held earlier requests. Cloudflare says its pre-launch checks validated HTTP success and throughput but not whether long-context output remained coherent.
This was not evidence that the language model memorised or hallucinated the leaked text. It was an infrastructure ownership failure: cache pages from one request remained readable to another request after the handoff logic accepted an incomplete transfer. That distinction matters because model safeguards alone cannot repair isolation below the model layer.[1][2]
The distinction that matters
Where the isolation boundary failed
The configured context limit was larger than the cache available on the prefill node, and a rejected handoff reached decode without overwriting every reserved page.
Expected path
Prompt fits memory or returns an error
Decode reads only cache pages owned by that request
Failed path
Oversized prompt became a placeholder transfer
Decode attended to stale pages from earlier requests
Patched path
Capacity checks and rejection before handoff
Invalid requests stop before cache transfer and generation
The incident is fixed, but operators need to verify their own serving stacks
Cloudflare declared the incident on 9 September, took GLM-5.3 private, enlarged the prefill pool and patched the rejection path before restoring the model that evening. It says no other Workers AI model was affected. SGLang documents related fixes across versions 0.5.20 to 0.5.22 and recommends that disaggregated-serving operators compare actual cache capacity with context length, reject failed handoffs before decode, preserve cache ownership during aborts and verify transfers.
For organisations using hosted AI, the practical question is whether contracts and incident processes expose model-specific failures quickly enough to protect customers whose prompts may contain code, business records or personal data. Confidence would improve with customer-level notification numbers, categories of exposed information, retention findings, an independent post-incident assessment and evidence that equivalent long-context boundary tests now run across every model and deployment change.[1][2][3]