The Cloudflare GLM-5.3 leak exposed pieces of other customers’ prompts in 155 AI responses on Workers AI. It ran from August 27 to September 9, 2026, and only hit very long prompts. Cloudflare says it found no sign anyone abused it, and the bug is now fixed.
If you never sent a prompt longer than about 681,000 tokens to that model, you were not in the blast radius. Here is what broke, who should worry, and what to check if you run your own AI servers.
Quick facts first:
- Affected model:
@cf/zai-org/glm-5.3on Cloudflare Workers AI. No other Workers AI model was hit. - Window: August 27 to September 9, 2026.
- Scale: 155 responses, all for prompts above 681,280 tokens.
- Cloudflare published its write-up on October 26, 2026 and is contacting affected accounts.
The short version is that a small number of long-context customers were affected, and the root cause also matters to anyone self-hosting models.
What actually happened in the Cloudflare GLM-5.3 leak
Per Cloudflare’s own post-mortem, some responses from GLM-5.3 contained data from other customers’ requests sent to the same model moments earlier. Cloudflare launched the model on August 27 with the problem already present.
A security researcher, Gadi Evron of Knostic, reported it through HackerOne on September 8. Cloudflare declared an incident the next day, set the model to private, and restored it to public about six hours after that.
Cloudflare says the affected requests looked like normal long-context usage. It found no evidence anyone exploited the flaw on purpose.
The timeline, all in 2026, looks like this:
| Date | Event |
|---|---|
| August 27 | GLM-5.3 launches on Workers AI with the flaw already present |
| September 8 | Researcher Gadi Evron reports it via HackerOne |
| September 9 | Incident declared, model made private, then restored after fixes |
| October 2 and 19 | SGLang v0.5.21 and v0.5.22 released |
| October 26 | Cloudflare publishes its full write-up |
Why this matters: the bug sat unnoticed for about two weeks, and an outside researcher found it, not Cloudflare’s own tests.
Why long prompts triggered the bug
Two problems stacked on top of each other. The first was a configuration mismatch: the model advertised a 1,048,576-token context window, but the memory pool that holds its working cache (the KV cache) only fit 681,280 tokens.
The second was a bug in the SGLang serving software. When a request was too long, it was marked as rejected and given a one-token placeholder, but it was never actually cancelled. The next stage then read stale cache pages left behind by earlier users.
Think of it like a hotel clerk handing you a room key without clearing the previous guest’s belongings. Cloudflare notes the SGLang bug had been reported upstream on July 6, weeks before the model launched.
Who was affected, and who wasn’t
Only people who sent prompts longer than 681,280 tokens to this one model could have received, or leaked, someone else’s data. That is a lot of text, roughly several full-length novels.
Here is how the risk breaks down:
| Your situation | Risk level | What to do |
|---|---|---|
| Used other Workers AI models | None reported | Nothing needed |
| Used GLM-5.3 with normal-length prompts | Very low | Watch for a Cloudflare notice |
| Sent prompts over 681,280 tokens to GLM-5.3 | Possible exposure | Check your email and rotate any secrets in those prompts |
| Self-host GLM-5.3 on SGLang | Same bug class | Upgrade and audit your cache settings (see below) |
Why this matters: long prompts are exactly where people paste contracts, codebases, and logs, so the data at risk tends to be sensitive.
What to check if you run your own AI servers
The fix was not just a patch. Cloudflare grew its cache pool to about 2.04 million tokens, roughly twice the context length, and patched SGLang so rejected requests are dropped before any cache transfer.
Cloudflare’s advice for operators boils down to a short checklist:
- Compare cache pool size with context length on every node, and lower the context length if the pool is smaller.
- Upgrade to SGLang v0.5.22 or later, or backport the patches.
- Turn on corruption checks such as
--disaggregation-enable-kv-checksumand--kv-canarywhere supported.
It is the same lesson as other recent agent-security stories: the model is rarely the weak spot, the plumbing around it is. We covered a similar trust problem in the AGENTS.md attack, and 1Password for Agents shows one way to keep credentials out of an AI’s reach.
Frequently Asked Questions
Was my ChatGPT or Gemini data leaked?
No. This only involved GLM-5.3 on Cloudflare Workers AI. Cloudflare says no other Workers AI model was affected.
How many people were affected by the Cloudflare GLM-5.3 leak?
Cloudflare counted 155 affected responses and says a small number of customers were involved. It has not published a customer count.
Is GLM-5.3 on Workers AI safe to use now?
Cloudflare restored the model on September 9 after validating the fixes, and later added extra hardening. Sensitive workloads should still avoid pasting secrets into prompts.
What is a KV cache?
It is the short-term memory a language model keeps while it reads your prompt, so it doesn’t redo work for every new word. If that memory is mixed up between users, one person’s text can leak into another’s answer.
Our take
This was handled better than most incidents: fast disclosure, exact numbers, and a clear fix. Still, treat any hosted AI as a shared building, and keep passwords, API keys, and customer data out of prompts unless you truly need them there. If you run your own inference stack, today is a good day to check that cache pool against your context length.
Leave a Reply