A KV cache exposure happens when an LLM serving engine generates a response while reading GPU memory that still holds another request's data, so fragments of someone else's prompt or output end up in your answer. On October 26, 2026, Cloudflare disclosed exactly that for its Workers AI GLM-5.3 model (@cf/zai-org/glm-5.3): between August 27 and September 9, 2026, 155 responses contained data from other customers' requests. This guide, current as of October 2026, sticks to what Cloudflare and the SGLang maintainers have published and turns it into a practical checklist for developers who call hosted AI APIs.

What happened in the Cloudflare GLM-5.3 KV cache exposure

Security researcher Gadi Evron of Knostic reported through Cloudflare's HackerOne program on September 8, 2026 that very long prompts sent to GLM-5.3 sometimes returned text from other users' sessions. Cloudflare reproduced the leak with two independent accounts the next day, set the model to private within about 40 minutes of declaring an incident, and restored it the same evening after fixing both the configuration and the inference engine.

Cloudflare counts 155 affected responses, all to prompts longer than 681,280 tokens. After excluding its own and the researcher's tests, the matching requests looked like ordinary long-context use in timing and volume, and Cloudflare says it found no evidence of deliberate exploitation. No other Workers AI model was affected. While it was happening, the public status page described it only as increased GLM 5.3 errors, from 14:25 to 20:09 UTC on September 9.

What is a KV cache, and why could data cross between users?

When a transformer model generates text, it stores the key and value vectors for every token it has already processed so it does not recompute them for each new token. That store is the KV cache. On Workers AI, Cloudflare explains, the cache lives in a shared pool of fixed-size GPU pages. Each request gets pages when admitted and hands them back when finished. Pages are not zeroed between requests for performance reasons; the next owner simply overwrites them. Tenant isolation therefore depends entirely on the engine tracking who owns which page.

Two problems lined up

1. A configuration mismatch. GLM-5.3 was deployed with a 1,048,576-token context window, but the KV pool on the prefill GPUs only fit 681,280 tokens. Cloudflare knew about the gap before launch, expected the engine to reject anything that did not fit, and its long-context tests checked HTTP status codes rather than output quality.
2. An SGLang bug in disaggregated mode. Workers AI splits prompt processing (prefill) and token generation (decode) across separate GPU pools. An over-length request was marked as rejected and swapped for a one-token placeholder, but the admission queues only checked whether a request had finished, not whether it had been rejected, so it kept moving.
3. The result. The decode node reserved pages for the full long prompt, yet only the first page was freshly written. The rest still held earlier users' prompts and partial generations. The model attended over them and the client got HTTP 200 with a fluent reply instead of HTTP 400.

The uncomfortable detail is that nothing errored. The reported prompt_tokens matched the long prompt and the text read naturally. The only tell Cloudflare mentions is that the reply arrived faster than a prompt that size should allow. Monitoring that watches status codes alone would not have caught it.

How to check whether your app was affected

Cloudflare's post does not include a customer action list, so your own logs are the practical way to narrow things down.

1. 1

   Confirm model and dates

   Search application logs or AI Gateway records for calls to @cf/zai-org/glm-5.3 between August 27 and September 9, 2026 (UTC). If you never called that model, this incident did not touch your traffic directly.

2. 2

   Filter for very long prompts

   Within that window, pull requests whose prompt_tokens exceeded 681,280. Per Cloudflare, every response that received foreign data falls in this group.

3. 3

   Review stored outputs

   If you kept those responses, look for names, code, or documents unrelated to your input. Treat anything that looks like another party's data as such: quarantine it and do not feed it into other systems or training sets.

4. 4

   Assess whether you were a source

   Leaked fragments came from requests made shortly before. If you sent API keys, passwords, or personal data to GLM-5.3 in that window, rotating those credentials and asking your privacy or legal team whether any notification duty applies is the cautious path.

5. 5

   Ask through official channels

   For account-level confirmation, contact Cloudflare support. Report new security findings through Cloudflare's HackerOne program, as the disclosure requests.

AI inference security habits worth adopting now

The incident shows that a provider promise not to store prompts does not cover every risk: isolation can fail while data sits in memory during processing. Cloudflare's Workers AI data usage page (updated October 16, 2026) says standard stateless inference inputs and outputs are not retained or used for training, but that content is stored if you turn on AI Gateway logging or caching or write prompts to your own logs.

Security incidents like this spread fast through developer channels. To see how AI-focused Telegram channels are discussing it, check the AI Telegram trends page, and use the blog trends dashboard to track write-ups from engineering blogs.

页面引用

趋势theddari.com›趋势博客仪表盘Naver 博客活跃度排行

If you self-host SGLang: the official recommendations

SGLang is the open-source inference engine Cloudflare uses. The SGLang team's write-up notes the bug only appeared in disaggregated prefill/decode serving; single-node deployments returned an error as intended. The same post covers a separate race-condition family in which late RDMA writes from an aborted request could land in another request's KV cache.

• Upgrade. Cloudflare strongly recommends that all operators depending on SGLang move to v0.5.22 or later. The incident fixes are #36988 (v0.5.20) and #38935 (v0.5.21).
• Compare KV pool to context length. After any change to weights, quantization, parallelism, or memory fraction, read the pool size from each prefill and decode node's startup log. If it is smaller, lower the context length. Do not rely on a proxy to enforce the limit.
• Enable deferred KV release on both roles and cap Mooncake transfer batch sizes.
• Turn on corruption detection with --disaggregation-enable-kv-checksum and the KV canary where your model supports them, and confirm in logs that requests are actually verified.
• Test outputs, not just status codes. Cloudflare called validating only response codes and performance the critical gap in its testing.

What the disclosure does and does not tell you

Confirmed: one model (GLM-5.3), one window (August 27 to September 9, 2026), 155 responses, a trigger condition of prompts over 681,280 tokens, no evidence of deliberate exploitation, and the fixes. After remediation, the prefill KV pool holds about 2.04 million tokens, roughly twice the context window.

Not disclosed: what kind of data leaked, whether it included personal data, and which customers' requests were the source. That makes both "my data is definitely safe" and "massive breach" unsupported claims. Multi-tenant GPU serving keeps costs down, but its isolation is only as good as the engine's bookkeeping. For sensitive workloads, the controls you own, such as minimal prompts, output checks, and lean logs, are the most reliable place to start.