A shared inference cache leaked other customers’ prompts and partial answers. In a October 26, 2026 post, Cloudflare said that between August 27 and September 9, “a small number of customers using the GLM 5.3 Workers AI model received responses that contained data from other customers’ requests made to the same model shortly before theirs.” In total, “155 responses were affected, all to prompts longer than 681,280 tokens.” Researcher Gadi Evron of Knostic reported the issue through HackerOne on September 8. Cloudflare says it has “confirmed that no other model hosted on Workers AI was affected,” and that it found “no evidence of deliberate exploitation.”
Quick Take
- What leaked: Other tenants’ recent prompts and partial generations, in 155 GLM-5.3 responses on Workers AI (
@cf/zai-org/glm-5.3). - Who was hit: Only requests longer than 681,280 tokens. After excluding Cloudflare’s tests and the researcher’s, Cloudflare says the remaining traffic looked like ordinary long-context use.
- Root cause: Two stacked failures. Cloudflare deployed GLM-5.3 with a 1,048,576-token context window but a prefill KV-cache pool of only 681,280 tokens, and an SGLang bug in disaggregated prefill/decode mode then served stale cache pages instead of returning an error.
- Response: Incident declared September 9; model taken private within about 40 minutes of confirmation; restored the same day at 19:40 UTC after a larger KV pool and an engine patch. Cloudflare recommends other SGLang operators upgrade to v0.5.22 or later.
What happened
Workers AI runs GLM-5.3, a Z.ai model aimed at long agentic coding prompts, on SGLang in a disaggregated setup: prefill GPUs build the model’s KV cache, then hand it to decode GPUs that generate the answer. KV pages live in a shared pool and are not zeroed between requests; the engine is supposed to track who owns which page.
Cloudflare knew, before launch, that the prefill pool was smaller than the advertised context window. It expected over-long prompts to fail. Instead, tests returned HTTP 200. In production, when a prompt did not fit the pool, SGLang marked the request as rejected and swapped in a one-token placeholder, but in disaggregated mode the decode node still reserved pages for the original long prompt, received only a tiny transfer, and then attended over leftover cache from earlier requests. The client saw a normal-looking 200 response that could contain another tenant’s data.
Evron’s report arrived at 23:11 UTC on September 8. Cloudflare began verifying at 08:00 UTC on September 9, declared an incident at 13:22, set the model private at 14:00, and restored it at 19:40 after enlarging the pool to about 2.04 million tokens and patching the rejection path. It later worked with SGLang’s maintainers at RadixArk on upstream fixes, including retiring rejected requests before any KV transfer.
What it means
This is a tenant-isolation failure in a hosted model API, which is as serious as it sounds, even with a modest count of 155 responses and no evidence of targeted abuse. The uncomfortable detail is that Cloudflare knew the pool and the context window disagreed, and trusted HTTP status codes instead of checking the engine’s actual cache math. Its own advice to other operators is the right checklist: measure KV pool against context length on every node after every config change, upgrade SGLang, and do not assume the engine will fail closed.
Customers who sent GLM-5.3 prompts longer than 681,280 tokens between August 27 and September 9 should assume some of that text could have appeared in another tenant’s response, and that they could have received someone else’s. Cloudflare’s post does not describe a customer notification with those exact 155 request IDs in the public text; affected firms should ask Cloudflare directly if they need confirmation.
About the analysis
Researched and written with AI assistance under the editorial responsibility of the i10X News team. The title image is an AI-generated illustration. Read our AI Use Policy. Spotted an error? Request a correction.
This i10x report is based on Cloudflare’s October 26, 2026 engineering post, including the timeline, counts, and SGLang technical detail published there. i10x did not reproduce the leak.
