When an AI Answer Contains Someone Else’s Data

The Cloudflare GLM-5.3 KV-cache incident, explained simply

A real cross-customer data exposure occurred inside an AI inference system. The important lesson is not that the model “remembered” strangers. The serving infrastructure accidentally allowed one request to read temporary GPU state left by earlier requests.

1. What happened?

On 26 October 2026, Cloudflare publicly disclosed that a specific deployment of Z.ai’s GLM-5.3 model on Workers AI had allowed some customers to receive text derived from other customers’ recent requests. The exposure had existed from the model’s launch on 27 August until Cloudflare fixed the deployment on 9 September. Public disclosure came later, after remediation and coordination with the researcher and the SGLang maintainers.

Cloudflare identified 155 affected responses. All of them involved extremely long prompts: more than 681,280 tokens. Cloudflare says it found no evidence that anyone had deliberately exploited the problem during the exposure window. It also says no other Workers AI model was affected.

This was a tenant-isolation failure. In a shared cloud service, “tenant isolation” is the wall that should keep one customer’s data separate from another customer’s data. In this incident, that wall failed inside the temporary memory used to serve the model.

2. What is a KV cache?

A large language model generates text one token at a time. Without caching, it would repeatedly recalculate large parts of the same earlier context for every new token. A key-value cache, usually shortened to KV cache, stores intermediate attention information from tokens the model has already processed so the next token can be generated much faster.

A useful analogy is a temporary scratchpad. Your prompt is processed and the system writes a compact computational representation of that context into GPU memory. While the model continues generating, it keeps consulting that scratchpad instead of rebuilding everything from the beginning.

The simplest mental model

Chat memory = information a product may deliberately save for later conversations. Model weights = what the neural network learned during training. RAG / retrieved files = outside information deliberately supplied to the model for a task. KV cache = temporary inference state used while the model is processing and generating a particular request.

The Cloudflare incident involved the last category. It was not evidence that GLM-5.3 had secretly developed durable cross-user memory, and it was not evidence that Z.ai had trained the model on these customers’ private requests.

3. The exact failure: the system thought old pages belonged to the new request

Cloudflare served GLM-5.3 using SGLang in a “disaggregated” setup. One group of GPUs handled prefill — reading and processing the prompt — and another group handled decode — generating the answer. The KV cache had to be transferred from the first group to the second.

The configured model context length was 1,048,576 tokens, but the KV-cache pool on the prefill GPUs could hold only 681,280 tokens. Cloudflare says it knew about that mismatch before launch. The team expected the engine to reject requests that did not fit, and long-context testing returned successful HTTP responses, so the mismatch was not treated as dangerous.

That assumption was wrong. A second bug in SGLang’s rejection path turned the configuration mismatch into a privacy failure. When an over-capacity prompt arrived, SGLang marked it for rejection and replaced the prompt internally with a one-token placeholder. In a single-node deployment that path returned an error. In Cloudflare’s disaggregated setup, however, the rejected request could continue through the handoff.

Cloudflare explains that its GPU memory pool is divided into fixed-size pages. For performance, those pages are not necessarily erased to zero between requests; the next request is expected to overwrite the pages it owns before reading them. That design can be safe if ownership and lifetime bookkeeping are correct. Here, the bookkeeping said the new request owned pages that it had never actually rewritten.

4. How the researcher showed this was a real leak, not a hallucination

The issue was reported by security researcher Gadi Evron of Knostic. The first anomaly appeared during normal work through OpenRouter. After tracing the relevant provider to Cloudflare, the investigation moved to a direct Workers AI account so the behavior could be tested more carefully.

The researcher used very large deterministic prompts containing unique markers at both ends. Below the failure boundary, GLM-5.3 processed the request normally and returned the marker. Above roughly 700,000 tokens, the marker disappeared and latency suddenly collapsed: very large requests sometimes completed much faster than smaller healthy ones. That suggested the system was no longer processing the submitted prompt in the normal way.

Knostic then compared the strange outputs with the test input. The outputs included information that was absent from the prompt, such as filesystem paths, source-code details, project identifiers, personal and company names, invoice numbers, euro amounts, payment dates, and agent-task records.

The strongest evidence came from time. In one case, the returned material corresponded to a public software project created after the model-creation timestamp recorded in Cloudflare’s catalog and correlated with active development within minutes of the affected inference. A catalog creation timestamp is not a verified training cut-off and is not conclusive on its own. Combined with repeatability and Cloudflare’s later internal reproduction using two independent accounts, the evidence supported a live cross-tenant exposure.

5. Why the scope was limited — but still serious

Most AI prompts are far shorter than 681,280 tokens, so ordinary short conversations did not reach the faulty path. However, a short request could still have supplied the earlier cached data exposed by another customer’s long request; the trigger threshold did not protect the owners of that earlier data. That helps explain why Cloudflare identified only 155 affected responses during the exposure period. The number refers to responses, not necessarily the number of individual customers whose data appeared or the number of customers who received leaked material.

