GLM-5.3 Exposed Other Customers' Data in 155 Responses

A window the cache could not hold

The KV cache is the model's working memory: pages of GPU memory holding what a prompt contained, so the model can refer back while generating. Pages are not wiped between requests, because wiping costs performance; the next request overwrites them, and the engine tracks ownership. That is standard, and it makes a bookkeeping failure a privacy failure.

Cloudflare serves GLM-5.3 on two GPU pools. Prefill machines build the cache from the prompt; decode machines generate from it. Two numbers then have to agree: the context window, 1,048,576 tokens, and the prefill cache pool, sized at startup from GPU memory left after the weights load, which held 681,280. Nothing forced them to match, and they did not.

A prompt between those numbers met this path. The scheduler marked it rejected and swapped in a one-token placeholder, so it could drain without allocating real memory. On one machine that worked, and the client got an error. Split across two pools, the rejection never reached decode. Decode had reserved pages for the full prompt, got a transfer-complete signal for one page, and generated while reading its other pages as they stood, still holding earlier requests' prompts and partial answers. The customer got a coherent reply, with the correct token count, faster than a genuine read should have allowed.

The test that passed anyway

Cloudflare's report is unusually direct about how this shipped. The company says it knew the pool was smaller than the window before launch. It expected the engine to error on prompts it could not process; its long-context tests returned successful responses, so it concluded there was no problem. Its own summary of the gap: it checked HTTP response codes and performance at long contexts, never the model's output or its coherence.

Against that, the failure mode: no error, no timeout, no garbled text, just a fast, coherent HTTP 200 assembled partly from strangers' data. A test program built on status codes could not have caught it, because the bug's output looked like success.

An earlier signal existed. Cloudflare says it found, while investigating, that the same failure had been reported to SGLang by another user on July 6, 2026, two months before the HackerOne report.

Thirteen days, fixed in one

The response was fast. Evron filed late on September 8; the next day Cloudflare reproduced the leak in 25 minutes, took the model private at 14:00 UTC, had the root cause by 14:35, and restored a rebuilt deployment with the fix by 19:40.

The scope Cloudflare reports is narrow, and it stays attributed here. GLM-5.3 was, it says, the only model affected, because every other disaggregated Workers AI deployment keeps pools larger than context length on both sides. After removing its own testing and the researcher's requests, Cloudflare says the rest matched ordinary long-context use, and that it found no evidence anyone deliberately exploited the bug. What the report does not say is whether the customers involved were told individually.

If you run the same engine, the checklist is the story

The practical payload for other operators is short. Measure the cache pool on the running engine and compare it with the context length after every change to weights, quantization or parallelism, because the pool is leftover memory and moves when anything else does. Cloudflare recommends upgrading to SGLang v0.5.22 or later, so over-length requests are rejected before the handoff. Run deferred cache release on both roles.

One limit deserves attention: Cloudflare recommends checksum and canary detection where supported, but says neither mechanism yet covers every architecture. Its own list of architectures still being added includes GLM-5.3. Operators should verify in their logs that the relevant requests are actually being checked rather than assume that enabling a detector provides complete coverage. Until they can, the defense is the unglamorous one: two numbers, measured on the live system, that are supposed to agree.

Sources

[1] Cloudflare, "Cross-request KV cache exposure in the GLM-5.3 Workers AI model, and our remediation with SGLang", October 26, 2026Read source
[2] SGLang team (RadixArk) via LMSYS, "SGLang security update: improving request isolation", October 26, 2026Read source
[3] Unite.AI, report on the Cloudflare GLM-5.3 KV cache disclosure, October 26, 2026Read source

THE ALFW VERDICT

The uncomfortable number in this report is not 155. It is 681,280 set against 1,048,576: Cloudflare knew the cache could not hold the window it was selling, shipped on the assumption that the engine would refuse anything that did not fit, and tested that assumption by watching status codes instead of reading answers. The 155 identified responses reflect a failure triggered by prompts exceeding 681,280 tokens. That unusually high threshold may have limited how often the failure could occur, but Cloudflare's report does not provide the total number of requests above it. The affected-response count therefore cannot, by itself, establish how close the isolation boundary came to holding. On Cloudflare's own account, every request over the threshold took the faulty path. The 155 identified affected responses show that the path could return data from other customers' requests; the report does not establish that every over-threshold request necessarily exposed such data.