# Cloudflare's GLM-5.3 on Workers AI leaked data between requests

published: 2026-10-27T09:05:47.962Z
topic: infrastructure
breaking: true
source: https://blog.cloudflare.com/kv-cache-exposure-remediation/
url: https://aiagentnews.io/stories/cloudflare-s-glm-5-3-on-workers-ai-leaked-data-between-requests

Cloudflare says responses from the GLM-5.3 model on Workers AI contained data from other customers' requests between August 27 and September 9, 2026, with 155 responses affected, all to prompts longer than 681,280 tokens. The cause was a prefill KV pool smaller than the context window, combined with an SGLang bug that let over-length requests reach the decode node, and both have been fixed.

Cloudflare states that a small number of customers received responses containing data from other customers' requests made to the same model shortly before theirs. In total 155 responses were affected, all to prompts longer than 681,280 tokens. The company says the affected requests look like ordinary long-context use, and it found no evidence of deliberate exploitation.

The incident had two causes. The GLM 5.3 deployment had a prefill KV pool of 681,280 tokens against a 1,048,576-token context window. In SGLang's disaggregated mode, an over-length request was marked as rejected, replaced with a one-token placeholder and still handed to the decode node, which attended over stale cache pages from earlier requests.

Cloudflare disabled the model, enlarged the pool to about 2.04 million tokens, and patched SGLang so rejected requests return an error before any KV transfer. The fixes are in SGLang v0.5.20 through v0.5.22, and Cloudflare recommends that operators running disaggregated SGLang update to v0.5.22 or later. The model was restored to public access on September 9, and Cloudflare says no other Workers AI model was affected.

## Why it matters if you build agents

Anyone running SGLang in disaggregated prefill/decode mode should confirm that the KV pool covers the configured context length and upgrade to v0.5.22 or later. The bug only triggered on prompts longer than the pool, and affected requests returned HTTP 200 instead of an error, so a successful response does not prove the output is clean.
