Cloudflare said on Monday that a configuration error and a bug in its inference engine caused the GLM-5.3 model on Workers AI to return data from other customers' requests in 155 responses between August 27 and September 9, 2026. Cloudflare said no other Workers AI model was affected and that it found no evidence of deliberate exploitation; the affected requests matched the timing and volume of ordinary long-context use.
The exposure only hit very long prompts. Every affected request exceeded 681,280 tokens, the size of the prefill KV cache pool Cloudflare provisioned for GLM-5.3, a model from Z.ai, even though the model was deployed with a 1,048,576-token context window. Cloudflare said "a small number of customers" were involved and did not give an exact count.
In a blog post by Kevin Flansburg and Michelle Chen, Cloudflare said it knew about the mismatch before launch. Its pre-launch tests checked HTTP status codes and engine performance at long context lengths, not the quality of the output, which the company called a critical gap in its testing.
Key facts
- 01Cloudflare says 155 GLM-5.3 responses on Workers AI contained data from other customers' requests between Aug 27 and Sep 9, 2026.
- 02Every affected prompt was longer than 681,280 tokens, the size of the prefill KV pool, while the model allowed 1,048,576 tokens.
- 03An SGLang bug let rejected over-length requests proceed and read stale KV pages, returning HTTP 200 instead of an error.
- 04Knostic CEO Gadi Evron reported the issue via HackerOne on Sep 8; Cloudflare restored the patched model at 19:40 UTC on Sep 9.
- 05Cloudflare recommends SGLang operators upgrade to v0.5.22 or later, released Oct 19.
The second cause sat in SGLang, the open-source serving engine Cloudflare uses. In disaggregated prefill and decode mode, requests that were too long were marked as rejected and swapped for a one-token placeholder, but the admission queues checked whether a request had finished rather than whether it had been rejected. The request moved forward, prefill sent a single KV page to the decode stage, and decode read across eight reserved pages, most of which still held data from earlier requests. The client received an HTTP 200 instead of an error.
That SGLang bug was not new. Cloudflare said the same behavior had been reported upstream as SGLang issue #30233 on July 6, 2026, weeks before GLM-5.3 launched on Workers AI.
Gadi Evron, CEO of security firm Knostic, reported the problem through Cloudflare's HackerOne program on September 8. In Knostic's own write-up, Evron said he noticed it during unrelated work through OpenRouter, when responses contained file paths from another machine and Chinese-language tutorials. Knostic's black-box tests found that requests up to 662,162 tokens returned a planted marker correctly, while requests from about 700,000 tokens upward did not. One 812,377-token request returned unrelated output and was billed in full.
Knostic said the leaked responses included personal and company names, invoice numbers, euro amounts, payment dates, source-code details, filesystem paths and agent task records. Per Knostic, reproducing it required only an ordinary paid Workers AI account and the requester's own API token.
Cloudflare declared a security incident at 13:22 UTC on September 9, and its Product Security team reproduced the leak within 25 minutes. The model was set to private at 14:00, returning HTTP 400 errors, and the root cause was identified at 14:35. After a full rebuild with a corrected configuration and an engine patch, GLM-5.3 returned to public access at 19:40 UTC.
The fix has two parts. Cloudflare enlarged the prefill KV pool to about 2.04 million tokens, roughly twice the context length, matching its GLM 5.2 configuration. It also changed SGLang so rejected requests are retired at the admission queue with their original error before any allocation or KV transfer, a patch proposed upstream as SGLang #38704. Further hardening includes deferred KV page release, bounded Mooncake transfer batches, a load balancer change so client disconnects no longer abort requests mid-transfer, and a deployment check that compares KV pool size to context length.
Cloudflare met SGLang maintainers at RadixArk on September 10, and SGLang shipped v0.5.21 on October 2 and v0.5.22 on October 19. Cloudflare recommends that operators running SGLang upgrade to v0.5.22 or later.
Cloudflare also prototyped per-page integrity tags that detect when a request reads KV pages it does not own. The prototype cost under 1% in throughput but was disabled after reliability problems, and Cloudflare said it plans to apply formal verification to its RDMA-based KV cache transfer protocol.
Working on something we should cover, or seeing a story we missed? Send leads, documents, or feedback to hello@aichatdaily.com. For sensitive tips, see our secure tips page for Signal and PGP options.
Spotted an error? Email hello@aichatdaily.com with the URL and the issue, or read our full corrections policy.
