Cloudflare discloses a fixed GLM-5.3 cache exposure affecting 155 responses

Cloudflare has published an incident account describing cross‑request data exposure in @cf/zai‑org/glm‑5.3 on Workers AI. The report was published October 26, but the exposure window was August 27 through September 9, 2026. Cloudflare says it remediated the issue and restored the model on September 9. This is a disclosure of a previously fixed incident, rather than an announcement of a current outage.

According to Cloudflare, 155 responses contained data from other customers’ requests to that same model shortly beforehand. Those were responses to prompts longer than 681,280 tokens. The count describes responses, not 155 identified people, organizations or accounts. The report does not supply a count of distinct affected customers.

Cloudflare says no other model hosted on Workers AI was affected. After excluding its own tests and the researcher’s activity, it found no evidence of deliberate exploitation in the requests it identified. Those are the provider’s findings from its investigation; they are not an independent audit or proof that no exploitation could have occurred.

The technical account describes two conditions that combined to produce the exposure. Cloudflare configured an advertised 1,048,576‑token context window, while the prefill GPU cache pool had space for 681,280 tokens. The model’s context setting and the memory available for its key‑value cache were separate quantities.

A key‑value, or KV, cache retains intermediate model state used to generate a response. In Cloudflare’s disaggregated setup, one group of GPUs processed the prompt, then transferred cache data to another group that generated the output. The engine rejected prompts that did not fit the prefill pool, but a one‑token placeholder still passed through the handoff. The decoder then read cache pages that the new request had not overwritten, including state from previous requests.

The practical distinction is between receiving a successful response and validating what produced it. Cloudflare says its earlier long‑context tests checked HTTP success and engine performance without validating output coherence. A successful HTTP status did not establish correct request isolation in this incident. This account does not establish the same failure in every SGLang deployment or in other hosting providers’ implementations.

Cloudflare’s UTC timeline says it received the researcher’s report September 8, set the affected model to private on September 9 at 14:00 UTC, and restored public access at 19:40 UTC that day. Before restoration, it enlarged the cache pool to hold valid prompts and patched the engine so rejected requests would stop before cache allocation and transfer. It says both changes were checked against the reported reproduction and its own marker tests.

The disclosure also describes later hardening of cache‑page lifetimes, cross‑node transfers and deployment checks. For operators of disaggregated SGLang, Cloudflare recommends measuring the running cache pool against the configured context length and using a build that includes the relevant fixes, pointing to v0.5.22 or later, or appropriate backports. Its advice is scoped to the affected architecture and patches; it is not a claim that a version number alone proves an operator’s entire deployment secure.

Some longer‑term work remains unfinished. The report distinguishes deployed configuration and engine changes from proposals such as zeroing cache pages on release and broader integrity checks. OpenTools has reviewed this published account without reproducing the exposure, inspecting customer data or testing the remediation.

Cloudflare’s San Francisco office entrance at 101 Townsend Street, photographed December 17, 2021. Historical company context, not the affected inference hardware or evidence of the incident. Photo: HaeB / Wikimedia Commons, CC BY‑SA 4.0. Cropped and resized; adapted image under the same licence.