Cloudflare’s AI Leaked Other Customers’ Data in 155 Replies. What to Check

For 13 days, from Aug. 27 to Sept. 9, 2026, Cloudflare’s Workers AI service could hand one customer pieces of another customer’s session. The trigger was a very long prompt sent to GLM-5.3, the open-weight model from China’s Z.ai, which Cloudflare had launched on the platform on Aug. 27. Cloudflare disclosed on Oct. 26 that 155 responses contained data from other customers’ sessions, all of them to prompts longer than 681,280 tokens, according to Unite.AI’s account of the disclosure. The flaw sat in SGLang, the open-source inference engine Cloudflare runs, and fixes are out. Two groups need to act: Workers AI customers who used @cf/zai-org/glm-5.3 in that window, and anyone running SGLang with prefill and decode split across machines.

Three primary documents tell the story, and they don’t all say the same thing. Cloudflare published its own write-up on Oct. 26. The SGLang team published a coordinated disclosure the same day, which puts it plainly: “requests exceeding the prefill KV cache capacity could return content from another user’s session.” And on Oct. 27 Gadi Evron, chief executive of the security firm Knostic, published the researcher’s account of how he found it. We read the SGLang and Knostic documents in full; where a figure comes only from Cloudflare’s post, we say who relayed it.

What happened on Workers AI: a 681,280-token gap

A model’s KV cache is its short-term memory for a request: the processed form of every token in your prompt, stored in GPU memory so the model doesn’t redo the work for each word it writes. Big serving setups now often split the job in two. One pool of machines handles “prefill”, reading the prompt and building the cache; another handles “decode”, writing the answer. The cache is handed from one to the other.

The SGLang disclosure, quoting Cloudflare’s figures, says the GLM-5.3 deployment was configured with a context length of 1,048,576 tokens, while its prefill KV pool held only 681,280. A prompt between those two numbers was allowed in but didn’t fit. On a single machine, SGLang rejects that request with an error. In the split setup, “a request marked for rejection could still proceed through the handoff,” and decode then read cache pages that had never been filled for that request. What was in them belonged to somebody else.

The SGLang team also fixed a second, separate race: when a request is aborted, its in-flight transfers can land in cache slots already reassigned to another request and silently corrupt that request’s output.

How Knostic caught it, and what leaked

Evron’s write-up says the first clue came during ordinary work through OpenRouter, the model marketplace: file paths from a machine that wasn’t his, Chinese-language tutorials he never asked for. On Sept. 7 triage pointed at Cloudflare. On Sept. 8 he reproduced it on a direct Cloudflare account and filed a HackerOne report.

His method is worth copying. Each request carried a unique marker at both ends of a huge block of filler text, with an instruction to repeat the marker, at temperature 0. Below the threshold the model answered correctly. Above it, the responses contained personal names, client and company names, invoice numbers, euro amounts, payment dates, source-code details, file paths and agent task records. Knostic’s conclusion: the “failed boundary was tenant isolation between Workers AI customers.” An attacker needed only a paid account and an API token. One oversized request was billed 103,604.64 neurons, Cloudflare’s billing unit, for output that had nothing to do with it.

Knostic is careful about what it can’t see from outside. Its evidence, it says, is “a serving-behavior hypothesis, not a root-cause finding.” It also noticed that the model’s advertised context window was 1,310,720 tokens, and quotes a Cloudflare correction: “The actual enforced context window is 1,048,576 tokens.”

The attacker needed only a paid account and an API token.

Cloudflare’s fix, and the question nobody has answered

Cloudflare acknowledged the report on Sept. 9, according to Knostic’s timeline. Unite.AI’s summary of Cloudflare’s post says the company changed the prefill configuration that day to match its GLM-5.2 setup, raising the pool to about 2.04 million tokens, patched the engine so a request carrying a pending rejection is retired at the admission queue, and returned the model to public access the same day. Cloudflare told Knostic on Sept. 24 that it had “validated the issue and have deployed a fix.” The SGLang disclosure, relaying Cloudflare, says no other Workers AI model was affected. Cloudflare “found no evidence of deliberate exploitation” once its own tests and the researcher’s requests were excluded, Unite.AI reports.

What none of the accounts we read says is how many customers were involved, or whether Cloudflare has told the ones whose data turned up in a stranger’s response. That cuts both ways. If you sent very long prompts in the window, you may have received someone else’s data. If you used GLM-5.3 at all in the window, your data may have gone to someone else.

What Workers AI and hosted-model customers should check

1. Search your logs. Look for calls to @cf/zai-org/glm-5.3 between Aug. 27 and Sept. 9, 2026, and check usage.prompt_tokens. Anything over 681,280 falls in the range Cloudflare says produced the 155 bad responses.
2. Ask Cloudflare in writing whether your account appears on either side of those 155 responses, and what it will tell you if it does. If those responses held personal data, your own data protection duties may apply too.
3. Treat strange output as a possible incident. Knostic’s lesson is that a cross-tenant leak looks exactly like a hallucination. Names, invoice numbers or file paths you never supplied deserve a check against your own inputs.
4. Ask every AI vendor the same three questions: which inference engine and version it runs, whether it splits prefill and decode across machines, and how it isolates cached state between tenants. Then check the breach-notice clause in your contract.
5. Keep secrets out of shared inference where you can. If a prompt contains customer records, the vendor’s isolation is now part of your security model.

That last point is the real lesson. Your app can be flawless and still leak, because tenant isolation on a hosted model is a property of the vendor’s serving stack. Nobody outside can audit it. GLM-5.3, for what it’s worth, is the same model whose hacking skills Anthropic’s red team tested in early October, and Workers AI keeps adding models, most recently Cloudflare’s decision models.

Running SGLang yourself: the fix list

If you self-host open-weight models (our guide to running them locally covers the single-machine case, which is safer here), the SGLang disclosure is specific.

• Who is exposed: disaggregated prefill/decode serving with a KV transfer backend (Mooncake, NIXL, MORI or a custom one). Default configurations were affected from the v0.4.x line in early 2025 until v0.5.21, or v0.5.22 for MORI. Single-instance deployments without the cross-engine path are not affected by the race.
• Upgrade: v0.5.21 (Oct. 2) protects Mooncake and NIXL by default. v0.5.22, released Oct. 19, adds MORI and fixes such as #43719. The disclosure lists one more, #45973, for v0.5.23, so take the newest release.
• Check your numbers: make sure your configured context length can’t exceed your prefill KV pool. That mismatch was Cloudflare’s trigger.
• Stuck on v0.5.19 or v0.5.20? Set SGLANG_DISAGGREGATION_DEFERRED_DECODE_KV_RELEASE=1 on both prefill and decode servers; on v0.5.20, also set SGLANG_MOONCAKE_MAX_TRANSFER_BATCH_INDICES and raise the deferred-release timeout (the team suggests 60 to 120 seconds). The team’s warning: “Neither replaces upgrading.”
• Verify: the optional –disaggregation-enable-kv-checksum flag, on both engines, checks cache integrity at some GPU cost. Then watch the sglang:decode_deferred_kv_release_total metric. “A healthy deployment releases almost all holds through drained,” the team writes.
• Router: a router that cancels both halves of a request pair, as sgl-router’s PD mode does, is “the first layer of defense.”

More on securing AI tools sits in our privacy and security coverage. The detail that stays with us is from Knostic’s tables: one 812,377-token request came back without a single occurrence of the marker or filler words, carrying identifiers that appeared nowhere in what Knostic sent.