
Cloudflare reports GLM-5.3 Workers AI KV cache exposure and SGLang fix
Cloudflare says a tenant isolation issue affected its GLM-5.3 Workers AI model from August 27 to September 9, 2026, with 155 responses exposed. It restored the model after a configuration correction and an SGLang engine patch.
Cloudflare has reported a tenant isolation issue affecting its GLM-5.3 Workers AI model, listed as @cf/zai-org/glm-5.3, after a security researcher alerted the company to cross-request KV cache exposure. Cloudflare said the issue began on August 27, 2026, was remediated, and the model was restored on September 9. The company confirmed that no other model hosted on Workers AI was affected.
What happened
Cloudflare said the exposure resulted from two overlapping issues. It had deployed GLM 5.3 with a 1,048,576-token context window, but the KV cache pool on its prefill GPUs only had room for 681,280 tokens. A second issue was in how SGLang, the open-source inference engine Cloudflare uses, handled over-length requests in disaggregated prefill and decode mode. A prompt that did not fit the pool was marked as rejected and replaced with a one-token placeholder, but prefill generated the KV cache for the placeholder and transferred it to the decode node. The decode node assumed prefill had overwritten the KV cache with the full prompt, while most of the previous state remained intact, so it generated a response while attending over stale cache pages. In total, 155 responses were affected, all to prompts longer than 681,280 tokens. Cloudflare said it found no evidence of deliberate exploitation.
Response and remediation
According to Cloudflare, it received the report from Gadi Evron of Knostic on September 8, 2026. Cloudflare reproduced the issue the next morning and took the model offline within 40 minutes of declaring an incident. To correct the configuration, Cloudflare adjusted its GLM 5.3 setup to match its GLM 5.2 configuration, freeing enough GPU memory for the prefill KV pool to hold about 2.04 million tokens, roughly twice the 1,048,576-token context length. It also patched the engine so that a request carrying a pending rejection is retired at the disaggregation admission queue, with its original error, before any bootstrap, allocation, or KV transfer happens. Cloudflare validated the changes against the researcher's reproduction script and its own canary-marker tests before restoring the model.
Upstream fixes and hardening
Cloudflare published the report alongside a post from SGLang as a coordinated disclosure. It said the patch for the issue was released in SGLang v0.5.20, with follow-ups in v0.5.21 and v0.5.22, and it highly recommends that all operators update SGLang dependencies to v0.5.22 or later. The maintainers also merged a change that rejects these requests earlier, following the Cloudflare approach. Cloudflare said GLM 5.3 was the only model affected by this bug, and it has applied the engine fix and hardening to every model it serves with SGLang. Its deployment checks now require those changes for every new deployment. Cloudflare recommends that operators measure KV pool size against context length on every prefill and decode node, upgrade to v0.5.22 or later, run with deferred KV release on both roles, bound Mooncake transfer batches, and enable corruption detection where supported.
Sources: Cloudflare
SiTech — AI-powered web development
We build fast, modern websites and bring AI into real business workflows. Have a project or a question? We'd love to help.