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.
Keep following the evidence
Join The Impact Brief founding list for selected AI reports, their effect on people and the evidence limits. Read a sample first.
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]
Continue the story
Read next
Continue exploring cloud security: compare the finding and its evidence limits.
Northflank says rotate every stored secret now—what should customers do first?
Northflank says customers should assume user-defined environment variables were exposed. Reports of unauthorized AI API-key use make this an active remediation incident, but the company has not published how many customers or credentials were affected.
Read the next reportExplore the full source and evidence record
What this means for people
- 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.
Global context
Workers AI serves customers internationally, while breach-notification, processor, confidentiality and sector-specific duties vary by jurisdiction. Other providers may use different inference engines and cache architectures, so this mechanism cannot be assumed to apply to every hosted model.
What the evidence does not yet show
- 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
What to watch next
- Customer and regulator notifications
- Independent post-incident review
- Content-sensitivity and retention findings
- Long-context isolation tests across providers
- Adoption of SGLang 0.5.22 or backports
- Transfer checksums and cache canaries across model architectures
Living evidence record
Impact record IAI-09ULBIJ
Evidence stage
Announced
Confidence
Corroborated
Reporting basis
Multi-source analysis
Independent or research support
Present
Record status
Monitoring
Last checked
28 October 2026
Source trail
3 direct sources across 2 source types.
People impact
Documented in this record.
Uncertainty
Limits and next checks are explicit.
Stages describe the evidence available—not whether a technology is good or bad. See the public method.
Evidence trail
Sources used for this report
Links checked 28 October 2026
Research question, topics and regions
Topics: AI infrastructure · Cross-customer data exposure · Cloud security · SGLang · Workers AI · Incident response
Regions: International · United States
This report is labelled multi-source analysis. We summarise and analyse source material in our own words; company statements remain attributed claims until independently supported. Translated summaries preserve the meaning of the original source and link back to it. Read our editorial standards.
Reader commentary
What does this mean where you are?
Tell us what you have seen at work, in your community or in everyday life. A question is welcome too. No account is needed; we review notes before publishing them.
Explore commentary across the portal →Published reader notes
0No published reader notes yet. You can start the evidence-led discussion above.
Prefer a private correction or response? Contact the newsroom.