- 155 responses from GLM-5.3 on Cloudflare Workers AI carried fragments of other customers’ prompts and outputs between August 27 and September 9, 2026.
- The cause was a cache pool sized at 681,280 tokens for a model advertised with a 1,048,576-token context window, which tripped a bug in the open-source SGLang inference engine.
- Cloudflare says it found no evidence of deliberate exploitation and that no other Workers AI model was affected; operators running SGLang are told to upgrade to v0.5.22 or later.
For 13 days after launch, customers sending very long prompts to the GLM-5.3 model on Cloudflare’s Workers AI could receive answers built partly from strangers’ requests. Cloudflare disclosed on October 26 that 155 responses between August 27 and September 9 contained data from other customers’ sessions, all of them replies to prompts longer than 681,280 tokens, according to the company’s incident report.
A configuration gap and an engine bug combined to leak data
Security researcher Gadi Evron of Knostic reported the problem through Cloudflare’s HackerOne program late on September 8. Cloudflare reproduced it the next day with two independent accounts within 25 minutes, took the model private, and restored it at 19:40 UTC on September 9 with a corrected configuration and a patched engine.
The root cause sits in how the service handles a model’s working memory, the KV cache that stores a prompt’s processed tokens during inference. Cloudflare split GLM-5.3 across separate prefill and decode GPUs. The prefill pool held only 681,280 tokens, and the company knew this before launch but expected oversized prompts to fail with an error. SGLang instead swapped the rejected prompt for a one-token placeholder, sent a single page of cache to the decode node and reported the transfer as complete. The decode node then generated a fluent reply while reading pages that still held earlier users’ data, and returned an HTTP 200 success code.
“Pages are not currently zeroed between requests; the next request that gets a page simply overwrites it.”
Cloudflare, incident report, October 26, 2026
Every company serving open models on shared GPUs inherits this risk
Cloudflare’s own admission is the useful part for buyers. Its pre-launch tests checked status codes and speed at long context lengths and never read the answers for coherence, so a leaking model looked healthy. The SGLang flaw had already been filed publicly as issue #30233 on July 6, and the fixes shipped in SGLang v0.5.20 through v0.5.22, released between September and October 19.
| Date (2026) | Event |
|---|---|
| August 27 | GLM-5.3 launches on Workers AI with the undersized cache pool |
| September 8 | Researcher’s HackerOne report arrives at 23:11 UTC |
| September 9 | Incident declared, model pulled, then restored at 19:40 UTC |
| October 19 | SGLang v0.5.22 ships with the upstream fixes |
| October 26 | Coordinated disclosure by Cloudflare, the researcher and SGLang’s maintainers |
Cloudflare now checks cache pool size against context length on every deployment and is building per-page ownership tags that would fail a request before it reads memory it does not own. Anthropic reported earlier this month that GLM-5.3 itself could assemble cheap exploit chains, whereas this leak came entirely from the serving software wrapped around the model.
Multi-tenant AI hosting rests on a software promise that one customer’s prompt never reaches another, and Cloudflare’s report shows that a single unchecked number in a deployment file was enough to break that promise for two weeks while every monitoring signal reported success.
Santage is committed to independent, transparent journalism. This article is produced in accordance with Santage's Editorial Standards and aims to provide accurate and timely information. Readers are encouraged to verify information independently.