Why Did Cloudflare's GLM-5.3 Hand Users Other Customers' Data?

Cloudflare says 155 GLM-5.3 responses on Workers AI held other customers' data, thanks to a KV cache config gap and an SGLang bug. Here's what to check now.

TheTechLane cover in black, electric lime and hot pink: a large TL logo beside the headline Whose data is in my answer?, a 155 leaked responses tag, and a row of one fresh lime cache page and seven stale pink pages, framed by a grid of memory pages

Cloudflare says 155 responses from the GLM-5.3 model on its Workers AI platform contained data from other customers' requests, and every one of them answered a prompt longer than 681,280 tokens. The company published the incident report on Monday, October 26, in a coordinated disclosure with the maintainers of the open-source SGLang inference engine.

Here's what you need to know:

  • The exposure ran from August 27 to September 9, 2026, starting the day GLM-5.3 (@cf/zai-org/glm-5.3) launched on Workers AI.

  • Cloudflare advertised a 1,048,576-token context window, but the KV cache pool on its prefill GPUs only held 681,280 tokens.

  • An SGLang bug in disaggregated prefill/decode mode let over-length prompts read stale cache pages instead of failing with an error.

  • Cloudflare says it found no evidence of deliberate exploitation and that no other Workers AI model was affected.

  • If you self-host SGLang this way, Cloudflare recommends upgrading to v0.5.22 or later.

UML sequence diagram of the GLM-5.3 leak on Workers AI: a client sends a prompt over 681,280 tokens, the prefill GPU marks it rejected and swaps it for a 1-token stub, decode reserves pages for the full prompt but prefill writes only one page and reports transfer complete, decode attends over all reserved pages that still hold earlier users' data and returns HTTP 200; the fix in SGLang v0.5.22+ rejects the request at admission with HTTP 400 before any KV transfer

How a rejected prompt leaked data: the GLM-5.3 KV cache bug, step by step

What Happened

Security researcher Gadi Evron of Knostic reported the issue through Cloudflare's HackerOne program on September 8. According to Cloudflare's incident report, very long prompts sent to GLM-5.3 "sometimes returned text that belonged to other users' sessions."

Cloudflare reproduced the leak the next morning using two independent accounts, set the model to private at 14:00 UTC on September 9, and restored it at 19:40 UTC the same day with a fixed configuration and a patched engine.

The root cause was two problems stacked together. First, a misconfiguration. Cloudflare says it knew about the gap between the 1M-token context window and the 681,280-token prefill pool before launch, but expected the engine to reject anything it couldn't process. Its long-context tests returned successful HTTP codes, so it didn't think it was a problem. The company admits it "only validated HTTP response codes and engine performance at long contexts, without validating model output and coherence."

Second, an engine bug. In SGLang's disaggregated mode, separate prefill GPUs process the prompt and hand its KV cache over RDMA to decode GPUs that generate the reply. An over-length prompt was marked as rejected and swapped for a one-token placeholder. But both admission queues only checked whether a request was finished, not rejected, so it sailed through. Prefill sent one page of cache, decode attended over all the pages it had reserved, and the rest still held earlier users' prompts and partial generations.

The client got an HTTP 200 and a coherent answer instead of an HTTP 400. As the SGLang team's security post explains, the single-node rejection path returned an error; only disaggregated serving was affected.

Why It Matters

This wasn't a model problem. It was a serving problem, and that's the uncomfortable part. Cloudflare notes that KV cache pages "are not currently zeroed between requests" because doing so costs performance, so the engine alone is responsible for tracking who owns each page.

That design is common across inference engines. And the bug wasn't unknown: it had been reported to SGLang as issue #30233 on July 6, 2026, weeks before GLM-5.3 launched, as Unite.AI's write-up of the disclosure points out.

There's a bigger pattern, too. SGLang says a related class of race conditions, where an aborted request's in-flight RDMA writes land in another request's cache, affected default disaggregated setups from the v0.4.x line (early 2025) until v0.5.21. Its team warns that long-context workloads widen that window, and that a deployer "has no reliable way to tell" whether corruption already happened, because it leaves no error or log line.

Million-token contexts are a selling point for coding agents. This incident shows they're also where multi-tenant isolation gets hardest. Open questions remain, though: the report doesn't say how many distinct customers were affected, what kind of data leaked, or how customers were notified.

What It Means for Developers

If you call GLM-5.3 on Workers AI, Cloudflare says the fix has been live since September 9. If you run your own inference stack, this is your checklist, straight from Cloudflare's and SGLang's recommendations:

  • Compare KV pool size to context length on every prefill and decode node, from the engine's startup log, after any change to weights, quantization, parallelism or memory fraction. If the pool is smaller, lower the context length.

  • Upgrade SGLang to v0.5.22 or later, which includes the admission fixes (#36988 and #38935). SGLang says it hasn't backported them to older release branches.

  • Keep deferred KV release on for both roles (the default since v0.5.21) and bound Mooncake transfer batches.

  • Turn on corruption detection with --disaggregation-enable-kv-checksum where your model supports it, and watch the new sglang:decode_deferred_kv_release_total metric.

  • Test output, not just status codes. Canary markers in long prompts would have caught this before launch.

  • Treat hosted model calls as shared infrastructure. Don't send secrets or customer data in giant prompts unless you need to.

Cloudflare has been busy lately; we covered its Rust port of the TypeScript compiler, tsrs recently. And for another reminder that AI infrastructure needs hard boundaries, see how a Qwen model tried to upload a file to Beijing from a test sandbox.

Flowchart checklist for disaggregated SGLang deployments: after any config change, check that the KV pool is at least the context length on every node and lower the context length if not, upgrade to SGLang v0.5.22 or later with admission fixes 36988 and 38935, keep deferred KV release on with bounded Mooncake batches, enable KV checksums and watch release metrics, and test long prompts with canary markers before shipping

Before you ship disaggregated SGLang: the operator checklist from Cloudflare and SGLang

What's Next

The researcher's own write-up is still coming, according to SGLang, and it should describe the discovery and external validation.

Cloudflare says it's working with the SGLang team to build page-level ownership tags into the engine, so decode can detect that it's about to read a page it doesn't own and fail that one request. It also plans to use formal methods to model and prove the safety of its RDMA-based KV cache transfer protocol.

Still in progress upstream: zeroing KV pages on release (a draft proposal) and extending checksums beyond the prefill-to-decode handoff. Expect other inference providers to face questions about how they size and isolate their caches.

FAQ

Was GLM-5.3 itself the problem?

No. Cloudflare says the cause was its own configuration plus an SGLang serving bug. GLM-5.3 was the only affected model because it was the only Workers AI deployment whose KV pool was smaller than its context length.

Was my data exposed?

Only responses to GLM-5.3 prompts over 681,280 tokens between August 27 and September 9 were affected, 155 in total. Cloudflare hasn't publicly said how many customers that covers or how they were notified.

Am I affected if I run SGLang myself?

Only in disaggregated prefill/decode mode; SGLang says the single-node path returned an error. Upgrade to v0.5.22 or later and check your KV pool against your context length.

Sources

Follow TheTechLane

Keep learning AI, development, and modern developer technologies with TheTechLane.

Learn • Build • Share

Follow @thetechlanehq for more developer guides, tutorials, and practical technology content.