Disclosure first: I work at Zscaler, and Cloudflare competes with us. So take my framing with that in mind, and check the facts yourself. Every one of them comes from Cloudflare's own write-up, linked below. I'm also a few days late on this one. Cloudflare published on October 26, and it deserves more attention than it got.
What Happened
From August 27 to September 9, customers calling the GLM 5.3 model on Cloudflare Workers AI could get back responses that, in Cloudflare's words, "contained data from other customers' requests made to the same model shortly before theirs."
Cloudflare counts 155 affected responses, all for very long prompts (over 681,280 tokens), across what it calls "a small number of customers." It found no evidence of deliberate exploitation, and says no other Workers AI model was affected.
The root cause, per Cloudflare, was two problems stacked on each other:
- A sizing mismatch. The model advertised a context window of about a million tokens, but the memory pool holding the model's working state (the KV cache) only fit about 681,000.
- A bug in SGLang, the open source serving engine. Requests that were too long were marked as rejected but kept flowing through the pipeline instead of returning an error. The part of the system generating the answer then read leftover cache pages from earlier requests. Other customers' requests.
Credit Where It's Due
Cloudflare handled this well, and I want to say that plainly.
A researcher, Gadi Evron of Knostic, reported it through HackerOne on September 8. Cloudflare took the model private the next afternoon, fixed it, and restored access that evening. Then they did the part most vendors skip: a detailed public write-up with the root cause, the exact numbers, and the fix. They patched SGLang and pushed the fixes upstream so everyone running that engine benefits, added checks that the data transferred matches what was reserved, and applied the hardening to every model they serve that way.
That's what good incident response looks like. No hand-waving, no "out of an abundance of caution." Specifics.
The Competitive Lens
Here's the architectural point, and it applies to every AI provider, not just Cloudflare. Including the AI features in products like mine.
AI inference is multi-tenant in ways most buyers never think about. To make large models fast and affordable, providers share GPUs, batch requests from different customers together, and reuse cached state. That's how the economics work. It also means tenant isolation for AI isn't only a network or identity property. It lives deep in the serving stack: memory pools, cache handling, and edge cases like "what happens when a prompt is too long?"
Traditional security controls didn't help here. Access controls were fine. Encryption was fine. The leak happened inside the inference engine, below anything a customer could configure. Your data isolation was a property of your vendor's open source dependency.
So the question to ask every AI vendor isn't "are you secure?" It's:
- Where is my data cached, and is that cache ever shared with other tenants' requests?
- What's your isolation boundary for inference: per customer, per request, or none?
- Which serving engines do you run, and how fast do you patch them?
- Will you tell me if my responses or my prompts were part of an exposure, and how quickly?
Ask Zscaler those too. Every vendor shipping AI features should have real answers.
What To Do About It
- If you used GLM 5.3 on Workers AI between August 27 and September 9 with very long prompts, check whether anything sensitive went into those prompts, and ask Cloudflare whether your account was among those affected. The write-up doesn't say whether affected customers were contacted directly.
- If you run SGLang yourself in disaggregated prefill/decode mode, read Cloudflare's post closely. They list concrete checks: size the KV pool against your context length and upgrade to SGLang v0.5.22 or later.
- Classify what goes into AI prompts. Huge prompts are often whole documents, codebases or data dumps. That's exactly what you don't want landing in someone else's response. DLP on AI traffic isn't paranoia anymore.
- Add AI inference to your vendor risk reviews, with the questions above, as its own line item.
Bottom Line
No vendor is immune to bugs like this, Zscaler included. Cloudflare found it through a researcher, fixed it fast, and explained it honestly. The lesson isn't "avoid Cloudflare." It's that when you send a prompt to a shared AI service, the isolation you're counting on lives in places you can't see. Ask about it before you find out the hard way.
Sources: Cloudflare: Cross-request KV cache exposure in the GLM-5.3 Workers AI model and eWeek on the Cloudflare AI leak