Cloudflare: GLM-5.3 returned other customers’ request data

One model and a past exposure window

Cloudflare says it identified 155 responses containing data from other customers’ requests sent to the same model shortly beforehand. The affected responses followed prompts longer than 681,280 tokens. The model was @cf/zai-org/glm-5.3 on Workers AI. That scope does not include every GLM deployment at every provider or every Cloudflare service.

According to the operator, exposure began when the model launched on August 27. After a researcher reported the problem on September 8, Cloudflare removed public access, fixed the configuration and inference engine, and restored the model on September 9. The report’s October 26 publication date is not the start of an ongoing leak.

Cloudflare says no other Workers AI model was affected and that it found no evidence of deliberate exploitation. Those are findings from its own investigation. They mean neither that no data crossed between customers nor that SecuFocus audited the infrastructure.

A coherent response could still use the wrong context

The SGLang engine processes prompts on one group of GPUs and generates responses on another. Its KV cache holds information computed from the context in memory. In this deployment, the prompt-processing cache was smaller than the advertised context window.

An overlong prompt should have been rejected. Instead, a handoff error let the response-generating engine read cache pages that still held data from previous requests. The client could receive HTTP 200 and a coherent reply. Neither established that the reply used only its own context.

This is an isolation failure during inference. Turning off an assistant’s use of conversations for training would not have fixed this memory-handling bug.

Check your usage before drawing conclusions about your account

If your application used this model during that period, find its identifier in the configuration and available logs. Then review the categories of data sent, such as internal documents, personal information or possible credentials. Do not paste that material into another AI request to ask whether it leaked.

Ask Cloudflare support for an account-specific assessment and preserve evidence relevant to your incident review. The length threshold for affected responses cannot, by itself, establish that your data was not exposed: the report also describes data originating in earlier requests. If you sent credentials, decide on revocation or rotation as part of that assessment.

Switching models today cannot retrieve data that may already have been disclosed. For future requests, send only what the task requires and check which provider your application actually uses.

• Send less sensitive information to an AI↗

SGLang operators also need to check errors and interrupted requests

Cloudflare recommends that operators running SGLang with separate prefill and decode stages upgrade to 0.5.22 or later, or backport the necessary fixes. It also calls for measuring actual KV pool sizes against context length on each GPU group after model or configuration changes. These are the operator’s recommendations, not package tests performed by SecuFocus.

The report also covers deferred page release, transfers and interrupted requests. Corruption checks do not yet support every model architecture. Installing a version without checking the active configuration therefore does not demonstrate that your service isolates requests correctly.

• The maintenance work that remains with self-hosting↗