NEWS 7 min read

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

A cross-request KV cache exposure hit GLM-5.3 on Workers AI, drawing 155 Hacker News responses. Here's what leaked, how it was fixed, and what builders should check.

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

The Bug Was Isolation, Not the Model

Official image for Cloudflare's GLM-5.3 Cache Bug Leaked One Request Into Another
Official image via www.cloudflare.com — source checked 2026-10-27.

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.

It drew 155 responses on Hacker News, which is a lot for an infrastructure post. Builders recognized the shape of it.

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.

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.

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.

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.

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.

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 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.

Share this article

> Want more like this?

Get the best AI insights delivered weekly.

By subscribing, you agree to our Privacy Policy. You can unsubscribe at any time.

> Related Articles