Cross-request KV cache exposure in the GLM-5.3 Workers AI model, and our remediation with SGLang

Cloudflare addressed a critical security vulnerability in its GLM-5.3 Workers AI model that exposed customer data between late August and early September 2026. The issue, discovered by security researcher Gadi Evron from Knostic, affected 155 responses containing data from other users' requests when processing prompts longer than 681,280 tokens.

The company took the model offline within 40 hours of receiving the report on September 8, implemented fixes, and restored service by September 9. Cloudflare confirmed that no other models hosted on Workers AI were impacted by this specific vulnerability.

Root causes identified

The data leak resulted from two overlapping issues. First, a misconfiguration where the GLM 5.3 model was deployed with a 1,048,576-token context window, but the KV cache pool on prefill GPUs only accommodated 681,280 tokens. Cloudflare was aware of this mismatch before launch but believed the engine would return errors for unprocessable prompts.

Second, a bug in SGLang's handling of over-length requests in disaggregated prefill/decode mode caused the system to transfer stale cache pages containing previous users' data instead of properly rejecting the request. This led to responses containing information from other customers' sessions.

Remediation implemented

Cloudflare implemented two key fixes to resolve the vulnerability. They adjusted the GLM 5.3 configuration to match their GLM 5.2 setup, expanding the GPU memory so the prefill KV pool now holds about 2.04 million tokens—roughly twice the context length. This ensures valid prompts always fit the pool.

The company also patched the SGLang engine to safely handle rejection cases. Requests carrying pending rejections are now retired at the disaggregation admission queue before any bootstrap, allocation, or KV transfer occurs. Cloudflare contributed these fixes upstream to the SGLang project.

Architecture background

Workers AI runs GLM 5.3 with SGLang in a disaggregated configuration where prefill GPUs process prompts and transfer KV cache to decode GPUs via RDMA. The KV cache uses a shared pool of fixed-size pages that aren't zeroed between requests, requiring careful tracking of ownership.

Cloudflare has since implemented additional safeguards, including direct validation of KV pool size against context length from the running engine before any deployment changes. The company continues working with SGLang maintainers to address similar vulnerabilities in the future.