# Cloudflare discloses GLM-5.3 cache exposure affecting 155 responses > Cloudflare’s October 26 report traces cross-customer data exposure to a cache-capacity mismatch and a SGLang rejection bug. Service was restored September 9. Canonical URL: https://www.devobs.io/news/news-event-0d5f71133d55d9853df76c94/ By: Elias Brooks Published: 2026-10-27T06:53:33.402Z Updated: 2026-10-27T06:53:33.402Z Event date: 2026-10-26 Section: Security ## Disclosure and exposure scope Cloudflare disclosed on October 26, 2026, that 155 responses from its GLM-5.3 Workers AI model contained data from other customers’ recent requests to the same model. According to the company’s incident report, the exposure occurred between August 27 and September 9, and all affected responses followed prompts longer than 681,280 tokens. The affected model was `@cf/zai-org/glm-5.3`. Cloudflare says no other Workers AI model was affected and that it found no evidence of deliberate exploitation. The October disclosure followed remediation in September. Cloudflare’s timeline records deployment of the corrected configuration and patched engine at 19:04 UTC on September 9, followed by restoration of public access at 19:40 UTC. ([Cloudflare incident report and timeline](https://blog.cloudflare.com/kv-cache-exposure-remediation/)) ## How rejected prompts reached stale cache pages Cloudflare traces the exposure to two overlapping failures. Its deployment had a configured context window of 1,048,576 tokens, but the key-value (KV) cache pool on its prefill GPUs could hold only 681,280 tokens. The company says it knew about the mismatch before launch but expected the inference engine to return an error for prompts it could not process. Instead, SGLang’s rejection path failed in the deployment’s disaggregated prefill/decode mode. In this setup, prefill nodes process prompts and transfer their KV cache to decode nodes, which generate responses. The engine marked an oversized prompt as rejected and substituted a one-token placeholder, but the request continued through the handoff. Prefill transferred the placeholder’s cache and signaled completion. Decode treated that signal as confirmation that the full prompt’s cache had arrived, even though most of the reserved pages had not been overwritten. According to Cloudflare, generation then attended to stale pages containing other users’ prompts and partial generations, returning HTTP 200 rather than the intended HTTP 400 error. ([Failure mechanism](https://blog.cloudflare.com/kv-cache-exposure-remediation/)) ## Two fixes: capacity and rejection handling Cloudflare says it enlarged the prefill KV pool to approximately 2.04 million tokens, enough to accommodate the configured context window. It also patched the engine to terminate requests carrying a pending rejection and return their original error before bootstrap, allocation or KV transfer. The two changes address different problems. Increasing capacity removes the configuration mismatch that triggered this incident. Correct rejection handling prevents a rejected request from continuing into the cache handoff. As Cloudflare explains, pool capacity can change with deployment settings, and other rejection conditions could reach the same faulty path. ([Immediate remediation](https://blog.cloudflare.com/kv-cache-exposure-remediation/)) ## Upstream fixes and operator guidance Cloudflare’s report distinguishes two upstream fixes: - **SGLang v0.5.20:** retires aborted prefill requests before their results reach decode. Cloudflare says this stops the exposure described in the incident. - **SGLang v0.5.21:** rejects those requests earlier, at admission, before bootstrap, allocation or KV transfer. The report recommends that operators running disaggregated SGLang update to **v0.5.22 or later**, or backport the relevant patches. It also recommends measuring the KV pool against the configured context length on every prefill and decode node after changes to weights, quantization, parallelism or memory fraction. If the pool is smaller, operators should lower the context length to fit. Cloudflare says it has also deployed additional hardening across its disaggregated production deployments. ([Upstream fixes and operator recommendations](https://blog.cloudflare.com/kv-cache-exposure-remediation/)) ## Successful responses are not isolation checks Cloudflare says its prelaunch long-context tests checked HTTP response codes and engine performance without validating model output and coherence. It now checks the running engine’s KV-pool capacity against the configured context length before disaggregated deployment changes ship. ([Testing changes](https://blog.cloudflare.com/kv-cache-exposure-remediation/)) For engineering teams, the incident suggests three distinct checks: verify live cache capacity, confirm that rejected requests terminate with the intended error, and test cross-request isolation. Cloudflare’s failure walkthrough describes a coherent response that nevertheless contained other users’ data. Neither transport success nor plausible output establishes tenant isolation. ([Response behavior](https://blog.cloudflare.com/kv-cache-exposure-remediation/)) A larger pool addresses this capacity mismatch, but it is not a substitute for correct rejection handling. ## Source references -