The News, Explained
On October 26, 2026 (UTC), Cloudflare disclosed an incident in which responses from its GLM 5.3 model on Workers AI included content from other users’ requests. Workers AI lets developers call AI models running on Cloudflare’s servers. The company dates the exposure to August 27 through September 9 and says the model was restored on September 9. October 26 is the report’s publication date. Source
What 155 affected responses describes
Cloudflare says it identified 155 affected responses from @cf/zai-org/glm-5.3. Those responses were returned to inputs longer than 681,280 tokens. Tokens are pieces of text that a model processes. The reported figure counts responses; it should be read separately from a count of exposed user accounts. The failure allowed content from an earlier request by another customer to appear in a later response from the same model. Source
The company says its investigation found that no other Workers AI model was affected and found no evidence of deliberate exploitation. This article explains the company’s investigation report and public incident record. The public status page also records an investigation into errors when using GLM 5.3 and resolution on September 9. Source Source
How rejecting a long input broke isolation
The cause involves the model’s temporary working memory. A GPU is a processor that handles many calculations in parallel, including graphics and AI work. A KV cache stores calculations from text already read in GPU memory, so the model can use them when generating the next piece of its answer. Cloudflare separated the servers that process an input from those that continue generating an answer. The first group passed its working data to the second. Source
The model’s advertised context window—the range available for processing input and output—was 1,048,576 tokens. However, the KV cache pool on the input-processing servers held only 681,280 tokens. Cloudflare says it knew about that difference before launch but interpreted successful responses to long inputs as evidence that the software running the model could handle it. Its tests checked response codes and performance without validating the output’s coherence. Source
The failure was in the internal path for rejecting requests larger than the pool. The engine calculated a one-token placeholder instead of the original input, then still signaled that data transfer was complete. The answer-generating server treated its allocated memory as if the new request had filled it. Unwritten portions retained earlier requests’ input and partial generations. A successful response code and a coherent answer could therefore accompany output that referred to another request’s data. Source
Cloudflare says it disabled the model, enlarged the memory pool and patched the path so rejected requests would stop before the transfer stage. It validated the changes using the researcher’s reproduction procedure and tests with distinct marker data before restoring public access. The company describes further work on memory ownership and transfer checks, while verification that works across every model remains a development goal. Source
OYOPICK’s Take
Reusing server working memory across requests helps limited GPU resources serve more AI work. The revealing part of this report is that Cloudflare used successful response codes to judge a memory-size mismatch it already knew about. Testing whether a request succeeded and testing whether it stayed separate from another user’s data answer different questions.
Wider use of shared AI services should be accompanied by better evidence that those boundaries hold. Cloudflare’s account of the cause and the gap in its testing gives readers something concrete to assess. If its developing memory-ownership checks work reliably in production and cover more models, they could strengthen trust. That assessment depends on subsequent deployment results.