Cloudflare's post-incident writeup frames the exposure as an infrastructure-layer defect: the prefix cache lookup hashed prompt tokens without mixing in the Workers AI account identifier, so two tenants with identical opening tokens could collide on the same cache slab. They scope the blast radius to 155 responses on GLM-5.3 during the window the bug was live, treating it as a bounded, remediated plumbing error rather than a model vulnerability.
The editorial argues that KV cache sharing across requests is one of the biggest performance wins in production LLM serving, which is exactly why it keeps producing cross-tenant leak classes that traditional web infra doesn't have. It frames the Cloudflare incident as a representative example of a broader, under-discussed problem class at the sharing boundary — where the same optimization that makes serving cheap is the one that erodes isolation if the cache key is wrong.
By submitting Cloudflare's writeup to Hacker News, wondersky surfaced the incident to a developer audience that reached 129 points and 42 comments. The traction signals that practitioners see cross-tenant KV cache exposure as a meaningful incident worth scrutinizing, not a routine postmortem.
On October 27, Cloudflare published a post-incident writeup for a cross-request data exposure in its Workers AI inference layer, specifically affecting the GLM-5.3 model. The company says 155 responses were impacted over the window the bug was live. The leak wasn't a prompt-injection stunt or a model behavior quirk — it was a plumbing bug. Content from one tenant's completion appeared verbatim inside another tenant's response because the two requests ended up sharing KV cache state that should have been isolated.
For non-infrastructure readers: when a transformer model generates text, it stores the attention keys and values for every token it has already processed in a per-sequence buffer called the KV cache. Without that cache, each new token would force the model to re-attend over the full prompt, which is catastrophically slow. Modern inference stacks go further and share KV state across requests when prompts share a prefix — the same system prompt, the same few-shot examples, the same tool schema. This is called prefix caching, and it's one of the biggest wins in production LLM serving: a 4K-token system prompt costs almost nothing to serve on the second request if the first one is still warm.
Cloudflare's bug sat exactly at that sharing boundary. According to the writeup, the prefix cache lookup used a hash of the prompt tokens as its key but did not mix in the Workers AI account identifier. Two different customers hitting GLM-5.3 with identical opening tokens — easy to do with a popular framework default or a boilerplate system prompt — could land on the same cache entry. In the worst case the second request didn't just inherit cached attention state; it inherited generated tokens that had been written into the same slab and were still live when the second request started decoding.
Multi-tenant inference is quietly one of the hardest security problems in the current AI stack, and nobody is talking about it the way they talked about VM isolation in 2010. The reason is structural. CPU-era isolation was built around address spaces, syscall boundaries, and hypervisors that had been hardened over decades. GPU-era inference is built around giant contiguous memory pools, batch schedulers that interleave requests from different customers in the same forward pass, and caching layers that are rewarded for sharing as much state as possible. Every performance optimization in a serving stack — continuous batching, paged attention, prefix caching, speculative decoding with a shared draft model — moves state closer to being shared and further from being isolated. The faster the stack gets, the harder the isolation story becomes.
Cloudflare is not an outlier here; they're the ones who got caught and wrote it up. vLLM, SGLang, TensorRT-LLM, and every hyperscaler's internal fork all implement some form of prefix caching, and all of them have to make the same choice: what goes into the cache key? If the answer is "a hash of the token IDs," you have Cloudflare's bug waiting to happen. If the answer is "token IDs plus tenant plus any PII-adjacent context," you lose a chunk of the cache hit rate that justified building the thing in the first place. There is a real, measurable tension between prefix-cache hit rate and tenant isolation, and most teams have not written down which side of that tradeoff they are on.
The HN thread on the disclosure (129 points, 155 responses — numbers that match the incident scope with uncomfortable symmetry) picked up on a second concern: detection. Cross-request leaks are nearly invisible from the customer side unless the leaked content happens to be surprising. If tenant A asks GLM-5.3 to summarize a meeting and tenant B asks it to summarize a different meeting, and B's output contains two sentences from A's meeting, B is overwhelmingly likely to assume the model hallucinated and move on. The only reliable signal is a canary — a request whose expected output is tightly constrained enough that any contamination stands out. Cloudflare says they found this one through internal review, which is more generous than most providers who typically find these bugs when a customer tweets a screenshot.
There's also a disclosure-quality angle worth noting. Cloudflare named the model, named the number of affected responses, described the mechanism, and did it inside a week. That's a sharply higher bar than most AI inference providers have cleared when similar things have happened, and it should become the floor rather than the ceiling. If your inference provider has never published a post-incident writeup, it is not because nothing has ever gone wrong — it is because they do not consider you entitled to know.
If you're building on Workers AI, Cloudflare's remediation closes this specific path and the practical blast radius is bounded — 155 responses, a specific model, a specific window. The honest action item is to decide whether your threat model tolerates serverless inference at all for anything containing customer PII, draft legal text, unreleased financial figures, or source code under NDA. If the answer is no, the mitigation isn't a config flag — it's dedicated inference, either single-tenant endpoints from your provider or self-hosted on your own GPUs. Both options cost dramatically more per token, and that cost is the actual price of isolation that shared inference was quietly deferring.
If you run your own inference, the lesson is more direct. Audit every cache in your serving path — prefix cache, prompt cache, embedding cache, retrieval cache, speculative-decode draft cache — and confirm that the lookup key includes a tenant or account identifier. The right place for that identifier is inside the hash input, not as a filter applied after lookup, because post-hoc filtering still leaves you with a correctness bug if the filter ever gets skipped under load. For teams on vLLM or SGLang, this means wrapping the engine's native prefix cache with your own keying layer or disabling cross-request sharing entirely for tenants above a sensitivity threshold.
For security-minded teams, this is also a case for adding synthetic canary traffic to your inference monitoring. A handful of requests per minute with cryptographically unique inputs and deterministic expected outputs would have caught this bug within hours of its introduction, not whenever the next internal review happened. The infrastructure to do this is cheap; the organizational will to actually look at the dashboard is the hard part.
Expect more of these incidents, not fewer. The economic pressure on inference providers to raise cache hit rates is only intensifying as model context windows grow and per-token margins compress, and every new sharing optimization is a new potential isolation bug. The industry has not yet standardized on anything like a "tenant-safe caching" spec, and until it does, every provider is reinventing the same hash-key design and getting bitten by the same class of error. Cloudflare's writeup is a useful datapoint; the next step is for the vLLM and SGLang maintainers, who together serve a startling fraction of production LLM inference, to codify tenant scoping as a first-class API rather than a thing each operator bolts on and hopes they got right.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.