Cloudflare's GLM-5.3 Bug Put Other Customers' Prompts Into 155 Responses. Here Is What Happened.

Cloudflare published a detailed post-incident report on Oct. 26, 2026 saying that one AI model on its Workers AI service, GLM-5.3, returned fragments of other customers' requests in 155 responses. The exposure ran from the model's launch on Aug. 27 until Cloudflare fixed it on Sept. 9. This article summarizes what Cloudflare reported, what the cause was, and what anyone running a similar system should check.

Everything below about the incident comes from Cloudflare's own post and a news summary of it. We did not test the service, and Cloudflare's account has not been independently verified.

What Happened

When Cloudflare launched GLM-5.3 on Workers AI (the model ID is `@cf/zai-org/glm-5.3`), some responses to very long prompts contained pieces of prompts and partial answers that belonged to other customers' earlier requests. Cloudflare counts 155 affected responses. All were for prompts longer than 681,280 tokens, which is far longer than typical chat or document prompts.

Cloudflare says only this model was affected, that "a small number of customers" were involved, and that it found no evidence of deliberate exploitation. It says the affected requests looked consistent in timing and volume with ordinary long-context use.

Timeline

Times are from Cloudflare's post, in UTC.

• Aug. 27: GLM-5.3 launches. The exposure is present from the start.
• Sept. 8, 23:11: Security researcher Gadi Evron of Knostic reports the problem through Cloudflare's HackerOne program, with a reproduction script.
• Sept. 9, 13:22: Cloudflare declares a security incident and reproduces the leak with two accounts within 25 minutes.
• Sept. 9, 14:00: The model is set to private, and requests return an HTTP 400 error.
• Sept. 9, 14:52: All prefill nodes are rolled to a corrected configuration.
• Sept. 9, 19:40: After a rebuild with the corrected configuration and a Cloudflare-written engine patch, the model returns to public access.
• Sept. 16 to Oct. 12: Fixes are merged upstream into SGLang, the open-source engine involved. SGLang v0.5.21 was released Oct. 2 and v0.5.22 on Oct. 19.
• Oct. 26: Cloudflare, the researcher and SGLang's maintainers publish together.

From the researcher's report to the model going private took about 15 hours.

Why It Happened

Cloudflare describes two overlapping problems.

A configuration mismatch. GLM-5.3 was set up with a context window of 1,048,576 tokens, but the memory pool that holds the model's working data for the "prefill" step (the key-value, or KV, cache) held only 681,280 tokens. Cloudflare says it knew about the mismatch before launch but assumed the serving software would return an error for any prompt that did not fit. Its tests checked HTTP status codes and streaming output, not whether the output was correct.

A bug in SGLang. In the mode that splits prefill and decoding across machines, a prompt too large for the pool was marked as rejected and replaced with a one-token placeholder. The queues that move work between the stages checked whether a request was finished, not whether it was rejected, so the rejected request went through anyway. The decoding stage then read memory pages that still held earlier requests' data, and returned a normal-looking HTTP 200 response instead of an error.

In plain terms: the system was asked to read a book that did not fit on the shelf, did not say so, and filled the gaps with pages left by the last person.

Cloudflare also says it later found a related upstream report on SGLang's issue tracker, filed July 6, 2026.

What Cloudflare Did About It

• Changed the configuration to match GLM-5.2, so the prefill pool holds about 2.04 million tokens, roughly twice the context length.
• Patched SGLang so over-length requests are rejected with their original error before any memory is allocated or transferred.
• Tested against the researcher's script and Cloudflare's own canary-marker tests before restoring access.
• Added hardening and new pre-deployment checks, and says it rolled additional hardening to all production SGLang deployments between Sept. 11 and 19.

Cloudflare recommends that operators of SGLang use v0.5.22 or later, or backport the patches. The post, as we read it, does not describe whether affected customers were individually notified.

Who Was at Risk

This is analysis, not reporting. The exposure window was long, 13 days, but the trigger was narrow. A response could only leak if the prompt exceeded 681,280 tokens, and most uses of AI models are far shorter than that. Teams that send entire codebases, document archives or long agent histories to a single prompt are the ones most likely to have been in range. Anyone who sent only ordinary prompts would not have triggered the failing path, according to Cloudflare's description. What we cannot say is how many customers received other people's data or what was in it, because Cloudflare gives neither number.

What Operators Should Check

This section is analysis, not reporting.

• Test correctness, not just success codes. A request that fails safely should return an error. Add tests that send oversized inputs and verify the output does not contain data from prior requests, for example by planting marker strings.
• Match the pool to the context window. If your cache is smaller than your advertised context, you need a hard rejection path that has been tested, not an assumption.
• Pin and update your inference engine. If you run SGLang in disaggregated mode, check that you are on v0.5.22 or later or have the patches.
• Treat shared caches as a security boundary. Where several customers share a cache, memory that is reused must be cleared or isolated.

For context on the model: GLM-5.3 is an open-weight model, listed in our open-weight comparison. The bug was in how it was deployed and served, not in the model's weights, so it does not mean the model itself is unsafe to run elsewhere.

What We Cannot Conclude

We cannot verify Cloudflare's count, the absence of exploitation, or whether other deployments of the same engine had the problem. A news summary of the incident gave a meeting date with SGLang's maintainers that differs from Cloudflare's own timeline, and we followed Cloudflare's. We did not review the SGLang code.

Why It Matters

• Fast and quiet. The leak returned normal-looking successful responses, so ordinary monitoring would not have flagged it.
• The model was not the problem. The weak point was serving configuration and a shared engine bug.
• Disclosure worked. An outside researcher reported it, Cloudflare took the model private within hours of declaring an incident, and fixes landed upstream.
• Long context raises the stakes. Million-token prompts push memory systems into edge cases that tests built for short prompts do not catch.