Cloudflare Says Its GLM-5.3 Model Sent 155 Responses Containing Other Customers' Data, After a Cache Mismatch It Knew About Before Launch

The most useful line in Cloudflare's incident report is an admission: the company knew before launch that its GLM-5.3 deployment could hold fewer tokens in memory than the context window it advertised, and assumed the inference engine would refuse anything that did not fit. It did not, and for almost two weeks the longest prompts could come back with pieces of other customers' sessions.

What leaked, and for whom#

Cloudflare says that between August 27 and September 9, 2026, a small number of customers using the GLM-5.3 model on Workers AI (@cf/zai-org/glm-5.3) "received responses that contained data from other customers' requests made to the same model shortly before theirs." In total 155 responses were affected, all to prompts longer than 681,280 tokens, and no other Workers AI model was affected, according to the company. "We found no evidence of deliberate exploitation," Cloudflare wrote, adding that the requests it identified were consistent with ordinary long-context use.

The issue was reported on September 8 at 23:11 UTC through Cloudflare's HackerOne program by Gadi Evron of Knostic. Cloudflare's timeline says it declared a security incident at 13:22 UTC on September 9, set the model to private at 14:00 and restored it to public at 19:40 the same day.

Two faults that lined up#

Cloudflare deployed GLM-5.3 with a 1,048,576-token context window, but the memory pool for the model's KV cache on its prefill GPUs held only 681,280 tokens. Its pre-launch tests checked HTTP status codes and performance at long contexts but not the content of the output, the company says.

The second fault was in SGLang, the open-source engine Cloudflare uses, running with prefill and decode split across separate machines. An over-length prompt was marked as rejected and swapped for a one-token placeholder, but the request was still passed to the decode machine, which then generated a reply while reading cache pages that still held data from earlier requests. The client got a normal, coherent response instead of an error. Cloudflare says another user had reported the bug to SGLang as issue #30233 on July 6.

The fix and what operators should do#

Cloudflare says it enlarged the prefill pool to about 2.04 million tokens, roughly twice the context length, and patched the engine so rejected requests return their original error before any cache transfer. SGLang's fixes shipped in v0.5.20 and v0.5.21, with follow-ups in v0.5.22, and Cloudflare recommends that all operators update to v0.5.22 or later. Its first recommendation to others running disaggregated SGLang is to compare the measured KV pool with the context length on every node, adding: "This is the check we did not enforce."

The SGLang team at LMSYS published a companion post the same day as part of the coordinated disclosure. Cloudflare's account puts the fault in its own configuration and in the inference engine, not in Z.ai's model, which other providers also serve; AWS added GLM-5.3 to Amazon Bedrock in October.

Limits#

• Everything about scope, including the 155 figure and the absence of exploitation, comes from Cloudflare. SGLang's post is part of the same coordinated disclosure, not an independent check.
• SOCtember's write-up, the only independent account we found, is based on Cloudflare's post and notes that the post does not say how affected customers were notified.
• Cloudflare does not describe what kinds of data appeared in the affected responses.

Sources#

• Cloudflare Blog: Cross-request KV cache exposure in the GLM-5.3 Workers AI model, and our remediation with SGLang (October 26, 2026)
• LMSYS Org: SGLang security update: improving request isolation (October 26, 2026)
• SOCtember: Cloudflare Says a Workers AI Model Returned 155 Responses Containing Other Customers' Data Over Nearly Two Weeks (October 27, 2026)
• Times of AI: AWS Puts Z.ai’s GLM-5.3 on Bedrock; Zhipu Shares Jump on a Reported Revenue Share (October 5, 2026)