The Pulse
Cloudflare Finds 155 GLM-5.3 Responses Exposed Other Users’ Data
Cloudflare says a flaw in its Workers AI GLM-5.3 service exposed fragments of other customers’ requests in 155 responses between August 27 and September 9, 2026. The company traced the exposure to an undersized KV cache pool and a request-r
AI.info Team · Written with AI · fact-checked ·
Cloudflare says 155 responses from its GLM-5.3 model contained data from other customers’ requests, after prompts exceeded 681,280 tokens. The exposure affected the Workers AI model between August 27 and September 9, 2026, and stemmed from a mismatch between the model’s advertised context window and the memory available to process it. Cloudflare published its incident report on October 26, saying it found no evidence of deliberate exploitation.
155 responses crossed customer boundaries
The affected model, identified as @cf/zai-org/glm-5.3, ran with a context window of 1,048,576 tokens, but its prefill GPUs had KV cache space for only 681,280. Every affected response followed a prompt longer than that pool could hold. Cloudflare described the number of affected customers as small but did not disclose a total.
Cloudflare says the requests it identified, after excluding its own tests and the researcher’s, fit the timing and volume of ordinary long-context use. “We found no evidence of deliberate exploitation,” the company’s report says. That is Cloudflare’s assessment of its investigation; the post does not identify what kinds of data appeared in the exposed responses.
A rejected prompt still reached the decode GPUs
The failure involved two parts of the serving setup. First, a prompt could fit the configured context window while exceeding the smaller KV cache pool. Cloudflare says it knew about the mismatch before launch, but its tests checked successful HTTP responses and performance at long contexts rather than whether the resulting text was coherent.
Second, SGLang mishandled over-capacity prompts in disaggregated serving, where one group of GPUs processes the prompt and another generates the response. The engine marked an overlong request as rejected and substituted a one-token placeholder, but the request still passed through the prefill-to-decode handoff. Decode treated the transfer as complete and read cache pages that the new request had not overwritten, leaving earlier requests’ data in those pages.
Cloudflare’s report says the client could receive HTTP 200 rather than an error, with a coherent-looking response that included content from other users’ sessions. The issue was specific to GLM-5.3 on Workers AI, according to the company; it says its other models had cache pools larger than their configured context lengths and could not reach this rejection path.
Cloudflare fixed the configuration and the rejection path
After reproducing the issue on September 9, Cloudflare made GLM-5.3 private, corrected its configuration and deployed an engine patch before restoring the model that evening. The revised prefill pool holds about 2.04 million tokens—roughly twice the 1,048,576-token context window. The patch retires rejected requests before they enter the disaggregated handoff, preventing decode from treating a partial cache transfer as a complete prompt.
Cloudflare says it also added checks for cache-pool capacity against context length and deployed further safeguards across its production SGLang services. Those measures include holding cache pages until transfers have finished and bounding transfer batches. The company says its checks now apply to every new disaggregated deployment.
SGLang operators get an upgrade recommendation
The underlying engine changes are available upstream. Cloudflare says the patch appeared in SGLang v0.5.20, with follow-up fixes in v0.5.21 and v0.5.22, and recommends that operators use v0.5.22 or later. SGLang’s coordinated disclosure separately describes related risks involving cache pages that are released while remote writes may still be in flight.
For customers, Cloudflare’s report establishes the exposure window, affected model and trigger, but leaves two details unspecified: how many distinct customers were involved and what information appeared in the 155 responses. The company says the issue was fixed on September 9; its published count remains 155 affected responses.