The vulnerability also required an authenticated Workers AI account to interact with the affected endpoint. The researcher did not need a victim’s credentials or privileged network access. In principle, a customer could deliberately send sufficiently long prompts and increase the chance of receiving unrelated state, although Cloudflare says its logs did not show a pattern consistent with deliberate exploitation.

The affected model was marketed for long-running agentic coding and tool-driven workflows. That makes the nature of the observed material unsurprising: Knostic reported code, paths and agent-task information among the leaked content. The incident therefore matters not only for chat privacy but for future AI agents that may handle source code, documents, business records and tool output.

6. What Cloudflare and SGLang changed

Cloudflare took GLM-5.3 private on 9 September after reproducing the problem. It increased the prefill KV-cache capacity so every valid prompt within the configured context window could fit. It also patched the rejection path so a rejected request is retired before any bootstrap, memory allocation or KV transfer occurs.

The fixes were validated against the researcher’s reproduction script and Cloudflare’s own canary-marker tests before the model returned to public service that evening. The SGLang project subsequently released fixes across versions 0.5.20, 0.5.21 and 0.5.22 and recommends operators running disaggregated serving use the corrected versions.

Cloudflare also hardened related failure paths: deferred release of KV pages, transfer checks, improved cancellation behavior, corruption detection and deployment checks that compare KV-pool capacity with the advertised context length. The broader SGLang team describes a related family of “distributed use-after-free” problems in which memory is reused while remote writes may still be in flight.

Longer term, Cloudflare wants the system to verify page ownership when the model reads the cache, rather than relying only on correct bookkeeping. It has also said it intends to apply formal verification methods to parts of the distributed KV-transfer protocol. The goal is to make entire classes of cross-request memory errors harder or mathematically impossible, not merely patch the exact path discovered this time.

7. One uncomfortable detail: the warning signs existed

Cloudflare’s own disclosure is unusually candid about two preventable weaknesses. First, it knew before launch that the KV-cache pool was smaller than the configured context window but assumed requests would fail safely. Second, its long-context testing emphasized HTTP success codes and performance rather than checking whether the model’s output was coherent and actually derived from the submitted prompt.

A related SGLang bug had also been reported publicly on GitHub on 6 July 2026. That report described over-long requests reaching decode with incomplete KV state and producing garbage output. Cloudflare says it noticed that report while investigating the September incident. The existence of the earlier report does not prove Cloudflare knew this exact privacy exposure would occur, but it shows that the failure mode had been visible in the ecosystem before the affected deployment launched.

8. What this incident does — and does not — mean

9. The bigger lesson for AI agents

As AI systems become longer-lived, tool-using and more agentic, people naturally focus on prompt injection, model behavior and permissions. This incident shows that another layer deserves equal attention: the inference machinery underneath the agent.

An agent can have perfect instructions and still be unsafe if the serving layer mixes temporary state between users. Security therefore has to exist at several levels at once: account permissions, tool permissions, retrieved content, model behavior, runtime isolation, memory ownership, network transfer and logging. “The model followed the rules” is not enough if the infrastructure hands it the wrong data.

10. Bottom line

The Cloudflare GLM-5.3 incident was a real privacy failure caused by the interaction of a known configuration mismatch and an inference-engine bug. Extremely long requests could reach a decoder that believed its temporary memory pages belonged to the new request even though most of those pages still held state from earlier customers. The result was coherent text containing other users’ information.

The model did not “remember” strangers in the human or product-memory sense. The infrastructure accidentally handed the model stale computational state. That distinction is technically important, but it does not make the incident trivial: for the affected customers, private information crossed a boundary that should have been absolute.

The encouraging part is that the disclosure led to fixes not only for this exact bug but for a broader class of KV-cache lifetime and transfer problems. The lasting lesson is simple: as AI systems become more capable, AI safety is increasingly also ordinary systems engineering — memory ownership, isolation, validation and failure handling.

Sources and verification

1. Cloudflare — “Cross-request KV cache exposure in the GLM-5.3 Workers AI model, and our remediation with SGLang” (26 Oct 2026) https://blog.cloudflare.com/kv-cache-exposure-remediation/

2. Knostic — “Hallucination or Cross-Tenant: When an LLM Answers With Another User’s Context” (27 Oct 2026) https://www.knostic.ai/blog/hallucination-or-cross-tenant-when-an-llm-answers-with-another-users-context

3. SGLang / LMSYS — “SGLang security update: improving request isolation” (26 Oct 2026) https://www.lmsys.org/blog/2026-10-26-cf-security

4. SGLang GitHub issue #30233 — over-long rejected requests reaching decode with incomplete KV cache (opened 6 Jul 2026) https://github.com/sgl-project/sglang/issues/30233

5. Cloudflare Workers AI — GLM-5.3 model documentation https://developers.cloudflare.com/workers-ai/models/glm-5.3/

6. Hugging Face Transformers — “How caching works” (KV-cache background) https://huggingface.co/docs/transformers/cache_explanation

Prepared for BunCosmos Research Lab • Current through 27 October 2026 • Claims are separated from inference and speculation wherever possible.