Cloudflare AI Leak Crossed Customer Boundaries — and Access Controls Couldn't Stop It

Written By
eWEEK Staff
eWEEK Staff
Oct 28, 2026
3 minute read
Cloudflare AI data leak illustration showing separate customer data streams crossing isolation boundaries in shared AI infrastructure

Cloudflare's AI data leak highlights security risks that access controls alone cannot address in shared inference infrastructure. Image: Generated via Google's Nano Banana 2

eWeek content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More

Cloudflare's AI data leak exposed a weakness that user permissions alone could not prevent. Some authenticated customers received AI responses containing information from other customers' requests, without needing access to those customers' credentials.

In an Oct. 26 disclosure, Cloudflare confirmed that 155 responses from its GLM-5.3 model on Workers AI contained cross-customer information between Aug. 27 and Sept. 9, 2026. The failure occurred within shared AI inference infrastructure, where safeguards intended to separate customer workloads broke down.

How Cloudflare's AI data leak happened

Security researcher Gadi Evron of Knostic reported the vulnerability through HackerOne on Sept. 8. Cloudflare reproduced the issue the following morning and temporarily disabled the affected model, according to its incident report.

The problem involved SGLang, the open-source inference engine running GLM-5.3. Cloudflare configured a 1,048,576-token context window, but the GPU key-value (KV) cache could accommodate only 681,280 tokens. That cache temporarily stores information used during AI processing.

Oversized requests should have returned errors. Instead, a software bug allowed rejected requests to proceed through the distributed inference pipeline, where response generation could draw on cached data belonging to earlier requests.

In its independent investigation, Knostic documented responses containing names, invoice details, source-code information, filesystem paths, and AI agent records. Such information poses confidentiality risks for enterprises using AI in software development and other sensitive workflows.

Cloudflare said GLM-5.3 was the only Workers AI model affected and found no evidence of deliberate exploitation. It restored service on Sept. 9 after correcting the configuration and patching the engine.

Additional memory-management safeguards followed. An SGLang security advisory documents related fixes and deployment-specific guidance.

Advertisement

Why access controls could not prevent the exposure

The failure occurred below the identity and access management layer. Enterprise AI agent identity controls restrict access and delegated permissions, but cannot independently enforce memory isolation inside shared inference infrastructure.

The need for isolation testing also applies to enterprise platforms offering shared AI models. Broadcom says VMware Cloud Foundation supports tenant-specific data separation, although its published documentation does not establish how those protections compare with the inference-memory safeguards involved in Cloudflare's incident.

Cloudflare's incident also differs from data exposure addressed by Microsoft's AI data protection controls, which help prevent sensitive information from reaching untrusted AI destinations. Here, information crossed customer boundaries after requests entered an authorized service.

What eWeek Found: Successful API checks missed an isolation failure

Cloudflare's configuration exposed a measurable gap between accepted context length and available memory. The 1,048,576-token limit exceeded prefill cache capacity by 367,296 tokens, approximately 54% more than the cache could accommodate.

Engineers knew about the mismatch before launch but expected oversized requests to fail safely. Prelaunch benchmarks returned successful HTTP responses without validating generated output integrity. Knostic's later tests demonstrated that such responses could contain unrelated customer information.

Cloudflare subsequently corrected the capacity mismatch, patched request handling, and added direct deployment checks. These changes addressed the reported failure without establishing that every potential memory-isolation vulnerability had been eliminated.

Enterprise security assessments should therefore examine how providers validate cache ownership, reject oversized requests, and test isolation under failure conditions. Cloudflare has remediated the reported exposure, but the disclosures do not establish how widely comparable vulnerable configurations were deployed elsewhere.

Want to learn more AI tips, tricks, and prompting techniques? Let us teach you How to Talk to AI for free! Try our six-minute course at The Neuron Academy, our practical learning platform designed to help professionals use AI more confidently at work.

Advertisement

Learn a few simple ways to write better prompts and get more useful results from AI, or browse our other AI course for free for seven days. eWeek readers get free 7-day access. Check out all the lessons here →

eWeek Logo

eWeek has the latest technology news and analysis, buying guides, and product reviews for IT professionals and technology buyers. The site's focus is on innovative solutions and covering in-depth technical content. eWeek stays on the cutting edge of technology news and IT trends through interviews and expert analysis. Gain insight from top innovators and thought leaders in the fields of IT, business, enterprise software, startups, and more.

Property of TechnologyAdvice. © 2026 TechnologyAdvice. All Rights Reserved

Advertiser Disclosure: Some of the products that appear on this site are from companies from which TechnologyAdvice receives compensation. This compensation may impact how and where products appear on this site including, for example, the order in which they appear. TechnologyAdvice does not include all companies or all types of products available in the marketplace.