Cloudflare says a GLM-5.3 bug leaked other users’ data in 155 responses

Cloudflare says that between August 27 and September 9, 2026, 155 responses from the GLM-5.3 model on Workers AI contained data from other customers’ requests. In its incident report, the company says only prompts longer than 681,280 tokens were affected.

The company says it found no sign of deliberate exploitation. After excluding its own testing and the researcher’s, the remaining requests matched the timing and volume of ordinary long-context use, according to Cloudflare. GLM-5.3 (@cf/zai-org/glm-5.3) is a Z.ai model built for agentic coding, and Cloudflare says no other Workers AI model was affected.

A context window bigger than the memory behind it

Cloudflare traces the leak to two overlapping problems. The first was its own configuration: GLM-5.3 was launched with a 1,048,576-token context window, but the memory pool for the model’s KV cache on the prefill GPUs held only 681,280 tokens. Cloudflare says it knew about the gap before launch and expected the inference engine to return an error for anything too long. Its long-context tests returned successful responses, so it did not treat the gap as a problem. The company now admits it checked HTTP status codes and performance, not whether the output was coherent.

The second problem sat in SGLang, the open-source inference engine Cloudflare uses. In a setup that splits work between prefill and decode GPUs, a prompt too large for the pool was marked as rejected and swapped for a one-token placeholder. But the request was not aborted. Prefill sent a single page of cache to the decode node, and decode treated the transfer as complete. It then read all the pages reserved for the request, and most still held data from earlier users. The client received an HTTP 200 instead of an error, with a coherent reply.

From a HackerOne report to a restored model in a day

Gadi Evron of Knostic reported the problem on September 8 through Cloudflare’s HackerOne program. Cloudflare says it began verifying the report the next morning, declared a security incident at 13:22 UTC and reproduced the leak with two independent accounts. It set the model to private at 14:00, returning HTTP 400 errors, and rolled the corrected configuration to all prefill nodes by 14:52. After the change, the prefill pool holds about 2.04 million tokens, roughly double the context length.

A rebuilt deployment with a Cloudflare-written engine patch followed, and the model returned to public use at 19:40 UTC on September 9. The exposure ran from launch on August 27, so it lasted about two weeks before anyone reported it. Cloudflare published its account on October 26, alongside a post from the SGLang team, as a coordinated disclosure.

Why a quiet failure is the hard one to catch

The rules-and-safety angle here is less about the single incident than about how it went unnoticed. Inference engines do not zero KV cache pages between requests, which Cloudflare calls common and necessary for performance. That makes the engine responsible for tracking who owns each page, and a mistake produces no error: the reply looks normal and simply contains someone else’s text.

The SGLang team’s own post suggests the exposure goes beyond one cloud provider. It says default disaggregated configurations using RDMA transfer backends were affected from the v0.4.x line, from early 2025, until v0.5.21 (v0.5.22 for the MORI backend). It also says the integrity check added upstream, which uses an Adler-32 checksum, is off by default. SGLang adds that it has not backported the fixes to older release branches. Operators still on old builds therefore need to upgrade themselves.

SGLang also gives a sense of how large these transfers get: an 800K-token request once moved 30 GB in a single call. Long agentic coding sessions are exactly the workloads that push prompts into that range. A related race condition, in which a request aborts while data is still being written, is described by SGLang as probabilistic, with long contexts widening the window.

What operators and customers should take from it

For anyone running SGLang in disaggregated mode, Cloudflare recommends comparing the KV pool size with the context length on every node after any change, and lowering the context length if the pool is smaller. It also advises upgrading to v0.5.22 or later and enabling deferred KV release on both prefill and decode roles. Where the model architecture supports them, it suggests switching on --disaggregation-enable-kv-checksum and --kv-canary. The company says neither flag yet covers every architecture, and it names GLM 5.3, GLM 5.3 Flash and DeepSeek V4 as ones it is working to add.

Cloudflare says it applied the engine fix and extra hardening to every SGLang model it serves, and that its deployment checks now require them. It also describes longer-term work: a prototype that tags each cache page so a request cannot read a page it does not own, and formal verification of the RDMA transfer protocol. It says the tag prototype cost under 1% in throughput and tail latency, but it was disabled in August over reliability problems.

The report does not say how many customers were affected, what kind of data appeared in the 155 responses, or whether any of it was sensitive. Those figures and the finding of no deliberate exploitation come from Cloudflare’s own analysis and have not been independently verified. Cloudflare directs further security reports on Workers AI to its HackerOne program.