---
id: "lib-2026-10-26-cross-request-kv-cache-exposure-in-the-glm-5-3"
type: "library"
title: "Cross-request KV cache exposure in the GLM-5.3 Workers AI model, and our remediation with SGLang"
lang: "EN"
org: "Cloudflare"
source_type: "Report"
date: "2026-10-26"
week: "2026-W44"
url: "https://nosov.ai/library/lib-2026-10-26-cross-request-kv-cache-exposure-in-the-glm-5-3/"
original_url: "https://blog.cloudflare.com/kv-cache-exposure-remediation/"
tier: "A"
tier_name: "Strong evidence"
tier_reason: "A first-party incident report from Cloudflare engineers with root cause, minute-level timeline, affected-response count and the upstream SGLang fixes by pull request number; self-reported, but specific and checkable against the public code."
summary_basis: "full-text"
original_minutes: "16"
tags: ["ai technology", "future of work", "enablement", "business transformation", "inference serving", "data exposure", "incident"]
---

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

Tier A (Strong evidence): A first-party incident report from Cloudflare engineers with root cause, minute-level timeline, affected-response count and the upstream SGLang fixes by pull request number; self-reported, but specific and checkable against the public code.

Summary based on the full text.

## In short

A Cloudflare blog post (26 October 2026) by Kevin Flansburg and Michelle Chen, published as a coordinated disclosure with the SGLang project. For 13 days, very long prompts sent to the GLM-5.3 model on Workers AI could return text from other customers' recent requests. Two problems combined: Cloudflare deployed the model with a context window larger than the GPU cache pool could hold, and SGLang, in split prefill/decode mode, passed rejected over-length requests to the decode node as if they were valid. Decode then generated from stale cache pages that still held other users' data and returned HTTP 200.

## Key numbers

- 155: responses that could contain data from other customers' requests, all to prompts longer than 681,280 tokens
- 681,280 vs 1,048,576: tokens the prefill KV cache pool could hold against the advertised context window
- August 27 to September 9: exposure window, from model launch to restoration with fixes
- 40 minutes: time to take the model offline after declaring an incident
- v0.5.22: SGLang version operators should run or exceed to get the engine fixes

## What it reports

- A security researcher reported the issue through HackerOne on 8 September; Cloudflare reproduced it with two accounts within 25 minutes of declaring an incident on 9 September, set the model private, and restored it the same evening.
- 155 responses were affected; after excluding test traffic, the requests matched ordinary long-context use, with no evidence of deliberate exploitation.
- Cloudflare knew of the pool-size mismatch before launch but assumed the engine would reject what did not fit; its tests checked status codes and performance, not output content.
- The fixed configuration gives a prefill pool of about 2.04 million tokens, roughly twice the context length.
- The SGLang bug had been reported by another user as issue #30233 on 6 July 2026. Fixes landed across v0.5.20 to v0.5.22, plus KV checksums and deferred page release.
- Only GLM 5.3 was affected; other disaggregated deployments had pools larger than their context length.
- A page-tagging prototype that blocks reads of pages a request does not own cost under 1% throughput in tests but was disabled for reliability issues.

## How they got it

Incident response logs, reproduction with the researcher's script and canary-marker tests, and code review of the SGLang admission and transfer paths. The post lists each upstream pull request and the release that carries it.

## Limits

- Self-reported by the operator; the affected-response count and the no-exploitation finding cannot be checked externally.
- The bug class (KV page lifetime and cross-node races) is ongoing, and some fixes are still in progress.
- Corruption checks do not yet cover every model architecture, including GLM 5.3.

## Why it matters for companies

Hosted inference shares GPU memory between tenants, and this shows how one configuration gap plus one engine bug turns that into a data leak with no error raised. Firms sending sensitive prompts to hosted open-weight models should ask providers how they enforce tenant isolation in the KV cache, whether they test output content at the context limit, and how fast they patch the inference engine. Teams running SGLang themselves should compare pool size with context length on every node and upgrade to v0.5.22 or later.

Original: https://blog.cloudflare.com/kv-cache-exposure-remediation/