The Cloudflare Workers AI leak affected 155 responses from the GLM-5.3 model between August 27 and September 9, 2026, and each one contained data from other customers’ requests. Cloudflare disclosed it in a post-mortem on October 26. The cause was a configuration mismatch that set off a bug in SGLang, the open-source engine that serves the model.
The Cloudflare Workers AI leak matters to anyone who sends member data, donor notes or draft content to a hosted AI API. This post covers what Cloudflare says happened, what a KV cache is in plain words, and why shared AI hosting has its own isolation risks. It ends with the questions to ask any AI provider, and what to do if you run SGLang yourself.
The short version: this was not a database breach. The model reused GPU memory that still held another customer’s work, and that data showed up in a reply. Cloudflare fixed its setup on September 9, and SGLang shipped fixes in October. Cloudflare’s post does not say it contacted affected customers. If you used GLM-5.3 on Workers AI in that window, ask Cloudflare directly.
What Cloudflare says caused the Cloudflare Workers AI leak
According to Cloudflare’s October 26 post-mortem, a small number of customers using GLM-5.3 received replies that held "data from other customers’ requests made to the same model shortly before theirs." The post says: "In total, 155 responses were affected, all to prompts longer than 681,280 tokens."
That number is the key. Cloudflare deployed GLM-5.3 with a context window of 1,048,576 tokens. But the memory pool that holds a prompt’s working data during the first processing step "only had room for 681,280 tokens," the post says. Cloudflare says it knew about the mismatch before launch. Its tests checked HTTP status codes and streaming output, not whether the answers were correct.
A very long prompt should have been rejected. Instead, a bug in SGLang let it through. Cloudflare says the request was marked as rejected and given a one-token placeholder. A later check looked at whether the request had finished, not whether it had been rejected. So the request kept going. The model then read memory pages that still held other users’ data, and the customer got a normal HTTP 200 reply.
Cloudflare says no other Workers AI model was affected. It also says: "We found no evidence of deliberate exploitation." A researcher, Gadi Evron of Knostic, reported the issue on September 8 through Cloudflare’s HackerOne program.
The timeline and the fix
Cloudflare’s post gives a timeline in UTC. The model launched on August 27 with the undersized memory pool. The report came in late on September 8. On September 9, Cloudflare declared an incident, reproduced the leak within 25 minutes, and set the model to private at 14:00. It corrected the configuration, deployed a patched engine, and made the model public again at 19:40.
The public record of the Cloudflare Workers AI leak from that day says little. The Cloudflare status page entry was titled "Cloudflare Workers AI increased errors." It did not mention data exposure. The full account came almost seven weeks later, on October 26, timed with the SGLang team’s own post.
Cloudflare lists these fixes:
- The memory pool for the first processing step now holds "about 2.04 million tokens," roughly twice the context window.
- SGLang is patched so over-length requests are rejected before any data moves between machines.
- New pre-deployment checks compare pool size to context length.
- More hardening for timing problems in how memory is handed between machines.
What a KV cache is, in plain words
A large language model reads your prompt in pieces called tokens. For each token, it computes two sets of numbers, called keys and values. It keeps them so it does not have to redo that work for every new word it writes. That stored work is the KV cache. Our explainer on context windows covers why long prompts take so much memory.
Cloudflare’s post puts it simply: "The KV cache in GPU memory is a shared pool of fixed-size pages." Many requests from many customers draw pages from the same pool. When a request ends, its pages go back to the pool for the next request.
That reuse is safe only if a request reads nothing but its own data. In the Cloudflare Workers AI leak, a request got pages that had never been filled with its own data. It read what earlier users left behind.
Cloudflare’s setup also split the work across machines. One group of machines reads the prompt (the "prefill" step). Another group writes the answer (the "decode" step). The data moves between them. That handoff is where SGLang’s bug lived.
Why shared AI hosting is a multi-tenant system
Most teams judge AI data risk by storage and training: will the provider keep or train on my prompts? The Cloudflare Workers AI leak shows a third risk. It happened in memory, during the few seconds a request was running.
A hosted AI API is a multi-tenant system, like shared web hosting. Many customers share the same GPUs, the same memory pool and the same serving software. That sharing is what makes the price low. It also means isolation has to be built into the serving engine, not just the database.
This is a different kind of failure from a database breach. No stored records were taken. No one broke into an account. The engine reused memory, and the leftovers became part of a reply. Logs and access controls would not catch it, because every request looked normal and got a success code.
If your team has weighed hosted APIs against running models in-house, this belongs in the comparison. Our guide to local AI models covers what changes when the hardware is yours. Running your own model removes other tenants, but it does not remove the engine bugs.
What SGLang changed, and who needs to update
The SGLang team published its own account the same day. In SGLang’s security update, it says the problem affects deployments that split prefill and decode across machines. It says default setups of that kind were affected from the v0.4.x line, in early 2025, until v0.5.21. Single-instance deployments without that handoff were not affected.
The bug was not unknown. A different user filed SGLang issue #30233 on July 6, according to Cloudflare. The issue describes rejected over-length requests producing unrelated text on the decode side.
On GitHub, the SGLang v0.5.22 release is dated October 19 and was marked Latest when we checked on November 2. Its notes list the drain-aware abort fix (#37077) and the failed Mooncake send fix (#43719). Cloudflare says: "We highly recommend all operators update SGLang dependencies to v0.5.22 or later." SGLang says it has "not backported this fix line to earlier release branches."
SGLang’s post names one more fix for a later v0.5.23. GitHub did not list that release when we checked.
If you self-host large models, check whether you run SGLang in split prefill and decode mode. Our Kimi K3 self-hosting cost breakdown covers the class of hardware where that setup is common. Then compare your memory pool size to the context length you advertise. That one check would have caught Cloudflare’s mismatch.
How other AI APIs describe prompt cache isolation
OpenAI, Anthropic and Google all reuse cached prompt work to cut cost and latency. Each one documents who can share a cache. OpenAI’s prompt caching guide says caches "are not shared across organizations." Anthropic’s prompt caching docs say "Different organizations never share caches," and isolate by workspace on the Claude API. Google’s Gemini API data retention page says implicit cache data is "isolated at the project level" with a 24-hour limit. Cloudflare’s own Workers AI prompt caching page explains prefix caching but, as of November 2, does not say how caches are scoped. These are policy statements about caching by design. The Cloudflare Workers AI leak was an engine bug, which no policy page covers. Our post on cache hit rates and Claude costs covers the cost side of caching.
Questions to ask after the Cloudflare Workers AI leak
These apply to Cloudflare, OpenAI, Anthropic, Google and any smaller host. Ask them before you send sensitive data, and put the answers in your vendor file.
| Topic | What to ask | Why it matters |
|---|---|---|
| Isolation | How do you keep one customer’s in-memory data out of another’s request? | Shared GPU memory is where this leak happened |
| Prompt caching scope | Is caching scoped to my account, workspace or project? Is it on by default? Can I turn it off? | Scope rules differ by provider and are not always published |
| Testing | Do your launch tests check output correctness, or only status codes? | Cloudflare’s tests passed while answers were wrong |
| Incident notification | Will you tell me directly if my data appeared in another customer’s response, or theirs in mine? | A status page may only say “errors” |
Add one more for your own team: can you pull request logs for a past date range? If a provider names a window like August 27 to September 9, you need to know whether your requests fell inside it.
What Workers AI customers should do now
If you called @cf/zai-org/glm-5.3 on Workers AI between August 27 and September 9, 2026, check your usage logs for that window. Two kinds of customers could be involved. Some received replies with other people’s data. Others sent requests whose data may have appeared in those replies. Cloudflare’s post does not say which accounts were in either group, and it does not describe direct notice. Open a support ticket and ask.
If your workloads run on Workers more broadly, nothing in the post points to other models or products. Our posts on Cloudflare Pages becoming Workers and on Deno joining Cloudflare cover where the rest of the platform is heading.
Frequently Asked Questions
What was the Cloudflare Workers AI leak?
A bug in how Cloudflare served the GLM-5.3 model let 155 responses include data from other customers’ recent requests to the same model. It ran from August 27 to September 9, 2026. Cloudflare disclosed it on October 26.
Was this a database breach?
No. No stored records were taken and no accounts were broken into. The serving engine reused GPU memory that still held another request’s data, and that data ended up in a reply.
Which model and dates were affected?
Only GLM-5.3 on Workers AI, from August 27 to September 9, 2026, according to Cloudflare. It says no other Workers AI model was affected.
Why did only very long prompts trigger it?
The model allowed prompts up to 1,048,576 tokens, but the memory pool for reading prompts held only 681,280. All 155 affected responses came from prompts longer than 681,280 tokens.
Did Cloudflare notify affected customers?
Its post does not say so. The status page on September 9 described “increased errors.” If you used GLM-5.3 in that window, ask Cloudflare support directly.
Was the Cloudflare Workers AI leak exploited on purpose?
Cloudflare says it found no evidence of deliberate exploitation. It says the affected requests looked like ordinary long-context use.
Which SGLang version fixes the bug behind the Cloudflare Workers AI leak?
Cloudflare recommends v0.5.22 or later, released October 19. SGLang says setups that split prefill and decode were affected until v0.5.21, and it has not backported the fixes to older branches.
Do OpenAI, Anthropic and Google share prompt caches between customers?
Their docs say no. OpenAI and Anthropic say caches are not shared across organizations, and Google says Gemini API cache data is isolated by project. Those are design rules, and an engine bug can still break them.
Is self-hosting a model safer?
It removes other tenants from your GPUs, so another customer’s data cannot reach you. It does not remove engine bugs. Keep your serving software updated and test output, not just status codes.
