Themata.AI
Follow coverage
Themata.AI
Glm 53AI safetyDeveloper toolsTenant isolation

Report · blog.cloudflare.com

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

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

blog.cloudflare.com

Source published October 26, 2026

Summary: 1 min read

🔥🔥🔥🔥🔥

56/100

Summary

Cloudflare remediated a tenant-isolation flaw in its Workers AI deployment of Z.ai’s GLM-5.3 model after security researcher Gadi Evron of Knostic reported it through HackerOne on September 8, 2026. From the model’s August 27 launch until September 9, 155 responses to prompts exceeding 681,280 tokens contained data from other customers’ recent requests to the same model. Cloudflare found no evidence of deliberate exploitation and said the affected request timing and volume matched ordinary long-context use. The flaw combined a Cloudflare configuration error with a bug in the SGLang inference engine’s disaggregated prefill/decode processing. GLM-5.3 accepted a 1,048,576-token context window, but its prefill KV-cache pool held only 681,280 tokens. For over-limit prompts, SGLang replaced the request with a one-token placeholder yet passed it to decode as completed; decode then read stale KV-cache pages left by earlier requests and could generate responses containing their data. Cloudflare made GLM-5.3 private on September 9, corrected the pool to about 2.04 million tokens, deployed an engine patch, and restored public access that day. It applied related hardening to all SGLang deployments. SGLang released fixes in versions 0.5.20 through 0.5.22; Cloudflare recommends operators of disaggregated SGLang deployments use v0.5.22 or later.

Key Takeaways

  • Cloudflare confirmed that only the GLM-5.3 model on Workers AI was affected by the cross-request KV-cache exposure.
  • All 155 affected responses were associated with prompts longer than 681,280 tokens, despite GLM-5.3 being configured to allow up to 1,048,576 tokens.
  • The exposure occurred because decode nodes used stale KV-cache pages after SGLang transferred only a one-token placeholder for a rejected oversized prompt.
  • Cloudflare increased the prefill KV-cache capacity to roughly 2.04 million tokens and patched SGLang’s rejection handling before restoring GLM-5.3 on September 9, 2026.
  • SGLang v0.5.22 includes fixes and hardening for this incident and related KV-cache transfer races.

What the discussion said

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.

Where opinion split

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.

Read original article

Coverage & discussions

Hacker News · blog.cloudflare.com

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

Community discussions

Hacker News discussion ↗

Reported comments: 47 · 12 saved in sample

Analysis ready

Community Sentiment

Negative

Positives

  • The postmortem earns rare trust by plainly tracing the leak to deployment capacity, cache handling, and missed tests instead of hand-waving around a security incident.
  • Swiftly taking the affected endpoint offline showed that the platform can halt unsafe AI serving before a long remediation cycle turns a leak into a prolonged exposure.
  • Calling out the precise affected inference endpoint gives API customers actionable scope, even if the underlying model was not responsible for the flaw.

Concerns

  • Cross-request KV-cache contamination is a serious tenant-isolation breach: another user’s prompts or generated context can surface in an unrelated AI request.
  • Advertising a million-token context while prefill cache held far less created a dangerous edge case the team already knew existed, then relied on the engine to reject safely.
  • Reports of inexplicably unrelated API responses make this failure mode feel broader than a theoretical exploit and undermine trust in shared LLM hosting.
  • Shared GPU inference exposes a hard truth for sensitive AI workloads: logical tenancy is only as strong as the cache and memory isolation beneath it.

Related Articles

AI meets Cryptography 1: What AI Found in Cloudflare's CIRCL

AI Meets Cryptography 1: What AI Found in Cloudflare's Circl

Jul 7, 2026

AI meets Cryptography 2: What AI Found in OpenVM's zkVM

AI Meets Cryptography 2: What AI Found in OpenVM's ZkVM

Jul 17, 2026

Incident Report: CVE-2026-LGTM

Incident CVE-2026-LGTM

Jun 26, 2026

The Hugging Face incident and the road ahead

The Hugging Face incident and the road ahead

Aug 26, 2026

Anatomy of a Frontier Lab Agent Intrusion: A Technical Timeline of the July 2026 Incident

Anatomy of a Frontier Lab Agent Intrusion: A Technical Timeline of the Incident

Jul 28, 2026