Cloudflare's GLM-5.3 leak: 155 responses carried other customers' data after a context window mismatch

An AI inference service handed some customers a stranger's data, and the cause was a mismatch between two numbers. Cloudflare's incident summary, published October 26, 2026, says 155 responses from its GLM-5.3 model on Workers AI contained data from other customers' requests. It is a useful case study in how inference leaks happen, because nothing in it involves the model being clever. It involves a server being asked to hold more than it was built to.

What happened

GLM-5.3, the model identified as @cf/zai-org/glm-5.3, launched on Workers AI on August 27, 2026. Cloudflare deployed it with a context window of 1,048,576 tokens, but the prefill KV cache pool, the memory where the server keeps the attention state for prompts it is reading, held only 681,280 tokens. The summary says that between August 27 and September 9 a small number of customers received responses containing data from other customers' requests to the same model, shortly before theirs. All 155 affected responses were to prompts longer than 681,280 tokens.

Cloudflare says no other Workers AI model was affected. It also says the affected requests were consistent in timing and volume with ordinary long-context use, and states: "We found no evidence of deliberate exploitation." That is Cloudflare's own conclusion from its own logs, and readers should weigh it that way. Our earlier tracker of open-weight cyber capability covers GLM-5.3 as a model. This incident is about how it was served.

The two faults

The post describes two overlapping problems. The first was the configuration: a pool smaller than the context window the product advertised. The second was a bug in SGLang, the open-source serving engine. When a prompt exceeded the pool, SGLang rejected it internally and swapped in a one-token placeholder. In disaggregated mode, where prefill and decode run on separate machines, the admission queues treated the rejected request as live and passed it to decode. Decode then attended over stale KV pages left behind by earlier requests. The client received an HTTP 200, a success code, instead of an error.

That detail is why the leak was quiet. Nothing crashed and no error was logged for the customer. The model simply answered from memory that was not theirs.

How fast it was fixed, and how slowly it was found

The timeline in the post is precise, in UTC. Gadi Evron of Knostic reported the issue through Cloudflare's HackerOne program at 23:11 on September 8, with a reproduction script. Cloudflare declared a security incident at 13:22 on September 9 and reproduced the leak within 25 minutes. It set the model to private, returning HTTP 400, at 14:00. It identified the root cause at 14:35, moved all prefill nodes to the corrected configuration at 14:52, and restored the model to public at 19:40 after rebuilding the deployment with an engine patch.

The response, from report to fix, took about 20 hours. The exposure itself ran for 13 days before anyone outside reported it. Both facts are true, and the second is the lesson. A pre-launch check that compared pool size to context length would have caught the mismatch on day one. Cloudflare now lists that check as mandatory.

What changed

On configuration, Cloudflare aligned GLM-5.3 with its GLM-5.2 setup, raising the prefill pool to about 2.04 million tokens, roughly twice the context length. On the engine, rejected requests are now retired at the admission queue with their original error, before any KV transfer. The post cites upstream SGLang fixes, PR #36988 and PR #38935, and says decode now verifies the transferred token count. Public release notes on GitHub show SGLang v0.5.21 on October 2 and v0.5.22 on October 19, matching the dates in Cloudflare's timeline, though we could not confirm from the excerpts we read which release carries which fix.

Further hardening includes deferred KV page release, bounded Mooncake transfer batches, and a load balancer change so client disconnects no longer abort mid-transfer. Cloudflare says it plans per-read page-ownership tags in SGLang and formal verification of its RDMA-based KV cache transfer protocol.

After the fix

Cloudflare met the SGLang maintainers at RadixArk on September 10 and rolled out additional hardening between September 11 and 19. It then waited until October 26 for coordinated publication, after the upstream releases on October 2 and October 19. The post lists a new mandatory pre-deployment check that compares KV pool size to context length, which is exactly the check that would have caught the original mismatch. A disclosure that comes six weeks after the fix is slower than some customers will like, and the delay is explained by that coordination with the open-source project.

Who should check what

The post's advice to SGLang operators is plain: verify KV pool size against context length on every node, upgrade to v0.5.22 or later, enable deferred KV release, bound transfer batches and turn on corruption detection where supported. Anyone running long-context models on shared infrastructure should add a test that sends an oversized prompt and checks for a clean error.

Customers of any hosted model should ask a vendor two questions: how does the service handle a prompt it cannot fit, and do concurrent customers share cache memory? Shared state is the efficient design, and it is also what turns a small bug into a cross-customer leak.

What we would watch

This is not a story about an AI going rogue. It is a story about plumbing, and it will repeat as context windows stretch past a million tokens and serving stacks get more complex. The control to watch is the boring one: whether providers test the failure path, not just the happy path, before a model goes public.