On 26 October, Cloudflare and the SGLang maintainers published coordinated reports on the same cross-request KV cache leak. Cloudflare’s names the model, the dates and the count: 155 affected responses on @cf/zai-org/glm-5.3, between 27 August and 9 September, all to prompts longer than 681,280 tokens (Cloudflare’s report). It never says how long the surrounding class of bugs had been reachable in a default deployment. The SGLang post does, in one clause, about a related race: “default configurations were affected from the v0.4.x line (early 2025), when PD disaggregation shipped with RDMA backends, until v0.5.21”.
That is the pattern worth reading these two documents for. Both are unusually candid. Neither is complete on its own, and the facts an operator needs to decide whether to act are split between them along a line that tracks who each document was written for.
The five questions, and which document answers them
Was I affected? Cloudflare only. It scopes the incident to one model and states that “no other model hosted on Workers AI was affected”, with the mechanism that makes that credible: “every other disaggregated deployment on Workers AI has KV pools larger than its context length on both prefill and decode, so no request could reach the rejection path.” SGLang’s post declines to restate the customer scope and points back at Cloudflare’s for it.
How did it happen? Both, at different altitudes. Cloudflare’s account is the specific one: it ran GLM 5.3 with a 1,048,576-token context window while the prefill KV pool held 681,280 tokens, a rejected over-length prompt was swapped for a one-token placeholder, and the placeholder’s cache was handed to a decode node that had already reserved pages for the full prompt. Decode then read eight pages of which this request had written one. SGLang’s post generalises it into a rule — “A slot is safe to reuse only when no remote writer can still touch it” — and names the class: “Each one is a distributed use-after-free, where the dangling pointer is a write request sitting in a NIC queue on another machine.”
How long was I exposed? SGLang only, and only for the aborted-transfer race rather than the rejection path Cloudflare hit. That is the v0.4.x-to-v0.5.21 clause above. Read conservatively it is still roughly twenty months in which a default PD deployment on an RDMA backend carried a silent cross-request corruption path. Cloudflare says it had been “working to address” this class “for several months” and lists its earlier contributions, but publishes no window.
Can I check whether it already happened to me? SGLang only, and the answer is no: “A deployer has no reliable way to tell, because the corruption leaves no error or log line.” Cloudflare’s post implies the same by describing a response that arrived with HTTP 200 and matching prompt_tokens, but it never puts the question to a reader running their own cluster.
What do I do now? Both, and here they disagree slightly in a way that matters. Cloudflare recommends v0.5.22 or later. SGLang recommends the same baseline and then adds that MORI deployments need a build at or past the merge of #37077, and that “in practice, cut the build past #41128”.
The gap neither document closes
SGLang’s own appendix lists one fix as still outside every released build: #45973, which stops a failed NIXL or MORI send from acknowledging itself as drained, “ships in v0.5.23”. I checked the GitHub API rather than the prose: #45973 merged on 23 October, and the most recent tagged release is v0.5.22, published 19 October. So v0.5.23 does not exist yet, and an operator who follows Cloudflare’s recommendation to “update SGLang dependencies to v0.5.22 or later” to the letter on a NIXL or MORI backend is running the current best release with that path still open. Both documents contain the pieces of this. Neither assembles it, because neither is wrong about anything it says.
The same is true of the page-zeroing proposal. Cloudflare lists “Zero KV pages on release, draft proposal: #46435” under works in progress (#46435). As of today the API reports that pull request still open and unmerged. Pages are, in Cloudflare’s own words, “not currently zeroed between requests”.
Where each document is more honest than it had to be
Cloudflare’s post is the more self-incriminating of the two, and the admissions are not generic. It states that it knew about the size mismatch before launch — “We were aware of this mismatch before launch” — and names the testing gap in its own voice: “we only validated HTTP response codes and engine performance at long contexts, without validating model output and coherence.” On whose job the check was, it does not hedge: “Nothing forces the two to agree, and it is our job to check that they do.” It also volunteers that the bug had already been filed upstream in July by someone else, as issue #30233, which Cloudflare found only while investigating its own incident. The GitHub API dates that issue to 6 July 2026 and the upstream fix #36988 to a merge on 6 September, three days before Cloudflare declared its incident and, as Cloudflare says, “not yet released”.
It goes further than any of that in a passage no reader would have been able to find. The long-term answer Cloudflare proposes — per-page ownership tags checked at read time — was built as a prototype over the summer, tested on GLM 5.2 in mid-August, and then, in its own sentence, “disabled it shortly afterwards due to reliability issues”. A company writing a breach report has no incentive to disclose that its own preventative control had been switched off weeks before the breach.
And Cloudflare declines the easy exit of blaming the dependency. It takes the configuration half, patches the engine half itself, and frames the remaining work as inevitable: “this incident is a reminder that the next bug will have a shape we have not seen.”
SGLang’s candour runs the other way, toward the uncomfortable general case. Its post is where you learn that the corruption is reproducible on demand once the window is held open, that “a client can raise the odds on purpose by sending long-context requests and disconnecting mid-transfer”, and that the attacker gets nothing back — “The realistic impact is therefore one-way cross-request leakage”, which it then declines to downplay: “in multi-tenant serving this is a data-leakage concern as well as an integrity one.” It also states plainly that the fix line was not backported: “We have not backported this fix line to earlier release branches.”
What I could not check
I did not verify the 155-response count, the no-deliberate-exploitation finding, or any item on Cloudflare’s incident timeline; all of those rest on internal telemetry no outsider can reach, and this article reports them as Cloudflare’s claims. The same goes for SGLang’s performance measurements — 21 runs on 2×H100 with “All deltas were within ±2%, and every 95% confidence interval spanned zero” — which I read but did not reproduce. What I did check independently was the release and merge state of every pull request the argument above turns on, through the GitHub API, because that is the half of the story the prose on both pages leaves a day behind.
The useful conclusion is not that one of these publishers is spinning. It is that a vendor’s incident report answers whether this touched your data, and an engine’s security post answers how long your own cluster was like this, and if you run SGLang yourself, the second question is the one with the twenty-month answer.