News AI

Cloudflare GLM-5.3 bug put other customers' data in 155 replies

Long prompts to one Workers AI model returned other customers' data for 13 days. The upstream bug was public weeks before launch.

The short read

For 13 days, 155 Workers AI responses carried data from other customers' requests, all from requests over 681,280 tokens.

  • Cloudflare says a known gap between GLM-5.3's context window and its cache pool met an SGLang bug that returned stale cache pages with HTTP 200.

What you can do with this

If you sent GLM-5.3 prompts over 681,280 tokens from August 27 to September 9, ask Cloudflare if yours were among the 155, so you know what was exposed. Self-hosting SGLang? Upgrade to v0.5.22.

A corridor between rows of server racks, lit by green and blue status lights.
Photo: The National Archives (UK), CC BY 3.0

Cloudflare disclosed on October 26 that its hosted GLM-5.3 model returned parts of other customers’ requests in 155 responses between August 27 and September 9, 2026. The researcher who found it, Gadi Evron of Knostic, published Knostic’s account a day later. If your team sends long documents or code bases to a hosted model, this is the failure to plan for: the model answered normally, with someone else’s context.

A known gap met a public bug

Cloudflare says it ran GLM-5.3 “with a 1,048,576-token context window, but the KV cache pool on our prefill GPUs only had room for 681,280 tokens.” That pool is the short-term memory the model fills while it reads a prompt. By our arithmetic, it held 65% of the advertised window. “We were aware of this mismatch before launch,” the post says; Cloudflare expected the engine to reject prompts that did not fit.

It did not. In SGLang’s disaggregated mode, where one set of GPUs reads the prompt and another writes the answer, over-length requests marked as rejected were still admitted. The answering side then read stale cache pages from earlier requests, and the client got HTTP 200 instead of an error.

That bug was not new. An SGLang user reported it on July 6, writing that “Decode starts from 284936 uninitialized KV cache slots.” A bot closed the issue for inactivity on September 5. By our count, that report was public 52 days before GLM-5.3 launched on Workers AI.

What leaked, and who could see it

Cloudflare says all 155 affected responses came from prompts longer than 681,280 tokens and that only GLM-5.3 was affected. Knostic reports that the leaked text included personal names, company names, invoice numbers, euro amounts, source code details and file paths. Triggering it took an ordinary paid account and a prompt of about 700,000 tokens.

Knostic writes that Evron first saw the odd output while working through OpenRouter and traced it back to Workers AI. So teams that reached GLM-5.3 through a router, without picking Cloudflare by name, may also have sent long prompts there.

Cloudflare says it “found no evidence of deliberate exploitation.” It took the model private on September 9 at 14:00 UTC and restored it at 19:40 UTC. The corrected setup gives the cache pool about 2.04 million tokens, roughly twice the context length.

Its post does not say whether affected customers were told. Knostic praised the handling and called the HackerOne process “a pleasure.”

What to do now

  • Check your logs. If you sent GLM-5.3 prompts over 681,280 tokens between August 27 and September 9 (directly or through a router), ask Cloudflare whether your requests were among the 155. Treat anything sensitive in those prompts as possibly seen by another customer.
  • Upgrade SGLang if you host models. Cloudflare asks operators to move to v0.5.22 or later, which carries fixes #36988 and #38935.
  • Measure, do not assume. Compare the KV pool to the context length on every prefill and decode node. Cloudflare’s advice: “do not assume the engine will reject what does not fit.”
  • Weigh what goes into very long prompts. Long-context calls are where this failed. Cutting a prompt to the pages a task needs costs some answer quality but keeps less data in a shared cache.

Sources