Cloudflare Workers AI Mixed User Data in 155 Replies

October 31, 2026

Cloudflare says 155 GLM-5.3 replies exposed other request data; the issue was fixed September 9. Learn why history, training and inference isolation are separate.

Cloudflare says 155 Workers AI responses included other customers' request data. The affected GLM-5.3 deployment was fixed on September 9, 2026; the company disclosed the incident on October 26. This was a failure during inference—not evidence that turning off chat history or model training prevents every kind of AI data exposure.

By OpenVeil Editorial. Research cutoff and last reviewed: October 31, 2026.

What Is Confirmed

According to Cloudflare's incident report:

Question Reported answer
Which deployment? Workers AI's @cf/zai-org/glm-5.3; Cloudflare found no other Workers AI model affected.
When? August 27–September 9, 2026, not an ongoing October exposure.
What was counted? 155 affected responses, all to prompts exceeding 681,280 tokens. That is not a count of people.
Deliberate exploitation? Cloudflare found no evidence of it after excluding its own and the researcher's tests.

The useful lesson is broader than the incident: data can cross a boundary while a model is answering, even when the privacy question you originally asked was about what gets saved afterward.

What Is Still Unclear

The published count does not establish how many distinct people had information exposed, which categories of information each response contained, or every downstream place a recipient might have copied an output. Do not substitute an imagined customer list for those missing details.

This article reviews published disclosures and code-review material; it does not independently reproduce the incident or audit a current deployment. A historical report also cannot certify every other provider's present isolation controls.

Equally important, the report is not evidence that all websites using Cloudflare were affected. Website hosting, traffic protection and a particular hosted model endpoint are different services. Seeing Cloudflare in a site's infrastructure is not enough to place that site inside this incident's scope.

What a KV Cache Does—and Why It Matters

A language model generates text incrementally. Recomputing all the relevant attention calculations for every new token would be wasteful. A key-value, or KV, cache keeps intermediate attention information available for reuse. Hugging Face's cache documentation explains that performance trade-off.

Think of it as working memory used to produce an answer, not the account's saved conversation list. It is also not the same thing as a model being trained on that conversation. These distinctions matter because deleting one kind of record does not automatically establish safe handling of every other representation.

The SGLang team's companion disclosure describes a split architecture: one set of workers processes the prompt, then another generates the response. The advertised context limit exceeded the first stage's available cache capacity. A rejected request could nevertheless reach the handoff, allowing the generation stage to read pages not populated for that request.

That is a system-boundary problem. The model does not need to decide to betray a user for the surrounding machinery to supply the wrong context.

Three Privacy Questions That Need Separate Answers

An AI product's privacy explanation should answer three questions independently. Treating one answer as a substitute for the other two creates false confidence.

1. What becomes a durable record?

Ask where normal chat history lives, whether uploads have separate storage, what administrators can retrieve, and what deleting a conversation actually removes. A browser-local conversation list is a specific storage choice—not a description of everything that happens during a request.

2. What is processed to complete this task?

Ask which service receives the prompt, selected previous messages, file extracts, search terms or media. The visible text box may not describe the full task context. A useful answer names the processing boundary rather than merely repeating the word private.

3. How are simultaneous users kept separate?

Ask how the operator prevents one request's working state from being reused incorrectly by another. This is an engineering question about isolation, not simply a retention setting. Users normally cannot inspect this directly; that makes specific incident disclosures and remediation evidence valuable.

These are questions to ask, not a claim that a vendor with a detailed policy is automatically secure. Policies describe intended handling. Tests, implementation controls and incident response provide different kinds of evidence.

What Users Should Do Now

Start with scope, not panic. If you used the named endpoint during the reported period, ask your application provider whether your requests were in scope and whether it has account-specific findings. If you only used a website behind Cloudflare, do not infer exposure from its hosting brand.

For future sensitive tasks:

Data minimization is not a patch for inference software. It reduces the amount of unnecessary information entrusted to the workflow while the operator remains responsible for isolation.

What Operators Should Verify Before Calling It Fixed

SGLang's guidance recommends upgrading disaggregated deployments, with version-specific backend differences; its current recommendations include the v0.5.22 fixes and release metrics. It also calls for routers that cancel both halves of a split request and monitoring of deferred cache-release outcomes. Older configuration workarounds do not replace upgrading. Read the maintainer's operator guidance against your actual build and transfer backend.

The admission-fix pull request is useful because it states both validation and remaining limits. Its tests check that rejected requests do not enter handoff queues; it also documents an asymmetric rejection case that can still wait for a timeout. A merged patch should not be summarized as proof that every failure path now fails instantly.

For your own acceptance test, require more than a successful HTTP response:

  1. Check identity: use distinct, synthetic markers for different test tenants, never real customer secrets.
  2. Check boundaries: include rejected inputs, interrupted streams, cancellation and capacity changes—not only ordinary completions.
  3. Check content: verify which marker an answer contains, not just whether the request returned a success code.
  4. Check deployment parity: record the running versions and settings on both sides of a split service. A repository patch is not proof every worker received it.
  5. Check observability: decide in advance what evidence would reveal a failed isolation test, and retain the result with the release record.

This is a proposed acceptance framework, not a claim that these five checks exhaust all isolation risks. The crucial shift is from “the request completed” to “the correct request completed using only its authorized context.”

Where OpenVeil Fits—and Where It Does Not

OpenVeil offers a hosted AI workspace for adults who want chat, files, search, voice and media tools with browser-local normal chat history and no normal server-side chat-history record. OpenVeil does not use prompts, uploads, selected local history context or outputs to train foundation models.

Those are bounded product claims. Active requests still require processing by OpenVeil and necessary providers. OpenVeil is not fully offline or anonymous, and browser-local history is not a guarantee against provider-side inference bugs.

OpenVeil is not a patch for the Cloudflare incident. This article does not establish that OpenVeil uses the affected model, nor does it claim protection against unrelated infrastructure flaws. Choose a workflow based on its documented data path and the information you actually need to send—not a promise that any hosted AI can eliminate every risk.

If that narrower approach suits your everyday work, explore OpenVeil. For related boundary questions, read our guides to AI aggregators and stored chat logs and browser-preview permissions. Neither is the same failure mechanism as this inference-memory incident.

Frequently Asked Questions

Does turning off history prevent a KV-cache leak?

Not by itself. History settings concern conversation records; inference isolation concerns the working state used to answer requests. Ask about both rather than assuming one control covers the other.

Does no training mean nobody processes my prompt?

No. A no-training policy addresses model improvement, not whether the service must process an input to answer it. Processing, storage, training and isolation need separate explanations.

Does this mean local AI is always safer?

A genuinely local, isolated runtime can change who handles inference. Downloading weights alone does not establish that isolation: check the application, network access, plugins, logs and backups. Local operation also makes you responsible for the runtime's configuration and updates.

Should I clear my browser cache?

Clearing browser data is not a repair for a hosted inference engine. It can also remove browser-local chat history. Identify the affected component before applying a familiar but unrelated cleanup step.

Bottom Line

The durable question is not only “Will this AI save or train on my chat?” It is also “What information is used while answering, and how is that working state kept separate from other requests?” A trustworthy evaluation asks all three questions without turning a narrow privacy feature into a universal security guarantee.

Sources

When privacy, account control, uploads, and search matter, OpenVeil gives you a private AI workspace designed for that job.