Cloudflare Discloses Cross-Request Data Leak in Hosted GLM-5.3 Model
Cloudflare's October 26 report says a tenant isolation fault in its hosted GLM-5.3 model returned other customers' text in 155 responses, all in replies to prompts above 681,280 tokens. The model was exposed from August 27 to September 9. Cloudflare reports no evidence of deliberate exploitation.
Cloudflare discloses a cross-request leak in a hosted GLM-5.3 model
On October 26, Cloudflare published a post-incident report on a tenant isolation flaw in its Workers AI service. A security researcher, Gadi Evron of Knostic, reported on September 8 that very long prompts sent to the GLM-5.3 model (`@cf/zai-org/glm-5.3`) sometimes returned text from other customers' sessions. Cloudflare says the exposure began when the model launched on August 27, that it took the model offline on September 9 and restored it the same day, and that no other Workers AI model was affected. The report carries an October 26 date because it was coordinated with a post from SGLang, the open-source inference engine involved. The incident itself is about seven weeks older. This October 27 issue covers the disclosure, not a new attack.
Cloudflare gives a count: 155 responses were affected, all to prompts longer than 681,280 tokens. Here a token is a unit of text that the model reads, not a cryptocurrency. After excluding its own tests and the researcher's, Cloudflare says the remaining requests matched ordinary long-context use in timing and volume, and it found no evidence of deliberate exploitation. That is the company's own finding. The post does not report how many customers were affected or what the leaked text contained.
Two faults had to line up
The first fault was a configuration mismatch. Cloudflare deployed the model with a context window of 1,048,576 tokens, but the pool of GPU memory that holds the attention cache (the KV cache) on its prefill GPUs had room for only 681,280 tokens. The company says it knew of the gap before launch and expected the engine to return an error for any prompt that did not fit. Its long-context tests returned successful responses, so the team did not treat the gap as a problem. It now admits that those tests checked HTTP status codes and speed, but not whether the output made sense.
The second fault was a bug in SGLang when it runs prefill and decode on separate GPU pools. A prompt too long for the pool was marked as rejected and swapped for a one-token stand-in, but the request was not stopped. Prefill wrote a single page of cache and told the decode node that the transfer was complete. In Cloudflare's illustrative diagram, the decode node reserves eight pages for the real prompt and assumes all eight are fresh. Seven still hold data from earlier requests, so the model answered while reading other users' leftovers. The client received a normal success reply, not an error. Cloudflare notes that cache pages are not zeroed between requests. Engines commonly accept this for speed, which means the engine itself must track who owns each page.
What Cloudflare changed
The report's timeline runs as follows. The incident was declared on September 9 at 13:22 UTC. The model was set to private at 14:00, the root cause was found at 14:35, and the model returned to public use at 19:40 with a corrected configuration and a patched engine. The prefill pool now holds about 2.04 million tokens, roughly twice the context window, so a valid prompt always fits. Cloudflare also patched the engine so that a rejected request is retired before any cache transfer starts. SGLang shipped related fixes in v0.5.20 through v0.5.22, and Cloudflare urges every operator of disaggregated SGLang to run v0.5.22 or later. It also lists wider hardening: deferred release of cache pages, bounded transfer batches, and a pre-deployment check that compares pool size with context length.
What readers should take from it
For people who buy hosted inference, the lesson is narrow but practical. According to the report, the requests that received leaked text had prompts longer than 681,280 tokens. It does not give the lengths of the other customers' requests whose data was exposed. Still, an isolation fault can sit silent for 13 days with no error, as this one did. Teams that run their own engines should compare cache capacity with the advertised context length, test the content of outputs and not only status codes, and keep a clear channel for outside researchers to report faults. Cloudflare's account is a vendor self-report. The post includes no independent check of its counts, and it does not quantify customer impact.
Sources
FAQ
What happened in Cloudflare's GLM-5.3 incident?
Cloudflare says very long prompts to its hosted GLM-5.3 model could return text from other customers' recent requests. It reports 155 affected responses between the model's August 27 launch and its September 9 repair, all in replies to prompts above 681,280 tokens. No other Workers AI model was affected, according to the company.
What caused the leak?
Two faults combined. The attention-cache pool on the prefill GPUs held 681,280 tokens while the model's context window was 1,048,576, and SGLang mishandled over-length requests in disaggregated mode, so decoding read cache pages left by earlier requests. The client received a normal success reply, not an error.
Does the report prove nobody exploited it?
No. Cloudflare says it found no evidence of deliberate exploitation after excluding its own tests and the researcher's, and that the remaining requests matched ordinary long-context use. That is the company's own finding. The post gives no independent check and no count of affected customers.