Cloudflare Workers AI Bug Put Other Customers' Data in 155 GLM-5.3 Responses Between Aug 27 and Sep 9

TL;DR: Cloudflare says a bug in its Workers AI service let some responses from the GLM-5.3 model include data from other customers’ requests. It ran from August 27 to September 9, 2026. Cloudflare counted 155 affected responses, all to prompts longer than 681,280 tokens, and says it found no evidence of deliberate exploitation. The fix is done on Cloudflare’s side. If your app sent sensitive data to GLM-5.3 during that window, rotate any secrets in those prompts and ask Cloudflare whether your account was involved. If you run the open-source SGLang engine yourself, update to v0.5.22 or later.

What happened

Cloudflare published a detailed write-up on October 26, 2026 (6:01 a.m. on October 27, Manila time). It covers the GLM-5.3 model it hosts on Workers AI, Cloudflare’s pay-per-use AI inference service, under the ID @cf/zai-org/glm-5.3.

The timeline Cloudflare gives, in UTC:

• August 27: GLM-5.3 launches on Workers AI.
• September 8, 23:11: Security researcher Gadi Evron of Knostic reports, through Cloudflare’s HackerOne program, that very long prompts sent to the model returned other people’s data.
• September 9, 13:22: Cloudflare declares a security incident.
• September 9, 14:00: The model is made private, so new requests fail.
• September 9, 19:40: After a configuration fix and a patch to the inference engine, the model goes back online.

According to Cloudflare, 155 responses contained data from other customers’ requests made to the same model shortly before. All 155 came from prompts longer than 681,280 tokens. Cloudflare says no other Workers AI model was involved, and that apart from its own tests and the researcher’s, the requests “are consistent in timing and volume with ordinary long-context use, not with someone repeatedly exploiting the bug.”

Cloudflare names two causes:

1. A memory mismatch it knew about. The model accepted prompts of up to 1,048,576 tokens, but the memory pool that holds a request’s working data (the KV cache) only had room for 681,280 tokens. Cloudflare says it assumed the engine would handle the gap gracefully, for example by returning an error.
2. A bug in SGLang, the open-source inference engine Cloudflare uses. In a setup that splits work between separate “prefill” and “decode” servers, a request that was rejected wasn’t fully cancelled. The decode server then read memory pages that still held an earlier request’s data. Pages aren’t wiped between requests, only overwritten.

Cloudflare enlarged the memory pool to about 2.04 million tokens, patched the engine and worked with the SGLang maintainers on fixes. SGLang published its own account the same day. It says v0.5.21, released October 2, protects Mooncake and NIXL setups by default, and MORI setups need v0.5.22.

Why it matters

Hosted AI models are shared infrastructure. When you call one, your prompt is processed on the same machines as everyone else’s, and this incident shows that the separation between customers depends on details like memory sizing and cancellation handling. Cloudflare’s report is unusually detailed, which is good. But it also shows that a known mismatch between memory and context size stayed in production for nearly two weeks.

For small teams, the practical risk depends on what you sent. Two groups could have been affected:

• Anyone who sent prompts to GLM-5.3 in the window. Data from your requests could have appeared in another customer’s response. Cloudflare says the leaked text came from other users’ prompts and partial responses, but not what those prompts contained.
• Anyone who sent very long prompts. If your prompts went over 681,280 tokens, some of your responses may contain text from other people’s requests. That could mean wrong or strange output in your app, and someone else’s data now stored in your logs.

The post doesn’t say whether Cloudflare told affected customers directly, so don’t assume you would have heard. We covered another Workers AI model, Clairic for document extraction, earlier this month. The same question applies to any hosted model: what goes into a prompt is only as private as the provider’s isolation.

What to do now

1. Check whether you used GLM-5.3. Search your code and any AI Gateway logs for @cf/zai-org/glm-5.3 between August 27 and September 9, 2026.
2. If you did, look at what you sent. If prompts held API keys, passwords, tokens or customer personal data, rotate the secrets. Treat the personal data as possibly exposed and check whether your privacy obligations call for any follow-up.
3. Ask Cloudflare. The post doesn’t say whether affected customers were contacted. Open a support ticket and ask whether your account sent or received any of the 155 affected responses.
4. Review very long outputs from that window. If you sent prompts over 681,280 tokens, check those responses for text that didn’t come from your request, and remove any you stored.
5. Keep secrets out of prompts. Pass references or IDs to the model instead of raw keys or passwords, whichever provider you use. This is our advice, not Cloudflare’s.
6. If you run SGLang yourself with separate prefill and decode servers, update to v0.5.22 or later. Cloudflare also recommends checking that your KV cache pool is at least as large as the model’s context length, and turning on SGLang’s KV corruption checks where your model supports them.

Updates

• Oct 27, 2026, 1:20 p.m. Manila: First published.

Sources & method

Sources

• Cloudflare blog, “Cross-request KV cache exposure in the GLM-5.3 Workers AI model, and our remediation with SGLang,” October 26, 2026
• SGLang (LMSYS) blog, “SGLang security update: improving request isolation,” October 26, 2026
• SGLang v0.5.22 release notes
• Cloudflare Workers AI docs: GLM-5.3 model page

Method. Last checked October 27, 2026, at 1:00 p.m. Manila time (05:00 UTC). The timeline, response count, causes and fixes come from Cloudflare’s post. SGLang release details come from SGLang’s post and release notes. Cloudflare’s times are in UTC. Steps 1 to 5 under “What to do now” are our own advice, because Cloudflare’s post doesn’t give customers any steps; step 6 is Cloudflare’s recommendation for SGLang operators. No affiliate links on this page. How we work.