Service eligibility and regional restrictions
PuppyIP serves only compliant overseas businesses and their authorized personnel. Proxy services are not available in mainland China. The service may only be used for lawful business activities outside mainland China. Use of this service within mainland China is prohibited.
Hosting a proxy IP or server overseas does not change these restrictions. The service must not be provided to end users in mainland China through relaying, forwarding, sharing or resale. Before use, read the Terms of Service.
Key Takeaways
- Cloudflare limited the impact to GLM-5.3 on Workers AI between August 27 and September 9, 2026; the model was restored after remediation on September 9.
- Cloudflare reported 155 affected responses, all to prompts longer than 681,280 tokens. This is not a count of 155 customers, and it does not mean every long prompt exposed data.
- Two conditions combined: the context window was 1,048,576 tokens while the prefill KV pool held 681,280; a placeholder handoff for an over-length prompt then let the decode side read stale cache pages.
- Cloudflare recommends that SGLang operators upgrade to v0.5.22 or later. Checksum and KV canary checks still did not cover every model architecture, so verify actual logs.
Scope first: GLM-5.3 only, and the issue was remediated
In its October 26, 2026 disclosure, Cloudflare said GLM-5.3 on Workers AI had a cross-request KV cache isolation issue from its launch on August 27. Cloudflare fixed the configuration and inference engine, then restored the model on September 9.
Cloudflare reported 155 affected responses, all to prompts longer than 681,280 tokens. It said it found no evidence of deliberate exploitation and confirmed that no other Workers AI model was affected. “155 responses” is not a count of affected customers, and it does not mean every over-length prompt exposed data.
How could the cache contain data from an earlier request?
A KV cache stores intermediate state produced while a model processes a prompt, so the model can reuse it while generating tokens. Cloudflare configured a 1,048,576-token context window for GLM-5.3, but the KV cache pool on its prefill GPUs could hold only 681,280 tokens.
The second issue was in SGLang’s disaggregated prefill/decode flow. An over-length prompt was marked rejected internally but replaced with a one-token placeholder and continued. Prefill handed that placeholder cache to decode and reported the transfer complete, although most old state had not been overwritten. Decode then generated on the assumption that the new prompt was fully present, and could read cache pages left by an earlier request.
What did Cloudflare change, and what should SGLang operators check?
Cloudflare first disabled the model, expanded the KV pool to hold the full context, and patched the request-rejection handoff before restoring service on September 9. Cloudflare said the issue patch shipped in SGLang v0.5.20, with follow-up fixes in v0.5.21 and v0.5.22. Its report strongly recommends that operators upgrade to v0.5.22 or later.
The report also recommends checking that prefill and decode cache pools match the context length, rejecting unsupported requests before cross-node handoff, enabling deferred KV-page release on both roles, and bounding Mooncake transfer batches. Where the model supports KV checksums or canary checks, confirm from logs that they actually cover the requests in use.
Which protections still do not cover every model?
Cloudflare said <code>--disaggregation-enable-kv-checksum</code> and <code>--kv-canary</code> did not yet cover every model architecture at the time of its report. It was working with the SGLang team to extend support to architectures including GLM-5.3, GLM-5.3-Flash, and DeepSeek V4. Setting a flag therefore does not prove that every model receives the same cache-integrity checks.
Cloudflare recommended v0.5.22 or later and said over-length requests should be rejected before handoff. That is the report’s version guidance, not a security guarantee for every SGLang deployment. Check the model architecture, configuration, and logs in your own environment.
Do not combine this with a separate Workers AI error incident
This disclosure concerns request isolation and cache lifecycle in GLM-5.3; it is not a report that all Workers AI models had inference errors. PuppyIP has a separate October 15 inference-error incident guide based on a different Cloudflare status-page event and a different set of models.
Cloudflare said this GLM-5.3 issue was fixed and the model restored. The October 26 report is retrospective, not evidence of a current incident. Operators assessing their own requests or model architecture should compare the actual model ID, date range, prompt length, and service logs rather than infer impact from another event or a similar model name.
What remains unknown to readers?
Cloudflare published the number of affected responses and the prompt-length threshold, but did not name affected customers in this report. Its statement that it found no evidence of deliberate exploitation does not prove that malicious activity never occurred at any time.
To assess an SGLang deployment, use the published version and configuration guidance, then check which integrity tests the architecture actually supports. A completed upgrade, configured flag, or successful response alone does not verify every cache handoff.
Sources
Frequently Asked Questions
Did this affect every Workers AI model?
No. Cloudflare said the affected model was GLM-5.3 on Workers AI and confirmed that no other Workers AI model was affected. Do not extend that scope to other platforms or similarly named models.
Were 155 users affected?
Cloudflare reported 155 affected responses, all to prompts longer than 681,280 tokens. It did not describe this as a count of customers or users.
Which SGLang version should operators use?
In its October 26, 2026 report, Cloudflare strongly recommended v0.5.22 or later. It also said checksum and KV canary checks did not cover every model architecture, so check logs and confirm which checks the current architecture supports.
Does Cloudflare restoring GLM-5.3 prove my own deployment is safe?
No. Cloudflare said it fixed and restored GLM-5.3 on September 9. Other operators still need to verify their SGLang version, context and KV-pool configuration, rejected-request flow, and supported integrity-check logs.