Cloudflare's Workers AI leaked 155 cross-tenant responses through SGLang KV cache — operators should patch

On October 26, 2026, Cloudflare published a coordinated incident report describing cross-request data exposure in the GLM-5.3 Workers AI model. Between August 27 and September 9, 155 responses to requests longer than 681,280 tokens contained data from other customers' prior requests. A GLM-5.3 deployment advertised a 1,048,576-token context window but its prefill KV pool held only 681,280 tokens. In disaggregated SGLang, a rejected over-capacity request was replaced with a placeholder, yet forwarded to decode as if its full KV cache had arrived. Decode then read stale pages from earlier requests. Cloudflare corrected the configuration and patched the engine September 9; upstream SGLang fixes landed across v0.5.20–0.5.22. Cloudflare recommends v0.5.22 or later for other disaggregated operators.

This is a concrete cross-tenant confidentiality failure in shared inference, not a speculative prompt-injection scenario. A normal HTTP 200 and apparently coherent model response hid the memory-isolation bug. Teams hosting multi-tenant models on disaggregated prefill/decode systems need to test the capacity and rejection path, verify that every allocated KV page belongs to the current request, and apply the relevant SGLang fixes. Customers of the specific Cloudflare model were exposed during the historical window; Cloudflare says it found no deliberate exploitation and no other Workers AI model affected.

The model's published context window was about 1.05 million tokens, but the prefill cache pool could hold only 681,280. When longer prompts arrived, SGLang marked the request rejected and replaced its prompt with a one-token placeholder. In disaggregated mode, admission logic still treated it as active, sent one page and marked transfer complete. The decode worker reserved pages for the original prompt and read previously occupied pages not overwritten by the placeholder, producing a coherent but contaminated response.

Cloudflare received a report from Knostic researcher Gadi Evron on September 8, reproduced it with two accounts, took the model offline September 9, then deployed a larger pool and a safe rejection path before restoring service. It identified 155 affected responses from August 27 through September 9, all above the 681,280-token threshold. Cloudflare reports no evidence of deliberate exploitation and says no other Workers AI models had this exposure.

The unsafe admission/rejection path was patched in SGLang v0.5.20, with follow-up fixes in v0.5.21 and v0.5.22. Cloudflare also discusses transfer integrity checks, abort handling, deferred page release and bounded transfer batches to reduce related stale-page risks. It recommends v0.5.22 or later for operators using disaggregated SGLang, or backporting the relevant patches where an upgrade is impossible.

Check the effective KV pool size at runtime against the maximum supported context window, not just HTTP status or token accounting. Reproduce oversized-prompt and rejected-request behaviour with separate tenants, including disconnect and abort races. Verify that invalid requests return an error and cannot decode over stale KV pages. Enable supported transfer checksums and canary checks, but confirm architecture coverage rather than assuming every model is protected.