Cloudflare has disclosed a security incident affecting its Workers AI platform, revealing that a tenant isolation issue in the GLM-5.3 text generation model allowed a small number of users to receive responses containing data from previous customer requests. The vulnerability, which persisted from August 27 to September 9, 2026, was identified by security researcher Gadi Evron of Knostic through Cloudflare’s HackerOne bug bounty program. Cloudflare has confirmed that no other model hosted on Workers AI was affected by the flaw.
According to Cloudflare’s technical post, the issue impacted 155 responses out of normal operations. All affected outputs occurred exclusively in response to prompts exceeding 681,280 tokens. An analysis of the request logs and timing profiles indicated that the traffic patterns matched ordinary long-context use rather than malicious exploitation, and the company found no evidence of deliberate targeting or data extraction.
The incident is the result of an overlapping configuration mismatch and a software bug within SGLang, the open-source inference engine utilized by Cloudflare to manage high-performance large language models. The companies have published coordinated disclosures outlining the root causes, immediate remediation steps, and long-term hardening measures implemented across production environments.
What Happened
The GLM-5.3 model, developed by Z.ai for agentic coding workflows, was integrated into Cloudflare’s Workers AI catalog shortly before the issue arose. Gadi Evron submitted his report on September 8, 2026, noting that extremely long prompts sent to the model occasionally surfaced text belonging to other users’ active or recent sessions. Cloudflare’s Product Security team successfully reproduced the data leakage across independent accounts the following morning, declaring a formal security incident and taking the GLM-5.3 model offline within forty minutes. Service was restored later that day after a corrected configuration and a patched inference engine were deployed.
The vulnerability emerged due to two distinct technical misalignments. First, Cloudflare deployed GLM-5.3 with an advertised context window of 1,048,576 tokens, but the Key-Value (KV) cache memory pool allocated on the prefill GPUs was only provisioned to handle 681,280 tokens. While engineering teams were aware of this capacity disparity prior to launch, pre-launch benchmarking tests showed successful HTTP status codes and streaming bodies without error frames. Cloudflare assumed the inference engine would gracefully handle the difference, failing to validate the actual coherence and textual output under maximum context lengths.
Second, a bug in SGLang’s handling of oversized requests within its disaggregated prefill and decode architecture triggered the data crossover. When a prompt exceeded the size of the prefill KV cache pool, SGLang’s scheduler internally rejected the request, logging an error and swapping the prompt for a one-token placeholder to let it pass through standard batching routines without allocating full memory. In a single-node setup, this safely terminated the request with a client error. However, in a disaggregated architecture, the admission queues on both prefill and decode nodes evaluated whether a request was finished rather than whether it had been explicitly rejected. Consequently, the rejected request reported itself as active, causing the prefill node to generate and transfer a partial KV cache to the decode node while leaving earlier session data intact in memory. The decode node processed the request while attending over stale cache pages, resulting in data exposure.
Immediate Remediation and Response Timeline
Upon identifying the vulnerability, Cloudflare removed public access to GLM-5.3, redirecting requests to return HTTP 400 errors while engineers investigated the root cause. The engineering team deployed a corrected configuration that adjusted the GLM-5.3 prefill memory pool to accommodate roughly 2.04 million tokens, comfortably exceeding the model’s 1.048,576-token context window. This adjustment ensures that any valid prompt fitting the context window will always fit the KV pool, rendering the rejection path unreachable for legitimate queries.
Concurrently, Cloudflare developed and deployed a patch to ensure that the engine’s request rejection path operates safely. By retiring rejected requests at the disaggregation admission queue prior to any memory allocation or KV cache transfer, the system prevents stale state propagation. Cloudflare worked alongside upstream maintainers at RadixArk, the core developers behind SGLang, to integrate these fixes into the mainline repository. The patches were subsequently incorporated into SGLang versions v0.5.20, v0.5.21, and v0.5.22.
Background on Workers AI Architecture
Workers AI runs models like GLM-5.3 using a disaggregated inference setup powered by SGLang and Mooncake, an efficient remote direct memory access (RDMA) data transfer framework. In this architecture, a dedicated pool of prefill GPUs processes the incoming prompt to construct the model’s KV cache. That cache is then transferred via RDMA to a separate pool of decode GPUs responsible for generating the final response tokens.
The underlying GPU memory for the KV cache consists of a shared pool of fixed-size pages that are assigned to requests upon admission and released upon completion. To optimize performance, these memory pages are not zeroed out between requests; incoming tasks simply overwrite existing page data. This design places the responsibility of strict ownership tracking squarely on the inference engine. In disaggregated deployments, managing these memory boundaries is uniquely challenging because mutable references are shared simultaneously across remote prefill and decode nodes.
Ongoing Hardening and Industry Recommendations
The incident highlighted a broader class of memory-safety challenges inherent to high-performance inference engines, where memory pages can occasionally be freed, reused, or read while concurrent tasks maintain valid claims on them. Cloudflare has previously contributed several patches to SGLang addressing local page lifetimes during host offloading and grammar error handling, as well as race conditions occurring across distributed nodes during RDMA transfers.
Following the GLM-5.3 incident, Cloudflare deployed extensive hardening measures across all production SGLang deployments. These include enabling strict pre-deployment checks to verify that KV cache memory pools match or exceed model context lengths, updating router configurations to cancel both halves of a request upon client disconnection, and enabling per-transfer KV checksum verification so that decode nodes validate data integrity before generating responses. Furthermore, Cloudflare is collaborating with SGLang maintainers to advance native integrity checks, such as physical page-level tagging, which would cause an engine to fail an isolated request if it attempts to read from a memory page it does not own.
Cloudflare and the SGLang maintainers have recommended that all operators running disaggregated inference architectures update their SGLang dependencies to version v0.5.22 or later to mitigate potential memory-safety races and ensure robust error handling during request rejections. Coordinated disclosures and technical deep dives regarding the incident have been published jointly by Cloudflare, LMSYS, and the SGLang team.
