AI Pulse

A bug in Cloudflare’s AI service sent some users other customers’ data

For two weeks, very long prompts to the GLM-5.3 model on Cloudflare Workers AI could get answers containing fragments of other customers’ requests. Cloudflare says 155 responses were affected, with no sign of deliberate abuse.

Illustration: a row of black memory blocks, most outlined, a few filled grey, with one red block slipping from one row into the row below
Illustration: AI Pulse.

Cloudflare published a detailed report on 26 October about a data-exposure bug in Workers AI, its service for running AI models. Between 27 August and 9 September, some customers using the GLM-5.3 model received responses that contained data from other customers’ requests made shortly before theirs.

How big it was

Cloudflare says 155 responses were affected, all to prompts longer than 681,280 tokens, which is several novels’ worth of text. A security researcher, Gadi Evron of Knostic, reported the problem on 8 September. Cloudflare reproduced it the next morning, took the model offline within 40 minutes of declaring an incident, and restored a fixed version the same day. It says no other model on Workers AI was affected, and that the affected requests looked like ordinary long-context use rather than someone exploiting the bug.

What went wrong

Two problems combined. AI models keep a working memory of the prompt, called the KV cache, in a shared pool on the graphics chips. Cloudflare had set GLM-5.3 to accept prompts of up to 1,048,576 tokens, but the pool only had room for 681,280. The company knew about the mismatch before launch but expected the software to return an error for prompts that did not fit, and its tests returned successful responses.

The second problem was a bug in SGLang, the open-source engine Cloudflare uses. In Cloudflare’s set-up, one group of chips reads the prompt and another writes the answer. A prompt that was too long was marked as rejected, but it went through anyway with almost nothing written to memory, and the answering side read memory pages still holding earlier requests. The customer got a normal-looking “success” response with someone else’s data in it.

The fix, and the lesson

Cloudflare enlarged the memory pool to about twice the context length and patched the engine so rejected requests stop before any data is handed over. The fix is in SGLang version 0.5.20, with follow-ups in 0.5.21 and 0.5.22, and Cloudflare recommends that everyone running SGLang upgrade to 0.5.22 or later. The same bug had been reported to SGLang by another user in July.

Cloudflare is candid about its own mistake: it checked only that responses succeeded, not that they made sense. It now checks the memory pool size against the context length directly before shipping changes. The report also explains why this class of bug is dangerous: memory pages are reused between requests without being wiped, for speed, so the software has to track exactly who owns each page.