Cloudflare Workers AI Leaked Other Customers' Data Into 155 Responses Over Two Weeks. The Bug Only Fired on Prompts Above 681,280 Tokens.
On October 26, Cloudflare published a post-mortem saying that its Workers AI hosting of the GLM-5.3 model returned responses containing other customers' request data. Cloudflare counts 155 affected responses between August 27 and September 9, and every one of them came from a prompt longer than 681,280 tokens. The number is small and the cause is mundane, which is exactly why it is worth reading if you build on a shared inference API.
What happened, in order
GLM-5.3 launched on Workers AI on August 27. On September 8, security researcher Gadi Evron of Knostic reported the problem through Cloudflare's HackerOne program. Cloudflare declared an incident on September 9, reproduced the leak, and set the model to private so requests returned HTTP 400. The model went back to public the same day after fixes. Cloudflare says no other Workers AI model was affected, and that its analysis of timing and volume points to ordinary long-context use rather than deliberate exploitation. It reports no evidence that anyone exploited the bug on purpose.
The public post-mortem is dated October 26, about seven weeks after the fix, so if you wondered why nobody told you in September, that is why.
Two bugs that had to line up
The first was a configuration mismatch. The model advertised a context window of 1,048,576 tokens, but the cache pool used during the prefill stage held only 681,280 tokens. Pre-launch tests returned successful HTTP responses, so nobody saw the gap.
The second was a bug in SGLang, the serving engine. In a mode that splits prefill and decode across machines, an over-length request was marked as rejected but still ran with a one-token placeholder. The decode side then read memory pages left over from earlier requests, and those pages could hold another customer's data. Cloudflare says a similar issue had been reported upstream on July 6.
Either bug alone would have been quiet. A correctly sized pool never receives an over-length request, and a correct engine would have refused it cleanly. Together they produced a leak that only appeared at extreme prompt sizes, which is why a normal test suite missed it.
What Cloudflare changed
The cache pool was raised to about 2.04 million tokens, roughly twice the context length. The engine was patched so rejected requests are retired at admission with their original error, before any cache transfer. Related upstream changes landed in SGLang v0.5.20 through v0.5.22. Cloudflare also added a pre-deployment check that compares cache pool size to context length, deferred page release, and is working on per-page integrity tags.
If you run your own disaggregated SGLang, the guidance in the post is to measure pool size against context length on every node and upgrade to v0.5.22 or later.
What a solo builder can actually do
You cannot audit a vendor's serving stack, so the control you have is what you send. Cloudflare's post lists no customer actions such as key rotation, which I read as: nothing you could have done afterward would have helped. The lever is before.
I would sort my prompts into two buckets. Anything with secrets, customer personal data, or credentials in it goes to a provider and plan where I have a contractual no-retention and isolation commitment, and I would keep those prompts short. Everything else can go to cheap shared endpoints. This incident needed prompts over 681,280 tokens to trigger, so a product that sends 4,000-token requests was never in the blast radius, but I would not build a policy on that detail alone, since the next bug will have a different threshold.
Separately, strip secrets from context before you send it. If your agent pastes an environment file into a prompt "so the model has context", a leak like this turns a bad day into a rotation of every key you own.
Where this could be wrong
One incident, 155 responses, found and fixed in about two weeks, with a public post-mortem that names its own root causes, is close to a good outcome for this kind of failure. I would weigh that in Cloudflare's favor. The counter-point is that I only know what Cloudflare chose to publish, and the sample is whatever their analysis found.
What I would actually do
Check what your largest real prompt is, and write down which provider receives it. If any request path can grow past a few hundred thousand tokens (a "summarize this whole repository" feature, say), cap it and split it. And take the pattern with you: when a vendor advertises a limit, ask what happens past it. The answer should be a clean error, and this week showed what it looks like when it is not.
Author
Lukas
@lukcombinator