On 26 October 2026 Cloudflare published a detailed report on a bug in how one AI model was served on its Workers AI platform. It was found by security researcher Gadi Evron of Knostic, reported through Cloudflare's HackerOne programme, and disclosed jointly with the maintainers of SGLang, the open-source inference engine involved. The bug is specialised. The lesson in it isn't: it's about what your tests actually check.
What happened, in Cloudflare's words
The model was GLM 5.3, made by Z.ai and served by Cloudflare. Cloudflare deployed it with a 1,048,576-token context window, but the memory pool that holds each prompt's working state (the KV cache) on its prefill servers only had room for 681,280 tokens. Cloudflare says it knew about the mismatch before launch: "We expected the engine to return an error for any prompt it could not process, and our long-context tests returned successful responses, so we did not believe this to be an issue."
It didn't return an error. Because of a bug in SGLang's split prefill/decode mode, an over-length prompt was internally marked as rejected but never actually stopped. The decode step then generated a reply while reading memory pages that still held earlier requests' data. Cloudflare's summary of what the caller saw:
"The client got HTTP 200 instead of HTTP 400. prompt_tokens matched the long prompt and the reply was coherent. It arrived faster than an 8-page prefill should take, and it contained content from other users' KV pages."
Cloudflare is careful about the scope, and so should we be. It says "In total, 155 responses were affected, all to prompts longer than 681,280 tokens", between 27 August and 9 September, and "We have confirmed that no other model hosted on Workers AI was affected." It also says "We found no evidence of deliberate exploitation." After the report, Cloudflare took the model offline within 40 minutes of declaring an incident, fixed the configuration and the engine, and restored it the same day. SGLang has released fixes too, and Cloudflare recommends that anyone running it upgrade to v0.5.22 or later.
The line worth pinning to the wall
The most useful sentence in the report is Cloudflare's own self-criticism:
"This was one critical gap in our testing: we only validated HTTP response codes and engine performance at long contexts, without validating model output and coherence."
Look at the symptom again with that in mind. Status code: 200, a pass. Token count: correct, a pass. Response: fluent and coherent, a pass. Speed: faster than usual, which most test suites would count as a bonus. Every signal a typical integration test checks said "working". The only honest tell was that the answer came back faster than the work could physically have been done.
That is a success-shaped failure, and it's not limited to AI. A payment call that returns "OK" without charging anything. A search that returns quickly because it searched an empty index. A report that renders perfectly from yesterday's cached data. In each case the status is fine and the content is wrong.
What to assert instead
- Assert the content, not just the status. A 200 tells you the server answered, not that the answer is right. Check that the response contains what this specific request should produce.
- Use canary markers. Before restoring the model, Cloudflare validated its fixes with "canary-marker tests". The general idea is simple: put a unique marker in one request and assert that it never appears in anyone else's response. It turns "is data crossing between users?" into a yes/no test.
- Treat "too fast" as a failure signal. If a job normally takes four seconds and comes back in 200 milliseconds, that's worth an alert, not a celebration. A lower bound on latency is as meaningful as an upper bound.
- Test the edge you know about. Cloudflare knew the limits didn't match. A test that sent a prompt just over the smaller limit and asserted an error, or checked the reply, would most likely have caught it before launch.
- Don't assume a dependency will refuse what it can't handle. Cloudflare's advice to other operators ends: "Do not rely on a proxy to enforce the limit, and do not assume the engine will reject what does not fit. This is the check we did not enforce."
Credit where it's due: this is an unusually candid report, published with the researcher and the engine's maintainers, with the fixes upstream for everyone. The rest of us get the lesson for free. If your tests only check that something answered, they will pass on exactly the day it matters most.
Source: Cloudflare, "Cross-request KV cache exposure in the GLM-5.3 Workers AI model, and our remediation with SGLang" (published 26 October 2026, read 27 October 2026).