For: teams that send business data to hosted AI APIs (Workers AI or any other), and people who run their own LLM inference servers. This article is based on Cloudflare's official post and does not cover how to trigger the flaw.
Developing: this article will be updated as the organisation publishes more
As of October 31, 2026Not yet known
- Number of customers affected
- What kinds of data appeared in the 155 responses
- Whether and how individual customers were notified
Cloudflare published this account as a coordinated disclosure with the team behind the open-source inference engine. It describes further hardening work as in progress (page-level integrity checks and formal verification of its transfer protocol). We re-checked the post on October 31 and found no later notice.
What teams using hosted AI should check today
Find out whether you were in scope
Per Cloudflare, only the GLM 5.3 model was affected, only between August 27 and September 9, 2026, and only for prompts longer than 681,280 tokens. Search your own logs or billing for calls to that model in that window and note the prompt sizes. In this site's view, prompts that long are unusual, so many teams will find none.
Look for a notice from the vendor, and keep your own record
Cloudflare's post does not describe steps for customers or say how individual customers were told. Check the email contacts and dashboard notices on your account, and ask your account team if you believe you were in scope. Keep a record of what was sent to the model and when, because that is what you will need to judge the impact.
Inventory what goes into each AI service
Write down, per service, what kinds of data your staff and applications send (customer records, source code, credentials, contracts). Where the answer includes data you could not afford to see exposed, remove it from the prompt, mask it, or use a deployment that is isolated for you. Do not paste secrets such as API keys into prompts at all (why keys leak through AI tools).
Treat anything a model returns as possibly not yours
The reported symptom was a response containing text that belonged to someone else. If a hosted model ever returns text that looks unrelated to your prompt, such as another company's names or code, stop using that output, save the evidence, and report it to the vendor through its security channel.
If you run your own inference servers, apply the engine checks
Cloudflare recommends that operators of the same engine measure the cache pool on every node and compare it with the model's context length after any change to weights, quantization, parallelism or memory settings; upgrade to engine version 0.5.22 or later; enable the corruption-detection options where the model supports them; and configure load balancers to avoid aborts before the first token. Read the post itself for the exact settings.
What happened (per Cloudflare)
The following is based on Cloudflare's post of October 26, 2026. Times are UTC as given in the post.
August 27, 2026
GLM 5.3 became available on Workers AI. Cloudflare says its cache pool was smaller than the model's context length, a mismatch it knew about before launch.September 8, 23:11
A report arrived through Cloudflare's bug bounty program.September 9, 13:22
Cloudflare declared a security incident. Per the post, its product security team reproduced the leak with two independent accounts within 25 minutes.September 9, 14:00
The model was made private (requests returned an error).September 9, 14:35–19:04
Root cause identified, prefill nodes moved to a corrected configuration, then the full deployment rebuilt with an engine patch and validated.September 9, 19:40
The model was made public again.September 16 – October 19
Upstream fixes merged and released in the open-source engine, including version 0.5.22 on October 19.October 26
Cloudflare published its account.
- Service and model
- Workers AI, GLM 5.3 (a text-generation model from a third-party developer)
- What was exposed
- Data from other customers' requests to the same model made shortly before the affected request
- Who could see it
- Customers whose over-length prompts received the affected responses
- Cause, part 1
- The cache pool held 681,280 tokens while the context length is 1,048,576 tokens
- Cause, part 2
- A bug in the open-source inference engine: an over-length request was admitted instead of rejected, and the response drew on cache pages that still held earlier requests' data
- Exploitation
- After excluding Cloudflare's testing and the researcher's, the requests matched ordinary long-context use in timing and volume; no evidence of deliberate exploitation
- Fix
- Configuration aligned with the previous model version (pool now about 2.04 million tokens), engine patch rejecting such requests at admission, and a check of pool size against context length before deployment changes
What is known and what is not
Status as of October 31, 2026.
| Item | What Cloudflare says | Status |
|---|---|---|
| Period | August 27 to September 9, 2026 | Confirmed (Cloudflare) |
| Affected model | GLM 5.3 only; no other Workers AI model | Confirmed (Cloudflare) |
| Affected responses | 155, all for prompts above 681,280 tokens | Confirmed (Cloudflare) |
| Number of customers | "A small number of customers" | Not disclosed |
| Content of exposed data | Other customers' recent requests | Type and sensitivity not disclosed |
| Deliberate exploitation | No evidence found | Cloudflare's finding |
| Individual notification | Not described in the post | Not disclosed |
| Fix | Deployed September 9; upstream fixes released later | Confirmed (Cloudflare) |
Why sharing the same cache can leak between customers
Hosted language models serve many customers on the same hardware, and keep a working memory (a cache) of the text being processed to answer faster. In general, if that memory is reused without being cleared, or is read in a size different from what was written, one customer's text can appear in another's output. This is a general explanation of the class of problem, not extra detail about this incident.
Two things stand out in Cloudflare's own account. The mismatch between cache size and context length was known before launch, and its pre-launch tests checked status codes and streaming rather than whether the output made sense. Cloudflare says it now checks the cache pool against the context length from the running engine before each deployment change. For customers, the lesson is that "the request succeeded" does not tell you the response is yours.
For teams that operate AI services: one check from this account
If you serve a model to more than one customer or team, add a test that sends over-length and boundary-size inputs and checks that the result is an error, not a successful answer. Also verify, after any change to model weights, quantization or memory settings, that the cache is still large enough for the advertised context length. Both come directly from the causes Cloudflare describes.
Cache pool 681,280 tokens, context length 1,048,576
↓→
Is the cache at least as large as the advertised context length?
Over-length request admitted, not rejected
↓→
Does an over-length test input return an error?
Tests checked status codes, not output
↓→
Do tests check that the output belongs to the request?
Sources (public record)
- Cloudflare blog, post on the cross-request KV cache exposure in a Workers AI model and its remediation (October 26, 2026) — blog.cloudflare.com
Update history
2026-10-31: First version, based on Cloudflare's post of October 26. We will update this article if Cloudflare or the engine's maintainers publish more.
Read next
- AI and attackers: An AI agent breaking into a system on its own
- Protecting keys and secrets: How API keys leak through AI tools
- Other 2026 incidents: Data breaches and cyberattacks in 2026