Cloudflare says its GLM-5.3 Workers AI model returned other customers’ request data in 155 responses between August 27 and September 9. Its October 26 incident report describes a configuration mismatch that reached an unsafe rejection path in SGLang, the model-serving engine.

Evidence status: vendor-confirmed cross-customer exposure, with no evidence of deliberate exploitation reported by Cloudflare. The company says no other Workers AI model was affected. The 155 figure counts responses, not customers or compromised accounts.

A rejected prompt still reached the response worker

Cloudflare served @cf/zai-org/glm-5.3 using separate workers for prefill, the first pass over a prompt, and decode, which generates the answer. They exchange a KV cache, the model’s stored working memory for that prompt.

The advertised context window allowed 1,048,576 tokens, but the prefill cache could hold only 681,280. All affected responses were to prompts longer than that smaller limit.

SGLang internally rejected those requests, yet the handoff continued with a one-token placeholder. The response worker then read cache pages that still contained earlier requests’ data. The client received a successful HTTP response instead of an error.

Cloudflare acknowledges it knew about the capacity mismatch. Its pre-launch tests checked successful responses and performance without validating output coherence. A successful status code concealed a broken isolation boundary.

Cloudflare disabled the model on September 9, enlarged the cache pool and patched the rejection path. It says it verified the repairs with the researcher’s reproduction and its own marker tests before restoring service that evening.

Interrupted transfers are a separate problem

The SGLang team’s coordinated disclosure also covers a related race during asynchronous memory transfers. A cancelled request’s writes could arrive after its destination pages had been reassigned to another request.

That race requires separate prefill/decode workers, an interrupted transfer and page reuse before the writes finish. The team reports reproducing another request’s prompt text in a recipient’s output on live hardware.

That is a controlled demonstration, separate from Cloudflare’s production rejection-path incident. In the demonstrated race, data flows into another request; the cancelling client does not receive the victim’s data. Single-instance serving without this cross-engine transfer path is outside this specific race’s scope.

Upgrade the engine and check the running configuration

The two reports describe several fixes, with different release boundaries:

  • The original exposure: Cloudflare identifies SGLang v0.5.20 as containing the initial fix, with earlier rejection in v0.5.21. It recommends v0.5.22 or later for the wider hardening set.
  • Interrupted transfers: SGLang says deferred cache release became the default for Mooncake and NIXL in v0.5.21. MORI support and further failed-send handling arrived in v0.5.22.
  • A remaining release gap: the merged NIXL/MORI failed-transfer fix, PR #45973, is assigned to v0.5.23 in the disclosure. At review, GitHub’s latest published release was v0.5.22; v0.5.23 was unavailable. Operators using those backends should arrange a reviewed build or backport containing that fix, rather than assume v0.5.22 includes it.

For disaggregated deployments, compare the actual cache pool capacity with the configured context length after every model, precision or parallelism change. Lower the context limit if it exceeds the pool. A proxy limit alone leaves the engine’s rejection behavior unresolved.

Keep deferred release enabled on both worker roles and use a router that coordinates cancellation. Check release metrics: a high proportion ending by timeout instead of confirmed drain needs investigation. A timeout expiring is not proof that remote writes have stopped.

Cloudflare also recommends corruption checks where the model supports them. Verify that checks actually run; the report says checksum and canary coverage still varies by architecture. Absence of logged errors cannot establish that no leakage occurred.

Caveat: Cloudflare and SGLang supply the incident findings and repair tests. Their coordinated reports are first-party evidence, not an independent audit of every deployment or a guarantee against further cache-lifetime bugs.