Cloudflare’s 26 October disclosure says 155 GLM-5.3 Workers AI responses contained other customers’ material from 27 August to 9 September 2026. The count is responses, not customers. Its investigation found no other Workers AI model affected and no evidence of deliberate exploitation.

The big change

  • What changed: Cloudflare patched its GLM-5.3 deployment.
  • Why it matters: A reply could expose another customer’s data when cache pages held an earlier request’s state.
  • What to watch: Compare cache capacity with the input limit.

Context exceeded cache capacity

The stated context was 1,048,576 tokens; the prefill pool held 681,280. Cloudflare’s prelaunch checks validated HTTP codes and performance, not output coherence.

The key-value, or KV, cache holds working state that the model later reads while generating an answer. Mooncake’s SGLang integration guide documents how prompt processing (prefill) transfers KV blocks to a separate worker that generates the answer (decode). Decode must read only written pages.

How the rejected prompt reached decode

Over-pool prompts queued rejection with a one-token placeholder. Single-node serving returned an error. Disaggregated admission checked finished status instead of the pending error, so handoff continued.

Decode reserved original pages, but prefill delivered only the placeholder’s page. Decode read unwritten pages holding earlier state; another request’s material reached the answer. The admission fix rejects before reservation.

Capacity and rejection fixes

On 9 September Cloudflare restricted GLM-5.3, expanded the pool to about 2.04 million tokens and patched the engine before restoring access. Rejection handling remains essential.

Pull request 36988, merged 6 September but unreleased then, already prevented wrong-status and stale-KV output by retiring aborted prefill after its in-flight result. Pull request 38935, merged 16 September, moved rejection to admission to avoid wasted work and delay.

Cloudflare recommends v0.5.22 or later for disaggregated SGLang operators. The release is dated 19 October. SGLang’s security update has backend-specific guidance.

A separate abort race and the limit of its safeguard

An abort can cause a different cache ownership failure. Decode may reuse a request’s destination pages while a remote write remains in flight. The late write then changes the next request’s cache. SGLang’s deferred-release change holds pages while transfers drain; a follow-up covers other transfer failures. This race differs from the placeholder rejection path.

The hold ends after drain acknowledgements or a timeout. Acknowledgement confirms launched writes finished; timeout alone does not. Safe reuse after timeout depends on every outstanding write ending during the hold. An optional transfer checksum can catch corruption before decode on supported models.