For thirteen days between August 27 and September 9, 2026, some long prompts sent to Cloudflare's GLM-5.3 model on Workers AI came back with pieces of a different customer's conversation mixed in. Cloudflare disclosed the full root cause on October 26, 2026. The detail that stands out is how ordinary the mistake was: a cache sized smaller than the context window it was supposed to serve, paired with a bug in how a rejected request was still allowed to signal "transfer complete."
Jump to what we checked in our own context-window testing if your team only load-tests an inference endpoint for status codes and latency.
Cloudflare advertised a 1,048,576-token context window for GLM-5.3 on Workers AI. The prefill KV-cache pool backing it, the memory that holds a request's attention state while the model works through it, was sized for 681,280 tokens, well short of what the advertised window implied for the longest prompts customers could legitimately send.
Cloudflare's own incident report says pre-launch testing checked HTTP status codes and that responses streamed correctly. It did not check whether the content of those responses was actually coherent for prompts that pushed past the real pool size. A request could get a 200 and a stream of tokens that looked like a normal completion while quietly attending over cache pages that belonged to someone else's earlier request.
The second half of the bug lived in SGLang, the inference engine used in a disaggregated prefill/decode configuration, where one set of machines builds the KV cache and a separate set generates tokens from it. When a request exceeded the real pool size, SGLang was supposed to reject it outright. Instead, it replaced the oversized request with a one-token placeholder, but still sent the decode node a "transfer complete" signal as if the full KV cache had been written.
The decode node, trusting that signal, generated a response by attending over whatever stale cache pages happened to occupy that pool slot, which could belong to an entirely different customer's earlier request, according to the technical breakdown published by the SGLang maintainers.
Across the thirteen-day window, this produced 155 affected responses, every one of them tied to prompts longer than 681,280 tokens, the actual ceiling of the undersized pool rather than the advertised context length.
Security researcher Gadi Evron, working with Knostic, reported the issue through HackerOne on September 8, 2026, after noticing a response that referenced context no legitimate user in that session could have provided. Cloudflare reproduced the behavior in 25 minutes and took the model offline about 40 minutes after confirming it.
A fix, expanding the pool to roughly 2.04 million tokens and patching the SGLang transfer-signal bug, shipped the same day the incident was declared internally. The upstream SGLang fixes landed as pull requests #36988 and #38935, reaching general release in v0.5.20 and v0.5.21, with the complete fix folded into v0.5.22 on October 19, 2026.
No evidence of deliberate exploitation turned up, and Cloudflare says no other Workers AI model shared the same pool-sizing mismatch. The company also issued a public correction on the exact enforced context window, having first stated it as 1,310,720 tokens before settling on the documented 1,048,576.
We pulled our own load-test scripts for any service we run with a documented maximum input size and checked what they actually assert on the response. Every one of them checked status code and response time. None of them checked whether a response at or near the advertised maximum made semantic sense relative to what was sent in, which is exactly the gap in Cloudflare's own pre-launch testing.
We added a check that sends two distinct long-context prompts back to back near the documented ceiling and confirms the second response doesn't reference content unique to the first. It's cheap to run, and it would have caught this specific failure mode.
The honest limitation here is that Cloudflare's report covers the 155 responses it could identify from logs; it does not establish whether every affected customer has been individually notified, and the correction Cloudflare issued on its own advertised context window after initial disclosure suggests the full technical picture took more than one pass to get exactly right. We also don't know whether other providers running SGLang in a similar disaggregated configuration have checked for the same transfer-signal bug.
We flagged the same category of problem in the Cloudflare outage that never triggered a single uptime alert: a monitoring setup that validates the easy, structural signals, status codes, connectivity, streaming, while missing the one check that would have actually caught the failure, whether the output itself was correct.
The verdict: Cloudflare's pre-launch testing confirmed GLM-5.3 responded correctly in shape, status code, streaming, latency, without ever confirming it responded correctly in substance, and that gap is what let a 367,000-token shortfall between the advertised context window and the real cache pool go undetected until an outside researcher found it by reading a response too closely.
The rule: any test suite for a service with a documented maximum input size needs at least one check that inspects response content near that maximum, not just the status code and the stream, because a cache that silently serves someone else's data still returns a 200.
What was the Cloudflare KV cache exposure?
Between August 27 and September 9, 2026, a sizing mismatch between the advertised context window and the actual KV-cache pool for GLM-5.3 on Workers AI, combined with an SGLang bug, caused 155 responses to include content from other customers' earlier requests.
What caused the KV cache exposure?
The prefill KV-cache pool was sized for 681,280 tokens while the advertised context window was 1,048,576 tokens. SGLang, the inference engine, was supposed to reject oversized requests but instead sent a false "transfer complete" signal, letting the decode node generate a response from stale cache pages belonging to a different request.
Who found the Cloudflare KV cache exposure?
Security researcher Gadi Evron, working with Knostic, reported it through HackerOne on September 8, 2026. Cloudflare reproduced the issue in 25 minutes and took the affected model offline roughly 40 minutes after confirming it.
Is the Cloudflare KV cache exposure fixed?
Yes. Cloudflare expanded the cache pool to roughly 2.04 million tokens and patched the SGLang transfer-signal bug the same day the incident was declared. The upstream SGLang fixes shipped in v0.5.20 and v0.5.21, with the complete fix included in v0.5.22 on October 19, 2026.
I'm Rohit, founder of Krova Cloud: disposable, per-minute-billed VMs where every workload gets its own isolated memory from boot, so a sizing mismatch in one tenant's job can't leave stale state for the next one to read. More debugging stories at debugly.dev.