Cloudflare's GLM-5.3 leaked 155 responses across customers - what it means for automation on hosted models

For 13 days this summer, Cloudflare's hosted GLM-5.3 model sometimes answered one customer's request with pieces of another customer's data. Cloudflare published the post-mortem on 26 October. According to Cloudflare, 155 responses between 27 August and 9 September contained data from other users' requests. Every one of them came from a prompt longer than 681,280 tokens.

No one hacked anything. A configuration mistake met an engine bug, and the result was a cross-tenant leak that returned HTTP 200.

What happened

The model was advertised with a 1,048,576-token context window. The GPU memory pool that holds the model's working state during the first stage of processing, the KV cache, was sized at 681,280 tokens. Cloudflare's write-up says the serving engine, the open-source SGLang, sizes that pool from leftover GPU memory at startup and does not check it against the context length.

When a prompt was too long for the pool, the engine rejected it internally but swapped in a one-token placeholder and kept going. Cloudflare runs the two stages of inference on separate machines. The second machine then read memory pages that still held earlier requests, and built a reply from them. The caller got what looked like a normal, successful response.

Gadi Evron of Knostic reported it through HackerOne on 8 September. Cloudflare took the model private the next day, fixed the configuration and the engine, and restored it that evening. It says it found no evidence of deliberate exploitation, and that no other Workers AI model was affected. The SGLang fixes shipped upstream, and Cloudflare recommends v0.5.22 or later to anyone running the engine in that split setup.

The line that matters

The most useful sentence in the post is an admission. Before launch, Cloudflare says, "we only validated HTTP response codes and engine performance at long contexts." Nobody checked whether the long-context answers made sense.

That is the testing most automation gets, too. A pipeline calls a model, gets a 200, parses the JSON, moves on. Status codes tell you the server did not crash. They tell you nothing about whether the content belongs to your request.

What it means if you run automation on hosted models

Almost every business automation today sends its data to a model on shared hardware. Your invoices, support tickets and contracts sit in GPU memory next to strangers' data, separated by software. This incident is a reminder that the separation is code, and code has bugs.

Some practical readings:

**Long context is the edge, and edges break first.** Million-token windows are a selling point. The leak only touched prompts past 681,280 tokens, the region that gets the least real-world traffic and the least testing. If your workflow stuffs a whole document archive into one call because the window allows it, you are operating where providers have the least experience. Splitting the job into smaller calls is often cheaper anyway.

**A successful response is not a correct one.** If an extraction step suddenly returns a supplier you have never heard of, or a summary that does not match the input, your pipeline should notice. A cheap check, such as confirming that a quoted reference number actually appears in the source document, catches this class of failure along with ordinary hallucination.

**Self-hosting does not exempt you.** The bug sat in an open-source engine, so a team running SGLang on its own GPUs in the same split configuration had the same exposure. Owning the hardware moves the responsibility to you. It does not remove the risk.

**Ask your provider how they test isolation.** Not whether they are secure. Every vendor says yes to that. Ask whether they validate output content at the context limits they advertise. Cloudflare has now answered that question in public. Most providers have not been asked.

The honest caveat

Keep the scale in view. This was 155 responses, on one model, triggered only by unusually huge prompts, found by a researcher and fixed within a day. Cloudflare's disclosure is detailed and candid, which is more than many incidents get. This is not a reason to pull your automation off hosted APIs, and moving to a smaller provider with no public post-mortems does not make you safer.

It is also not the last incident of its kind. Inference stacks are young, they change monthly, and the pressure to advertise ever-larger context windows runs ahead of the testing behind them.

What to do this week

Look at the automations that send sensitive data to a model and find the step where the output is used without being checked. Add one assertion there that ties the answer back to the input, a reference number, a customer name, a total. It takes an afternoon, and it is the check that would have caught this leak on your side.

If you sent prompts over roughly 681,000 tokens to GLM-5.3 on Workers AI between 27 August and 9 September, check your logs and contact Cloudflare support about your account.