155 Leaked Responses: Inside Cloudflare’s GLM-5.3 KV-Cache Bug

Twenty-five minutes. That’s how long Cloudflare’s own security team needed to reproduce the bug once they knew where to look, according to the incident report the company published on October 26. Forty minutes after that, GLM-5.3 was pulled offline on Workers AI, by Cloudflare’s own hand, before anyone forced them to.

The root cause comes down to two numbers that never should have disagreed: a 1,048,576-token context window advertised to anyone calling GLM-5.3, and a KV cache pool actually built to hold 681,280 tokens of attention state. Cloudflare runs GLM-5.3 in SGLang’s disaggregated serving mode, where one set of machines handles prefill and hands off to a separate set of machines running decode, so each stage can scale independently under load. On paper, the model promises over a million tokens of context. In the cache that actually backs it, there was room for about two-thirds of that.

A prompt asking for more than the pool could hold was supposed to get rejected outright. Instead, a bug in that disaggregated path replaced the rejected prompt’s tokens with a single placeholder token and let the request keep moving through the pipeline anyway. The “transfer complete” handoff signal from the prefill node to the decode node fired regardless of whether real attention state had actually been transferred. Sometimes what landed in a decode node’s cache slot wasn’t the placeholder at all. It was whatever KV data happened to already be sitting in that slot from a previous request, from a different customer.

Thirteen days, 155 responses

Cloudflare traced the exposure window to thirteen days, August 27 through September 9, and counted 155 completions where fragments of another user’s cached attention state surfaced inside someone else’s response. Out of everything Workers AI served in that stretch, 155 is a small number. It’s not zero, and it only happened on GLM-5.3 — every other model on the platform had a KV pool sized correctly for its own advertised context, so this specific failure needed both the sizing mismatch and the disaggregated-mode defect to show up at the same time.

Cloudflare says its own investigation found no sign that anyone discovered and deliberately exploited the gap before the HackerOne report that triggered the whole response. Gadi Evron, a researcher at Knostic, is credited with that report. I’d take “no evidence of deliberate exploitation” for exactly what it says and nothing more. It’s an absence of evidence in logs that weren’t built to catch this specific failure mode, not a guarantee that nobody ever noticed a stray fragment of someone else’s conversation and simply said nothing.

The fix is boring, which is the point

Cloudflare’s remediation has two parts, and neither one is clever. First, they resized the KV pool backing GLM-5.3 to roughly 2.04 million tokens, matching the configuration already running under GLM-5.2, so the advertised context and the actual cache capacity agree with each other again. Second, they patched SGLang so a rejected request gets retired at the admission queue, before any KV transfer handoff happens, instead of limping through the pipeline with a placeholder token standing in for data that was never actually there.

On top of that, they added integrity-checking logic that catches a wrong-tenant KV transfer directly, independent of whether the admission-queue fix catches the request first. Belt and suspenders. The performance cost of that extra check came in under 1% in their own testing — a number worth keeping on hand the next time someone argues a safety check isn’t worth the latency it costs.

What this means if you run inference infrastructure

If you operate a multi-tenant inference service, and especially if any part of it runs a disaggregated prefill/decode configuration, the lesson isn’t just “go audit your KV cache sizing,” though you should do that too. It’s that a context-window number you advertise to users and a cache-capacity number configured on your actual hardware are two separate numbers living in two separate parts of your stack, and nothing forces them to stay in sync unless someone writes the check that enforces it. GLM-5.2’s settings happened to have this right. GLM-5.3’s didn’t, for thirteen days, until an outside researcher found it first.

It’s also worth noticing what didn’t fail here: Cloudflare’s response time once the report landed. Twenty-five minutes to reproduce a cross-tenant data leak in a production inference service is fast by any standard, and forty minutes to pull the affected model offline is the kind of number that only happens when the incident-response path has actually been rehearsed, not just documented somewhere.

Cloudflare moved fast once they knew. Twenty-five minutes to reproduce, forty to pull the model. The thirteen days before that is the part of the timeline nobody gets to patch retroactively.

Sources

Cloudflare: KV cache exposure and remediation (primary incident report, retrieved October 28, 2026).