Cloudflare: GLM-5.3 bug sent other users' data in 155 responses

Cloudflare: GLM-5.3 bug sent other users' data in 155 responses

26 October 2026: Cloudflare says that a small number of customers using the GLM-5.3 model on its Workers AI platform received responses containing data from other customers' requests, 155 responses in all, between 27 August and 9 September. Every affected response answered a prompt longer than 681,280 tokens. Cloudflare took the model offline on 9 September, restored it the same evening with a corrected configuration and a patched inference engine, and says no other Workers AI model was affected.

Not yet independently verified. This rests on Cloudflare's own report. We found no CVE or GHSA identifier for the SGLang bug, and the report does not say whether or how the affected customers were told. We will update this when it can be confirmed, and remove this note.

The company published its report on 26 October as a coordinated disclosure with the security researcher who found the flaw, Gadi Evron of Knostic, and with RadixArk, the company behind the open-source SGLang inference engine. It says it found no evidence of deliberate exploitation: after excluding its own tests and the researcher's, the requests looked like ordinary long-context use.

How a rejected prompt read someone else's cache

Two problems overlapped. Cloudflare deployed GLM-5.3 (@cf/zai-org/glm-5.3) with a context window of 1,048,576 tokens, but the KV cache pool on its prefill GPUs held only 681,280. It knew of the mismatch before launch and expected the engine to reject prompts it could not fit; its long-context tests returned success codes, so it did not look further.

The second problem was in SGLang's disaggregated prefill and decode mode. An over-length prompt 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 reported the transfer complete. The decode node had reserved pages for the full prompt and read all of them, and the pages this request never wrote still held fragments of earlier users' prompts and replies. The client got HTTP 200 and a coherent answer rather than an error.

Which SGLang versions carry the fix

Cloudflare says the patch first shipped in SGLang v0.5.20, with follow-ups in v0.5.21 (released 2 October) and v0.5.22 (released 19 October), and it recommends that every operator move to v0.5.22 or later:

• #36988, in v0.5.20, retires aborted prefill requests before their result reaches decode, which stops this exposure;
• #38935, in v0.5.21, rejects such requests at admission, before any allocation or KV transfer;
• v0.5.21 also adds an optional checksum of the transferred cache (--disaggregation-enable-kv-checksum), and further race-condition fixes landed in v0.5.21 and v0.5.22.

The same bug had been reported to SGLang by another user as issue #30233 on 6 July.

What teams running their own inference should check

Workers AI customers have nothing to change. For teams that host open models themselves on SGLang in disaggregated mode, Cloudflare's advice is specific: read the KV pool size from each prefill and decode node's startup log after every change to weights, quantisation, parallelism or memory fraction, and lower the context length if the pool is smaller; do not rely on a proxy or on the engine to refuse what does not fit. Then upgrade, and keep deferred KV release switched on, as it is by default after #41023.

Cloudflare says it now checks pool size against context length before any disaggregated deployment ships, and has applied the engine fix to every model it serves with SGLang. Our catalogue lists Cloudflare among 17 website optimisation tools.

Sources

• Cloudflare Blog: Cross-request KV cache exposure in the GLM-5.3 Workers AI model, and our remediation with SGLang, 26 October 2026