# An AI reply can succeed and still contain the wrong customer's data. Cloudflare's 26 October disclosure shows why an HTTP success code is not enough to validate a shared inference service. Here is the release checklist it changes. Published: 2026-10-31 | Updated: 2026-10-31 Author: /init editorial Method: AI-assisted, source-checked Canonical: https://init.news/notes/kv-cache-isolation-release-checks/ For: AI builders operating shared inference, technical founders selecting a provider, and owners asking a supplier how customer data stays separated. Question: Cloudflare SGLang KV cache exposure isolation checks ## The answer Treat request isolation as a release requirement, separate from uptime and throughput. Cloudflare's 26 October 2026 report describes a remediated GLM-5.3 Workers AI incident in which an oversized prompt rejection did not stop a prefill/decode handoff, allowing stale KV state into responses. Its report recommends SGLang v0.5.22 or later for relevant operators. Verify your exact configuration, patch coverage, rejection behavior and page-lifetime handling before relying on shared serving for sensitive work. ## What you will leave with A narrowly scoped incident explanation, an operator acceptance checklist and concrete questions a non-operator can ask their inference supplier. - A successful HTTP response does not prove request isolation. - Check the running cache capacity and failure paths, not only the advertised context window. - Use synthetic data in authorized isolation tests and keep incident scope precise. ## The disclosure is new. The incident was earlier. Cloudflare published its coordinated disclosure on 26 October, after an incident affecting GLM-5.3 on Workers AI from 27 August to 9 September. It reports 155 affected responses, all for prompts longer than 681,280 tokens, and says no other Workers AI model was affected. It restored the model on 9 September after remediation. [1] Those are Cloudflare's reported scope and findings. This note is not a new incident discovery, an independent forensic assessment or a claim that every shared model server has the same flaw. ## Where the contract broke Cloudflare describes two interacting problems: a prefill KV pool smaller than the advertised context window, and an SGLang rejection path that did not safely stop the disaggregated handoff. Decode could attend to cache pages that the current request had not overwritten. A normal-looking response could therefore conceal a data-isolation failure. [1] Its pre-launch checks had relied on response status and performance rather than validating the content returned at long contexts. That is the transferable lesson: transport success, answer correctness and isolation are three separate checks. [1] ## What to ask before the next release Release question | Evidence to request --- | --- Does the running pool fit accepted requests? | Measured capacity and configured context limits from the actual serving process. Does rejection stop both sides? | An authorized test that returns the intended error before unsafe allocation or transfer. Can cancellation leave writes in flight? | The documented lifetime/release contract and relevant patch coverage. Can one request receive another's state? | Synthetic isolation checks covering long prompts, interruptions and reuse. Can the deployment be reversed? | Named owner, version record and tested rollback procedure. Cloudflare's report details configuration correction, earlier rejection, deferred release and transfer hardening. It recommends updating relevant SGLang deployments to v0.5.22 or later, or backporting the needed changes. Read its patch table rather than treating a version string alone as proof that your topology and configuration are safe. [1] ## For owners who buy inference rather than run it You do not need to debug GPU memory. You do need a supplier who can identify the service you use, explain whether the disclosed configuration applies and provide a concrete remediation statement where relevant. - Name the exact service and model, not just the vendor. - Ask whether the incident's affected period or configuration intersects your usage. - Ask what changed and what release checks now enforce isolation. - Use the supplier's established security channel for account-specific questions; do not publish customer prompts in a support thread. - Keep sensitive workloads within your approved handling policy while an applicability question remains unresolved. ## Do not test this with customer secrets Any proposed validation should use synthetic markers in an environment you are authorized to test. This article does not provide an exploitation recipe, and no cross-account or production test was performed for it. A small successful test would still not prove the absence of every isolation defect. Start with the report's What happened, Immediate remediation and Working with the SGLang team sections. The next decision is whether the evidence for your serving path is sufficient, not whether a different model can produce a faster demo. ## Try one thing Ask the serving owner for the exact engine version, prefill/decode topology and evidence that rejected or interrupted requests cannot transfer stale state into another request. Record an unknown answer as an open release requirement. ## Sources [1] [Cloudflare: Cross-request KV cache exposure and remediation with SGLang, 26 October 2026](https://blog.cloudflare.com/kv-cache-exposure-remediation/): First-party incident dates, affected scope, failure mechanism, remediation, validation gap and version/patch recommendations; page modified 27 October.; checked 2026-10-31 ## Related guides - https://init.news/notes/agent-handoff-receipts/ - https://init.news/notes/apple-silicon-inference-evaluation/ - https://init.news/notes/engineering-claim-freshness-ledger/