Cross-request KV cache exposure in the GLM-5.3 Workers AI model (155 responses)

Discussion overview

The thread treats this as a serving-stack security failure, not a failure of GLM-5.3 itself. Commenters focused on a cross-tenant KV-cache leak caused by inadequate session isolation, a cache-capacity mismatch, and an SGLang failure to safely handle the resulting condition. The clearest practical lesson was brutal: a shared inference endpoint can expose one customer’s context to another if GPU memory and cache bookkeeping go wrong, so highly sensitive workloads may require dedicated infrastructure rather than faith in multitenancy.

Several readers objected to the title because it foregrounded the model even though the root cause sat in Cloudflare’s deployment and serving software. The provider’s response persuaded some that naming the affected endpoint was appropriate disclosure rather than blaming the model author. People also praised the unusually candid incident report: it acknowledged that the team knew the advertised million-token context exceeded available prefill cache, explained why tests missed it, and described rapidly disabling the endpoint. Still, that transparency sharpened rather than erased alarm: unrelated API outputs reported by users now look less like mysterious model behavior and more like possible isolation failures. The discussion ends with an uncomfortable open question over whether truly single-tenant inference is even readily available.

Points of disagreement

The sharp dispute is whether the incident should be branded around GLM-5.3. Critics argue that attaching the model name misdirects blame from Cloudflare’s configuration and SGLang’s unsafe cache handling, potentially tarnishing an uninvolved model vendor. Defenders argue that customers need the precise affected Workers AI endpoint identified, and that the disclosure explicitly assigns the technical fault to the serving platform rather than the model.