# Cloudflare's GLM-5.3 Bug Leaked Other Customers' Data in 155 AI Responses

- URL: https://usa-24.com/cloudflare-glm-5-3-data-leak/
- Publisher: USA 24
- Section: Artificial Intelligence (AI)
- Published: 2026-10-27T12:25:09.122Z
- Updated: 2026-10-27T12:25:09.129Z
- Topics: Cloudflare, AI Security, Data Privacy, Workers AI, Open-Source AI

> Cloudflare says a bug in its Workers AI hosting of GLM-5.3 returned fragments of other customers' requests in 155 responses between August 27 and September 9.

## Key takeaways

- Cloudflare says its Workers AI endpoint for GLM-5.3 returned fragments of other customers' requests in 155 responses between August 27 and September 9, 2026.
- The root cause was a size mismatch: the model advertised a 1,048,576-token context window, but the KV cache pool on its prefill GPUs held only 681,280 tokens.
- Affected clients received HTTP 200 responses that looked coherent, so they had no error signal that something had gone wrong.
- Cloudflare took the model offline within 40 minutes of declaring an incident and says it found no evidence of deliberate exploitation.
- Operators running SGLang should upgrade to v0.5.22 or later, the version Cloudflare recommends.

The Cloudflare GLM-5.3 data leak started with a mismatch between two numbers. For a window that ran from August 27 to September 9, 2026, some developers calling Cloudflare's hosted GLM-5.3 model received responses containing fragments of other customers' requests. Cloudflare disclosed the problem in an [incident report published October 26, 2026](https://blog.cloudflare.com/kv-cache-exposure-remediation/) that counts 155 affected responses. The company says it found no evidence of deliberate exploitation. The fault lay in its own configuration and in shared open-source software, not in an attack.

Workers AI is Cloudflare's platform for running AI models on behalf of developers, and it offers GLM-5.3 as one of its hosted options. The model is developed by Z.ai, a Chinese AI company. That combination, a Chinese-built model served to American developers by a major U.S. cloud provider, is one reason the disclosure matters beyond a single company's error. Cloudflare dates the GLM-5.3 launch on Workers AI to August 27, though one outlet cites a changelog entry dated August 28.

## How the disclosure unfolded

Security researcher Gadi Evron of Knostic reported the tenant-isolation issue to Cloudflare on September 8, 2026, through the company's HackerOne program. Cloudflare reproduced it the next morning and took the model offline within 40 minutes of declaring an incident. It then deployed a corrected configuration and a patched inference engine, and it restored service the same day.

The sequence, as reported in Cloudflare's post and secondary coverage, looks like this:

| Date (2026) | What happened |
|---|---|
| August 27 | Cloudflare dates the launch of GLM-5.3 on Workers AI |
| August 27 to September 9 | Window in which affected responses were served |
| September 8 | Gadi Evron of Knostic reports the issue through HackerOne |
| September 9 | Cloudflare reproduces the issue and takes the model offline |
| October 26 | Cloudflare publishes its incident report, and SGLang confirms the report |

The disclosure followed a coordinated process with the researcher and the SGLang maintainers, according to [Mallory's write-up](https://mallory.ai/stories/01a17a82-65fb-762b-9043-2471b832766e). SGLang, the open-source inference engine Cloudflare ran the model on, [confirmed the report](https://www.lmsys.org/blog/2026-10-26-cf-security). It said it worked with Cloudflare to address the request-rejection path involved and to strengthen related cache-lifetime handling.

## The root cause: a context window larger than the cache

Cloudflare deployed GLM 5.3 with a 1,048,576-token context window. The KV cache pool on its prefill GPUs, however, had room for only 681,280 tokens. A KV cache stores intermediate computation so repeated parts of a prompt do not have to be recomputed. In a multi-tenant system, that stored state should never leave the request that created it. Here, it did.

A second defect made the first one worse. According to Cloudflare, a prompt that did not fit the pool was internally marked as rejected and replaced with a one-token placeholder. 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. Cloudflare says it was aware of this mismatch before launch.

The affected prompts were all longer than 681,280 tokens. That threshold is far above what most chat and retrieval apps send in a single call, which is why the bug was narrow in practice. Narrow, though, does not mean harmless for the customers whose data appeared in someone else's output.

## Why affected users saw no error

The bad output did not look like a failure. Clients that sent those oversized prompts received an HTTP 200 response that appeared coherent, which means affected users may have had no signal that anything had gone wrong. That detail matters for anyone who builds monitoring around status codes. A success code confirms the server answered, not that the answer came from your prompt.

Cloudflare has said that no other Workers AI models were affected. In its incident report, the company wrote: "We found no evidence of deliberate exploitation." That statement speaks to intent. It says much less about who saw what.

## Which customers may have been exposed

Cloudflare says it notified customers whose requests it could identify. Coverage from [1023 Jack](https://1023jack.com/news/your-ai-answer-in-a-stranger-s-session-cloudflare-s-kv-cache-leak-and-the-ai-spa/) argues the disclosure does not explain how affected customers were notified, so do not assume a notice will reach you. The company has not disclosed how many customers were affected in total. It has also not said whether the leaked fragments contained personal or sensitive information.

Some search results describe a different GLM-5.3 incident from May 2025, with different figures. Those accounts conflict with Cloudflare's report, so readers should treat Cloudflare's primary post as the authoritative record.

## What to check if you use Workers AI or self-host SGLang

If your team used GLM-5.3 on Workers AI, or runs SGLang yourself, work through these steps:

1. Check your Cloudflare account dashboard and email for an incident notice. Cloudflare says it contacted customers whose requests it identified.
2. Search request logs for GLM-5.3 calls between August 27 and September 9, 2026. Flag any prompt longer than 681,280 tokens, since those are the only prompts Cloudflare says were affected.
3. Review responses from that window for content your application did not send, such as text that reads like another user's conversation, other people's names or code you did not write.
4. If you run disaggregated SGLang, upgrade to v0.5.22 or later. Fixes shipped across v0.5.20 through v0.5.22, and Cloudflare recommends that all SGLang operators upgrade.
5. Treat any sensitive content sent to that endpoint during the window as potentially seen by someone else, and report suspicious output to Cloudflare through your support channel.

## What this means for shared AI infrastructure

The lesson reaches past one model. Multi-tenant inference systems batch and cache work from many customers, so the boundary between customers is enforced in software. The cache is a performance feature, and this incident shows what happens when cached state outlives the request that should own it. Because SGLang is used across many AI hosts, a fix in one open-source project can reach operators who never touched Cloudflare's stack.

Public reporting on AI-serving leaks is rare, which is part of why this one stands out. It names a model, a platform, specific counts and a dated timeline. That level of detail makes it easier to judge the risk and easier to check whether your own systems were affected.

Compare this with the broader debate over AI agents. Banks have begun blocking unvetted agents from customer accounts, as covered in [our report on bank restrictions](https://usa-24.com/ai-agents-bank-accounts-blocked/). In this case, no agent acted on the wrong account. Instead, a model response carried another customer's data. Model provenance is drawing similar scrutiny, as in [our coverage of Alibaba's Qwen model](https://usa-24.com/qwen-beijing-upload-cohere-test/).

For US readers, the practical rule is simple. Treat any hosted model as shared unless the provider documents its isolation controls in writing. Ask vendors how caches are scoped per customer, what happens when a prompt exceeds the context limit, and whether failures are returned to the caller as errors.

## What comes next

Several answers are still missing. Cloudflare has not published a customer count, and one source says the company is still working on stronger memory isolation. Watch for a follow-up from Cloudflare on those controls, clearer notification details, and SGLang release notes that spell out the cache-lifetime changes. Developers who sent long prompts to GLM-5.3 during the window should finish their log review before assuming they were untouched.

## Frequently asked questions

### Was my data exposed in the Cloudflare GLM-5.3 leak?

Cloudflare says it notified customers whose requests it could identify, but it has not published a customer count or detailed the notice process. Check your Cloudflare account and email for notices, and review logs for GLM-5.3 requests sent between August 27 and September 9, 2026. Only prompts longer than 681,280 tokens were affected, so shorter requests fall outside the reported bug.

### What is a KV cache, and why did it leak data?

A KV cache stores intermediate computation so a model does not recompute repeated parts of a prompt. In this incident, cached state from one customer's request could appear in another customer's response after a prompt that did not fit the cache was handled incorrectly. A configuration mismatch and an SGLang inference-engine bug combined to cause the exposure.

### Which SGLang version fixes the bug?

SGLang released fixes in versions 0.5.20 through 0.5.22. Cloudflare advises operators to run v0.5.22 or later and recommends that all SGLang operators upgrade. Teams running disaggregated SGLang setups should prioritize the update.

### Did a hacker cause the Cloudflare GLM-5.3 data leak?

Cloudflare says it found no evidence of deliberate exploitation. The cause was a configuration mismatch and a request-rejection error, not an intrusion. The bug still exposed customer data, which is why the disclosure matters even without an attacker.

## Sources

1. [Cross-request KV cache exposure in the GLM-5.3 Workers AI model, and our remediation with SGLang — Cloudflare Blog](https://blog.cloudflare.com/kv-cache-exposure-remediation/)
2. [Cloudflare Says GLM-5.3 Bug Leaked 155 Responses Across Tenant Sessions — Unite.AI](https://www.unite.ai/cloudflare-says-glm-5-3-bug-leaked-155-responses-across-tenant-sessions/)
3. [SGLang security update: improving request isolation — LMSYS Org](https://www.lmsys.org/blog/2026-10-26-cf-security)
4. [Cross-request KV cache exposure in the GLM-5.3 Workers AI model, and our remediation with SGLang — daily.dev](https://daily.dev/posts/cross-request-kv-cache-exposure-in-the-glm-5-3-workers-ai-model-and-our-remediation-with-sglang-qkref7qhu)
5. [Cloudflare GLM-5.3 Cache Isolation Failure Leaked Customer Data in 155 Responses — Mallory](https://mallory.ai/stories/01a17a82-65fb-762b-9043-2471b832766e)
6. [Cloudflare GLM-5.3 KV cache bug leaked other customers' data in 155 Workers AI responses — Data Studios](https://www.datastudios.org/post/cloudflare-workers-ai-glm-5-3-kv-cache-exposure-155-responses-sglang)
7. [Your AI Answer In A Stranger's Session: Cloudflare's KV Cache Leak And The AI Spam Drowning Bug Hunters — 1023 Jack](https://1023jack.com/news/your-ai-answer-in-a-stranger-s-session-cloudflare-s-kv-cache-leak-and-the-ai-spa/)