BMShop Products
← All articles
Cloudflare discloses KV cache leak in its GLM 5.3 model
AI News

Cloudflare discloses KV cache leak in its GLM 5.3 model

Cloudflare admits 155 responses from GLM 5.3 on Workers AI contained data from other customers' requests between August 27 and September 9, 2026.

Ammar Rahimi · 27 October 2026 · 4 min read

Cloudflare published an incident report on October 26, 2026 about a security flaw in its GLM 5.3 model on Workers AI. Between August 27 and September 9, 2026, 155 responses from that model contained data from other customers' requests made shortly before theirs. The model was fixed on September 9, but the full write-up only went public now, alongside the SGLang team.

1. What happened

GLM 5.3 is a text generation model from Z.ai built for agentic coding workflows. It is offered through Workers AI, the platform that lets developers run AI models on Cloudflare's infrastructure.

On September 8, 2026, security researcher Gadi Evron of Knostic reported through Cloudflare's HackerOne program that very long prompts sometimes returned text belonging to other users' sessions. Cloudflare confirmed the report and took the model offline on September 9, then restored it the same day after fixing the configuration.

2. First cause: a misconfiguration

GLM 5.3 ships with a context window of 1,048,576 tokens. But the KV cache pool on Cloudflare's prefill GPUs only had room for 681,280 tokens. Cloudflare admits it knew about this mismatch before launch.

The company assumed the inference engine would return an error for any prompt that could not be processed. Pre-launch testing only checked HTTP response codes and performance, not output coherence. So long prompts passed the tests even though the engine could not actually handle them.

3. Second cause: an SGLang bug

Cloudflare runs GLM 5.3 with the open-source SGLang engine in disaggregated mode: prefill GPUs produce the KV cache and hand it to decode GPUs that generate the response.

When a prompt exceeded the pool size, SGLang internally rejected it and swapped in a one-token placeholder. In disaggregated mode, the admission queues checked whether a request was finished, not whether it was rejected. So the rejected request kept flowing: prefill transferred a single cache page, but the decode node assumed the full cache had been written. It then generated a response while reading stale cache pages that still held earlier users' data.

The result: customers received a normal-looking HTTP 200 response containing fragments of someone else's session. All 155 affected responses came from prompts longer than 681,280 tokens.

4. No evidence of deliberate exploitation

Cloudflare says it found no evidence of repeated exploitation. After excluding its own testing and the researcher's requests, the request patterns it identified were consistent with ordinary long-context use.

The company also confirmed no other model on Workers AI was affected. Every other disaggregated deployment has a KV pool larger than its context length, so valid prompts never reach the rejection path.

5. How it was fixed

Two changes were made. First, the configuration was adjusted so the prefill KV pool now holds about 2.04 million tokens, roughly twice the model's context length. Second, the SGLang engine was patched so a request carrying a pending rejection is retired at the admission queue before any cache transfer happens.

Both fixes were proposed upstream to the SGLang project. The SGLang team shipped fixes in v0.5.21 and v0.5.22 (October 19), and Cloudflare advises all SGLang operators to upgrade to v0.5.22 or later. SGLang's report says the performance cost of the protections stayed within roughly two percent.

What it means for you

This case shows that security risk can sit in the infrastructure layer, not in the model itself. API keys and quotas worked as intended, yet shared GPU memory still leaked. If you use hosted AI services, the serving layer needs review too.

  1. Long context carries higher risk. Only prompts beyond 681,280 tokens triggered the bug, and the leaked output looked coherent.
  2. Response codes are not proof of safety. An HTTP 200 can hide internal failure. Testing should check output quality too.
  3. Favor operators that disclose incidents. Cloudflare published a full report and a fix within a day. That is the standard to expect from any AI provider.
  4. Running your own engine? Update now. If you run SGLang in disaggregated mode, upgrade to v0.5.22 and make sure your KV pool size exceeds your model's context length.
  5. Impact on ordinary users was small. 155 affected responses over 13 days, with no evidence of deliberate exploitation. Still, it is a reminder that data isolation must be tested at every layer.

Sources