Other customers' data appeared in 155 GLM-5.3 responses
Cloudflare said on October 26, 2026, that request data from other customers showed up in 155 replies from GLM-5.3 on Workers AI, its service for running AI models on its own servers. Between August 27 and September 9, some customers got replies that included input another customer had sent to the same model shortly before. Cloudflare says no other Workers AI model was affected.
GLM-5.3 is a text generation model from Z.ai built for agentic coding (see GLM 5.3 benchmarks, pricing, and open weights). Leaving out its own tests and the researcher's, Cloudflare says the affected requests matched ordinary long-context use in timing and volume. It found no evidence of deliberate exploitation.
Only prompts longer than 681,280 tokens were affected
All 155 affected responses were replies to prompts longer than 681,280 tokens. A token is the unit an AI model uses to count text, and the context window is how much text a model can take in at once. Cloudflare launched GLM-5.3 with a context window of 1,048,576 tokens, so prompts above 681,280 tokens were accepted.
GLM-5.3 went live on Workers AI on August 27. According to Cloudflare, the leak existed from that launch day on.
"In total, 155 responses were affected, all to prompts longer than 681,280 tokens." ／ "We found no evidence of deliberate exploitation." — from the opening summaryView official source →
Leaked content included names and invoice numbers
Knostic, the security firm whose researcher reported the bug, lists the kinds of data it saw in responses during testing. These included:
- personal names, and client and company names
- invoice numbers, amounts in euros and payment dates
- source code details and file paths
- records of AI agent tasks
Cloudflare's report does not describe what the leaked data contained. Knostic says reproducing the leak took only an ordinary paid Workers AI account, its own API key and a network connection, with no victim credentials, special access or action by the victim.
Knostic first noticed the odd output on September 7 while using GLM-5.3 through OpenRouter, a service that routes requests to many AI providers. It traced the provider to Cloudflare and then continued testing on its own Workers AI account.
"Personal names" ／ "Client and company names" ／ "Invoice numbers" — from The observed leaksView official source →
A config mismatch and an SGLang bug combined
Cloudflare says the leak came from two problems at once: a configuration mistake on its side and a bug in SGLang. SGLang is an open-source inference engine, the software that runs an AI model and produces its replies.
Cloudflare ran GLM-5.3 with prefill, which reads the prompt, and decode, which writes the reply, on separate servers. The KV cache is where a model keeps its working results after reading a prompt, and prefill hands it to decode.
The mismatch was between the context window and the size of that cache. GLM-5.3 accepted 1,048,576 tokens, but the KV cache pool on the prefill side could hold only 681,280 tokens.
Cloudflare knew about the gap before launch. It expected the engine to return an error for any prompt it could not process, and its long-context tests came back successful. Those tests checked status codes and speed, not what the model actually wrote.
"We were aware of this 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." — from What happenedView official source →
SGLang kept processing prompts that did not fit
When a prompt was too large for the pool, SGLang marked it as rejected and swapped it for a one-token placeholder. Instead of stopping there with an error, prefill built a KV cache for the placeholder alone and sent it on to decode.
Decode got a "transfer complete" signal and assumed the earlier request's data had been overwritten. In fact only the placeholder's share had changed, and most of the old data was still there.
KV cache pages are not wiped between requests; the next request simply writes over them, which Cloudflare says is common among inference engines. Decode read those stale pages to build its reply, so another customer's data ended up in the response.
"A prompt that did not fit the pool was internally marked as rejected and replaced with a one-token placeholder, but instead of aborting the request and returning a client error, prefill generated the KV cache for the placeholder prompt and transferred it to the decode node." — from What happenedView official source →
The responses looked normal to users
GLM-5.3 users got what looked like a successful reply, not an error. The request should have failed, but the reply came back as normal and read sensibly, so a user had little reason to suspect it held someone else's content.
GLM-5.3 was the only model hit. Cloudflare's other models that split prefill and decode had KV cache pools larger than their context windows, so the bug never triggered.
"GLM 5.3 was the only model affected by this bug. 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." — from Issue two: SGLang bugView official source →
Cloudflare pulled the model the day after the report
Gadi Evron, a security researcher at Knostic, reported the bug through Cloudflare's HackerOne bug bounty program on September 8, 2026 (UTC). Cloudflare declared a security incident on September 9, and its product security team reproduced the leak with two separate accounts within 25 minutes.
Within 40 minutes of the declaration, Cloudflare made GLM-5.3 private, and it restored the model later that day with a fixed configuration. The report does not say whether affected customers were contacted. Cloudflare published the details on October 26 together with the researcher and RadixArk, the team behind SGLang.
From report to disclosure
Cloudflare took seven weeks to go from the bug report to the public write-up. Times are in UTC, as in Cloudflare's report.
From report to disclosure (from Cloudflare's report)
| Date and time (UTC) | Event |
|---|---|
| September 8, 23:11 | Gadi Evron reports the bug through HackerOne |
| September 9, 08:00 | Cloudflare starts checking the report |
| September 9, 13:22 | Incident declared; leak reproduced within 25 minutes |
| September 9, 14:00 | GLM-5.3 set to private; requests return an error |
| September 9, 14:52 | All prefill servers moved to the fixed configuration |
| September 9, 19:04 | Rebuilt with the fixed configuration and an engine patch, then tested with the researcher's script |
| September 9, 19:40 | GLM-5.3 back online |
| September 10 | Meeting with RadixArk; agreement on an upstream SGLang fix |
| October 2 | SGLang v0.5.21 released |
| October 19 | SGLang v0.5.22 released |
| October 26 | Joint disclosure by Cloudflare, the researcher and RadixArk |
The model was offline for about 5 hours 40 minutes. SGLang v0.5.21 and v0.5.22 both shipped before the disclosure.
"Security incident declared. Product Security reproduced the leak using two independent accounts within 25 minutes." — from TimelineView official source →
The KV cache now holds about 2.04 million tokens
To stop a repeat, Cloudflare matched GLM-5.3's settings to those of GLM-5.2, which freed GPU memory and raised the prefill KV cache pool to about 2.04 million tokens. That is roughly twice the context window. Cloudflare also patched SGLang so that a rejected request stops before its KV cache is sent to decode, and the same approach was merged into SGLang itself.
The fix first shipped in SGLang v0.5.20, with more fixes in v0.5.21 and v0.5.22. Cloudflare advises other operators running SGLang to update to v0.5.22 or later.
Longer term, Cloudflare and SGLang plan to tag each KV cache page with its owner and check the tag when the page is read. Cloudflare says a prototype cost under 1% in throughput and latency.
"We adjusted our GLM 5.3 configuration to match our GLM 5.2 configuration, which freed enough GPU memory that the prefill KV pool now holds about 2.04 million tokens, roughly twice the 1,048,576-token context length." — from Immediate remediationView official source →
How companies and staff can prepare for incidents at AI providers
This leak came from the provider's settings and software, not from anything users did wrong. Data sent to an outside AI service can surface in another user's reply because of a bug at the provider, and the sender cannot prevent that alone. Companies should therefore decide in advance what data may go into outside AI tools.
On June 2, 2023, Japan's Personal Information Protection Commission published an alert on generative AI services for both businesses and individual users. The two steps below follow that alert.
Companies: decide what data may go in and check how providers use it
The Commission asks businesses that enter personal data into generative AI to confirm it stays within the purpose they collected it for. If personal data is entered without consent and the provider uses it for anything beyond producing the reply, the business may break Japan's privacy law. Before entering such data, businesses should confirm that the provider does not use it for machine learning.
On top of that, decide which AI services staff may use and which data may or may not go into them, and make the rules known. Customer personal data and documents from business partners would need explaining to others if they leaked, so settle those first.
"当該個人データを機械学習に利用しないこと等を十分に確認すること。" — from section 1, Points for businesses handling personal informationView official source →
Staff: read the terms and keep sensitive data out
Before using an AI service at work, staff should read the provider's terms of use and privacy policy and decide based on what they plan to enter. The Commission gives individual users the same advice.
As the GLM-5.3 case shows, a provider bug can send your input into someone else's reply. Even with a service your company approves, keep out anything you would not want to leak. At Panasonic, staff and family data was uploaded to a banned AI tool (see Panasonic HR data on 334,000 uploaded to banned AI).
"生成 AI サービスを提供する事業者の利用規約やプライバシーポリシー等を十分に確認し、入力する情報の内容等を踏まえ、生成 AI サービスの利用について適切に判断すること。" — from section 3, Points for individual usersView official source →
FAQ
- Were other Workers AI models affected?
- No. Cloudflare says it confirmed that no other model on Workers AI was affected. Its other models that split prefill and decode had KV cache pools larger than their context windows.
- Did anyone exploit the bug on purpose?
- Cloudflare says it found no evidence of deliberate exploitation. Leaving out its own tests and the researcher's, the affected requests matched ordinary long-context use in timing and volume.
- What should teams that run SGLang themselves do?
- Cloudflare advises operators who run SGLang with prefill and decode on separate nodes to update to v0.5.22 or later, or to backport the patches.
Related articles
Panasonic HR data on 334,000 uploaded to banned AIA Panasonic group project member uploaded HR data on about 334,000 employees, ex-staff and relatives to a banned AI service. No misuse has been found so far.
AI cyber attack: AI agents hit 27 firms for $25In an AI cyber attack disclosed by Gambit Security, three open source AI agents breached at least 27 retailers and took 600,000+ cards for about $25 a target.
EMBRACE flaws hit 5 AI coding tools, 2 unpatchedForever Security found flaws in the built-in browsers of Cursor, Copilot, Codex, VS Code and Claude Desktop. Codex and VS Code were unpatched at publication.
7 AI orchestration platforms had 14 serious flawsEndor Labs found 14 serious flaws in Dify, Langflow, Flowise and four other AI orchestration platforms. In some, one prompt could run code without a login.