On October 26, Cloudflare disclosed that 155 responses from its GLM-5.3 model on Workers AI contained data from other customers’ requests. If your team sends sensitive prompts to a shared inference service, this incident is a useful test of how you assess AI vendor risk. The failure happened below the model, in GPU memory handling that no customer can see.
The incident was small in count and narrow in trigger. It still shows that “multi-tenant” is a property of the runtime, which a contract clause cannot enforce.
What Cloudflare says happened
According to Cloudflare’s post, the exposure ran from August 27, 2026, the model’s launch date, to September 9. All 155 affected responses were to prompts longer than 681,280 tokens, and they contained data from other customers’ requests to the same model made shortly before. Cloudflare says no other Workers AI model was affected and that it found no evidence of deliberate exploitation.
Security researcher Gadi Evron of Knostic reported it through Cloudflare’s HackerOne program on September 8. Cloudflare declared an incident at 13:22 UTC on September 9, set the model to private at 14:00 UTC, and restored it at 19:40 UTC after rebuilding the deployment with a configuration fix and an engine patch.
Two details are missing from the disclosure. The post does not say how many distinct customers were affected or what kinds of data were exposed, and it does not describe whether affected customers were notified. 155 counts responses, not customers. Treat any larger or smaller number you read elsewhere as unconfirmed.
Two small problems that added up
The root cause was a combination of two issues, and neither looks dramatic alone.
- Configuration: GLM-5.3 was deployed with a 1,048,576-token context window, but the prefill KV cache pool held only 681,280 tokens. Cloudflare knew about the mismatch before launch and expected the engine to return an error for oversized prompts. Its long-context tests returned successful responses, so it did not treat the gap as a problem.
- Engine bug: in SGLang’s disaggregated prefill/decode mode, a rejected over-length request was swapped for a one-token placeholder instead of being aborted. Prefill transferred KV pages to decode, and decode then attended over stale pages left by earlier requests. The client got HTTP 200, not an error.
The second problem had been visible upstream for a while. Cloudflare notes that the bug was reported as SGLang issue #30233 on July 6, 2026, which describes aborted over-length prefill requests making decode generate garbage from incomplete KV cache. The issue was later closed by a bot for inactivity on September 5, four days before Cloudflare declared its incident.
The fix has two parts. Cloudflare raised the prefill KV pool to about 2.04 million tokens, roughly twice the context length, and the engine now retires rejected requests at the admission queue before any KV transfer happens. Those engine fixes landed in SGLang v0.5.20 and v0.5.21, and Cloudflare recommends operators run v0.5.22 or later.
Why a 200 OK is not a safety signal
The failure returned a normal response code. Nothing in the client logs would have flagged it, and the leaked content arrived inside an otherwise valid completion. As one write-up on DEV Community puts it, a clean HTTP status does not rule out leakage. That post also suggests a customer-side canary test: send a unique marker string, send unrelated requests from a fresh session, and scan the responses for the marker. Its own caveat matters, though: a clean run proves little, because this bug only appeared with prompts beyond the pool size.
That caveat is the real lesson. You cannot black-box test your way to isolation assurance. AI Weekly raises the open question of whether other inference providers ran vulnerable builds, and nobody outside those providers can answer it today.
The gap between policy and runtime
Cloudflare’s Workers AI data usage documentation says inputs and outputs are Customer Content, that Cloudflare does not retain them for standard stateless inference once they are no longer needed, and that it does not make them available to other customers. That is the right commitment. The incident shows how a runtime defect can break it without any policy being changed or ignored.
The OWASP Top 10 for LLM Applications entry on sensitive information disclosure lists this exact failure class as an example: a user receiving another user’s data in a response. Its mitigations are mostly about sanitization, least-privilege access and published retention policies. It does not address tenant separation in the serving layer directly, which is where this incident happened. Your checklist needs to cover that part yourself.
A due diligence checklist for shared inference
Cloudflare’s own remediation list is a good template for what to ask any provider. Here is how it translates into vendor questions:
- Capacity checks: does the provider verify that KV cache pool size is at least the advertised context length before a model goes live? Cloudflare now runs that check before deployment.
- Failure behavior: what happens when a request exceeds limits? The right answer is an explicit error before any memory allocation or transfer, not a silent downgrade.
- Corruption detection: is KV checksum or canary detection enabled in production? Cloudflare lists options such as –disaggregation-enable-kv-checksum and –kv-canary for SGLang where the model supports them.
- Upstream tracking: how does the provider triage open bugs in the inference engines it runs? A July bug report matched a September incident.
- Disclosure: will you be told which of your requests were affected, and on what timeline? This is the one question Cloudflare’s post leaves unanswered.
- Your own exposure: do you need to send full long-context documents to a shared endpoint at all, or can you redact, chunk or run that workload on dedicated capacity?
If you run SGLang yourself in disaggregated mode, the same advice applies to you. Measure KV pool size against context length on every prefill and decode node after any relevant change, upgrade to v0.5.22 or later, and confirm corruption detection is actually active in the logs.
What to do this week
Inventory which workloads send long prompts to shared inference endpoints, since those were the only ones exposed here. Check which providers and engine versions sit behind them. Then rank the data by what you could not accept appearing in a stranger’s response, and decide whether that data belongs on shared capacity at all.
Cloudflare deserves credit for publishing a detailed timeline, including the part where its own tests passed when they should have raised a flag. Most vendors will not give you that much detail, so ask for it before an incident, not after. If you want a second pair of eyes on how AI vendors fit into your architecture and risk review, talk to the Luby team.