- Cloudflare says 155 responses from the GLM-5.3 model on its Workers AI service contained other customers' data, all for prompts longer than 681,280 tokens.
- Cloudflare says it found no evidence of deliberate exploitation. Its pre-launch tests checked response codes and speed, not whether the answers were coherent.
- Teams buying hosted AI should ask providers how they test output correctness, and operators of SGLang should update to v0.5.22 or later.
A green dashboard is not a correct answer
An AI service can return a clean success code and still hand you someone else's data. That is the lesson of a disclosure Cloudflare published on October 26, 2026. The company says its own testing looked healthy while a long-prompt flaw was already live.
The idea for leaders: when AI is hosted, "it responded" and "it responded correctly" are different tests. Only the second one protects customers.
What Cloudflare says happened
Cloudflare says security researcher Gadi Evron of Knostic reported the problem through its HackerOne program on September 8, 2026. It affected the GLM-5.3 model on Workers AI, Cloudflare's service for running AI models. GLM is a text model from Z.ai. Cloudflare says exposure began on August 27.
Between August 27 and September 9, Cloudflare says 155 responses contained data from other customers' requests to the same model. All were replies to prompts longer than 681,280 tokens. A token is a small chunk of text, roughly a word fragment.
Per Cloudflare, its team recreated the problem the morning after the report. The model was pulled from service 40 minutes after an incident was formally declared. Service returned on September 9. Cloudflare says no other Workers AI model was affected.
Cloudflare also says the affected requests match ordinary long-context use in timing and volume. It found no evidence of deliberate exploitation. That is Cloudflare's own finding, and the post does not describe independent verification.
How the leak worked
Cloudflare uses SGLang, an open-source engine that runs AI models. For GLM-5.3 it split the work in two. One group of GPUs reads the prompt and builds a working memory of it, called the KV cache. A second group uses that memory to write the answer.
The memory lives in fixed-size pages. Cloudflare says pages are not wiped between requests. The next request simply overwrites them. The engine is therefore responsible for tracking who owns each page.
Cloudflare configured the model to accept prompts up to 1,048,576 tokens. But the memory pool on its prefill GPUs held only 681,280 tokens. Cloudflare says SGLang sizes that pool from leftover GPU memory, and nothing forces it to match the advertised limit.
A prompt too big for the pool was meant to be rejected. According to Cloudflare, the engine swapped it for a one-token placeholder. In this split setup it then sent the placeholder's memory onward as if the request were normal. The answering side saw "transfer complete" and assumed the full prompt had overwritten old data. Most of it had not.
The answering GPUs then wrote a reply while reading stale pages that still held earlier customers' text. Cloudflare adds that a different SGLang user had filed this same defect upstream on July 6, 2026, as issue #30233. That was weeks before the model launched.
The gap was in the testing
Cloudflare says it knew about the size mismatch before launch. Its team assumed the engine would turn away prompts it could not hold. Long-context tests came back with successful responses, so the team judged the mismatch harmless.
The company names this as a gap. It says it "only validated HTTP response codes and engine performance at long contexts, without validating model output and coherence." This is a candid admission.
It is an easy pattern to fall into: check that the model answered, and how fast. Cloudflare's account shows why that is not enough. Nothing crashed and no alarm sounded. The failure was silent.
The fix, and the wider pattern
Cloudflare fixed this in two ways. First, it changed the configuration so the memory pool is larger than any prompt the model accepts. Cloudflare puts the new pool at about 2.04 million tokens, so a valid prompt always fits. Second, it patched the engine so a rejected request ends with its original error before any memory transfer. Before restoring the model, Cloudflare ran both changes past the researcher's reproduction script and its own canary-marker tests.
Cloudflare describes this as one of several KV cache memory bugs it has been working on with SGLang's maintainers for months. It recommends that all SGLang operators update to v0.5.22 or later.
What to ask your team and your providers
Ask any hosted-AI vendor whether it checks the content of long-context outputs, not only response codes. Ask whether it compares memory capacity with advertised limits before each deployment. Cloudflare says it now does this check directly from the running engine.
If your own teams run SGLang in the split setup, ask which version they run and whether it is v0.5.22 or later. Ask whether shared prompts or customer data could pass through the model's memory.
Finally, ask what your acceptance test for a new AI model actually checks. Cloudflare's own account shows that "no errors" and "no leaks" are separate claims.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Cloudflare.
