Skip to main content

KVGuard: Catching the KV cache bug behind Cloudflare's GLM leak

· 2 min read
Jonguk Cheong
Jonguk Cheong
PhD Student, CompSec Lab @ SNU

In October 2026, Cloudflare disclosed that 155 responses from its GLM-5.3 model on Workers AI leaked pieces of other users' prompts and outputs. Nothing crashed, nothing was logged, and every response returned HTTP 200 (OK). The model was not at fault: the serving engine, SGLang, let a request read KV cache memory it never wrote.

We built KVGuard, a KV cache sanitizer for LLM serving systems. It catches this exact bug, and every other code path that ends in the same bad read.

KVGuard catches the uninitialized KV cache read behind the Cloudflare GLM leak

Serving engines keep the KV cache in one shared GPU buffer that is reused across users and never zeroed, so they inherit the classic memory-safety bugs, including this uninitialized read. KVGuard keeps a small shadow record for every KV block, tracking which request owns it and which entries were actually written, and checks every read in the attention kernel. We reproduced the incident on SGLang 0.5.19: KVGuard reported 4,095 uninitialized reads on the leaking request, while normal traffic stayed silent.

The demo below reproduces the leak and shows KVGuard catching it.

A victim and an attacker share one SGLang service: the attacker's over-length request is answered with the victim's leftover data (name, recovery code, PIN, address), while the KVGuard panel reports 4,095 uninitialized KV reads on that request.

Watch the MP4 for a sharper version.

For the full story and the design, see: