Cloudflare’s hosted GLM-5.3 model returned data from other customers’ requests in 155 responses after a long-context configuration mismatch triggered a faulty rejection path in the SGLang inference engine.
The exposure affected @cf/zai-org/glm-5.3 on Workers AI from August 27 through September 9, 2026. Every affected response followed a prompt longer than 681,280 tokens, according to Cloudflare’s coordinated incident report, published October 26. Cloudflare says it found no evidence of deliberate exploitation and confirmed that no other Workers AI model was affected.
The incident is notable because the service did not fail visibly. Oversized requests returned HTTP 200, coherent output and normal-looking usage data. Some of that output, however, came from GPU cache pages that still held material from earlier customers’ sessions.
How a rejected prompt reached another customer’s cache
Cloudflare ran GLM-5.3 with a configured context window of 1,048,576 tokens. The pool of GPU memory available for the model’s key-value, or KV, cache could hold only 681,280 tokens. That cache stores the intermediate attention state the model needs while generating each next token.
The mismatch should have produced a client error when a prompt exceeded the available pool. Instead, two separate components developed different views of the same request.
Workers AI uses a disaggregated serving design for this model. A set of “prefill” GPUs reads the prompt and builds its KV cache; the cache then moves over remote direct memory access, using Mooncake, to “decode” GPUs that generate the response. This separation can improve utilization and scale, but it also makes cache ownership a distributed-systems problem.
When SGLang rejected an over-capacity prompt, it replaced the input with a one-token placeholder so the request could drain through its normal machinery. That worked in a single-node setup. In the disaggregated path, however, the rejected request still appeared live to the admission queues.
The decode node reserved cache pages for the original long prompt. Prefill wrote only one page for the placeholder, then reported that the transfer was complete. Decode began generating against every page it had reserved. The unwritten pages still contained keys and values from previous requests, so the model could attend to another user’s text and reproduce it in a new response.
The leak looked like a successful inference request
Knostic researcher Gadi Evron first saw unrelated machine paths and Chinese-language tutorials during ordinary work through OpenRouter. The team traced the relevant provider to Cloudflare on September 7, then reproduced the issue through a direct Workers AI account and reported it through HackerOne the next day.
In Knostic’s disclosure, a roughly 761,000-token test reliably crossed the affected threshold. The API reported success, but the requested unique marker was absent and the answer did not relate to the prompt. That behavior could easily be dismissed as a model hallucination unless a tester checked the content rather than the status code.
Cloudflare acknowledged that it knew before launch that the advertised context length exceeded the prefill pool. Its long-context benchmarks returned successful HTTP responses and streaming bodies, leading the team to assume the engine handled the difference. The pre-launch checks measured response status and performance but did not validate output coherence.
The company reproduced the cross-account exposure on September 9 and made the model private within 40 minutes of declaring an incident. It enlarged the prefill pool to about 2.04 million tokens, installed an engine patch that stops rejected requests before cache transfer, validated the fix against the researcher’s script and restored the model that evening.
What affected Workers AI customers should check
The disclosed scope is narrow but the data at issue depends on what customers placed in long prompts. Organizations that used @cf/zai-org/glm-5.3 between August 27 and September 9 should establish whether they submitted requests above 681,280 tokens and retain the related request, response and application logs.
- Review unusually fast, incoherent or off-topic successful responses, especially those missing expected markers or structured output.
- Inventory secrets, proprietary code, customer records and internal documents included in affected long-context prompts.
- Rotate credentials or tokens that may have appeared in exposed prompts when logs or provider notifications indicate a credible path to disclosure.
- Ask Cloudflare for account-specific impact details rather than assuming that every long prompt leaked or that the reported 155 responses represent 155 customers.
- Record downstream systems that stored, indexed or acted on an anomalous response so any foreign data can be removed.
Cloudflare’s statement that it found no deliberate exploitation does not mean every affected output was harmless. It means the timing and volume resembled normal long-context use rather than repeated attempts to trigger the flaw.
SGLang operators should move to 0.5.22
The incident-specific admission fixes arrived across SGLang 0.5.20 and 0.5.21, with additional cache-lifetime, acknowledgement and observability work in 0.5.22. Cloudflare recommends that operators using disaggregated prefill and decode upgrade to 0.5.22 or later. The SGLang project’s technical advisory gives more detailed guidance for Mooncake, NIXL and MORI deployments.
An upgrade is only one part of the check:
- Read the KV pool capacity from the running engine’s startup logs on every prefill and decode node, then compare it with the configured context length after changes to model weights, quantization, tensor parallelism or memory fraction.
- Lower the context limit if the pool cannot hold it. Do not rely on an API proxy to reject oversized requests.
- Keep deferred KV release enabled on both roles so pages are not reused while remote writes may still be in flight.
- Bound Mooncake transfer batches and monitor the deferred-release outcome metrics added in 0.5.22. A high timeout ratio indicates a broken or degraded acknowledgement path.
- Enable
--disaggregation-enable-kv-checksumand--kv-canarywhere the model architecture supports them, then confirm in logs that verification is active. - Configure the router and load balancer to cancel both halves of a paired request and avoid unnecessary mid-transfer aborts.
The integrity flags do not yet cover every architecture, including all GLM-5.3 and DeepSeek V4 paths, so they should not be treated as a universal control.
AI inference state needs tenant isolation like any other cloud data
KV cache is often discussed as a performance feature: reusing it saves computation, while moving it between GPU pools increases utilization. This incident shows the security side of the same design. Shared cache pages carry customer state, even when they are not readable through a conventional file or database interface.
Zeroing every page before reuse would reduce one risk but can impose a performance cost. Cloudflare and SGLang instead added stricter admission handling, delayed page release, transfer acknowledgements, checksums, canaries and new metrics. Cloudflare also described a prototype that tags each physical cache page and checks ownership before decode reads it; its tests showed less than a 1% effect on throughput and tail latency, although the prototype was not reliable or portable enough for production.
The practical lesson for AI platform teams is sharper than “test long context.” Failure-path tests must validate model output, tenant markers and cache ownership under rejection, disconnect, timeout and transfer errors. A green HTTP response cannot establish that an inference request stayed inside its own security boundary.
