Cloudflare's GLM-5.3 Cache Bug Leaked One Request Into Another

The Bug Was Isolation, Not the Model

Cloudflare published a post-mortem on a cross-request KV cache exposure affecting GLM-5.3 on Workers AI. The short version: cached key-value state from one request could be visible to another. The model weights were fine. The plumbing around them wasn’t.

That distinction matters. When people hear “model bug” they assume bad outputs or a poisoned checkpoint. This was a shared-state problem — the same class of failure that bites anyone running inference behind a cache layer. The model itself kept doing exactly what it was trained to do; the machinery deciding which cached bytes to hand it did not.

It drew 155 responses on Hacker News, which is a lot for an infrastructure post. Builders recognized the shape of it. Threads about model quality tend to attract opinions; threads about shared state attract people who have already been burned by one.

What a KV Cache Actually Holds

KV caching stores attention keys and values so a model doesn’t recompute the whole context on every token. It’s the standard trick behind cheaper, faster inference. The cache is derived from the prompt — including whatever the user sent.

To see why that matters, it helps to know what those keys and values are. In a transformer, attention compares a query vector against key vectors to decide which earlier tokens matter, then blends the corresponding value vectors into the next step. Caching them means the expensive projection work happens once per prefix instead of once per token. The cached tensors are not abstract metadata; they are a compressed, mathematical residue of the actual input. Prompt text gets folded into them. Which is precisely why a misrouted cache entry is not a performance hiccup but a disclosure.

If cache entries are keyed or scoped loosely, a request can read state that belongs to someone else’s conversation. You don’t need a model leak for that. You need a cache lookup that returns the wrong entry. A prompt hash alone, for instance, may collide or may be reused across tenants; a key that omits the conversation identifier can serve a sibling session’s prefix; a cache shared across model versions can hand v5.3 the state built by an earlier checkpoint. None of these require anyone to write a bad model. They require a key that is one field short.

Cloudflare’s remediation is documented in the post. The important takeaway for builders is that cache isolation is a security boundary, not an optimization detail. The same property that makes prefix caching worth money — reuse across requests — is the property that makes it dangerous when the reuse boundary is drawn in the wrong place.

Why This Lands This Week

Most teams now run inference on shared platforms. You don’t own the GPU, the scheduler, or the cache. You own the prompt and the trust that the response came back scoped to you.

That trust is usually implicit. Nobody reads the cache-scoping section of a provider’s docs before shipping a prototype, because at prototype scale there is one tenant and the question never comes up. It comes up when traffic arrives, when the platform starts optimizing aggressively on your behalf, and when the thing being optimized is state derived from other people’s prompts.

A cache-isolation incident is concrete in a way benchmark charts aren’t. It tells you whether the platform’s multi-tenant story holds under real traffic. 155 comments is the builder class doing that math in public. Some of those comments will be about Cloudflare specifically; the more useful ones are about the general pattern, because every hosted inference product now sits on some variant of this architecture.

There is a fair counter-argument worth stating plainly: cross-request cache exposure is usually a narrow, transient leak rather than a standing archive. It surfaces fragments of a neighboring request’s context, not a full history, and it is fixed once the key is corrected. That is true, and it is why the right response is calibration rather than panic. But “narrow” is a property of the blast radius, not of the trust model. If your threat model assumes per-request isolation, any crossing of the boundary is a violation of the contract, however small the payload.

What to Check on Your Own Stack

• Ask your provider how KV cache entries are scoped per request, tenant, and model version.
• If you self-host a cache layer, verify the key includes tenant and conversation identifiers, not just a prompt hash.
• Test with two concurrent sessions carrying distinguishable prompts and confirm neither sees the other’s state.
• Treat cached state as untrusted input when it crosses a boundary.

None of this is exotic. It’s the same discipline as tool-result validation, applied to the inference layer. The concurrent-session test is worth doing even if you trust your provider, because it costs one afternoon and it converts an assumption into an observation. Make the two prompts distinctive enough that a leak would be obvious in the output rather than a subtle drift in tone.

For readers who are neither platform engineers nor security specialists, the practical translation is simpler: the isolation guarantee you are relying on is a written commitment somewhere, or it is a habit. Find out which. If it is a habit, treat cached state the way you treat any third-party data that enters your pipeline — as something to be checked before it is trusted.

The Trust Ledger

Cloudflare documented the exposure and the fix, which is the right move. The open question for anyone on Workers AI with GLM-5.3 is narrower: what does the cache scope guarantee look like in writing?

A cache bug doesn’t make a platform unusable. It makes the isolation contract worth reading before you ship. The distinction between a model failure and an isolation failure is the difference between “the answers are wrong” and “the answers are someone else’s” — and only one of those is fixed by swapping checkpoints.