Presales Customer Engineer

Cloudflare AI leak crossed customer boundaries - and access controls couldn't stop it. Oct 28, 2026 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. eWEEK may make money when you click on links to its 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. 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 eWEEK teach you How to Talk to AI for free! Try its six-minute course at The Neuron Academy, its practical learning platform designed to help professionals use AI more confidently at work. Learn a few simple ways to write better prompts and get more useful results from AI, or browse its other AI course for free for seven days. eWeek readers get free 7-day access. Check out all the lessons here

Researchers chain cloudflare security flaws to bypass CSP and execute malicious JavaScript. October 28, 2026 Security researchers at Searchlight Cyber chained several small flaws in Cloudflare's image feature. The chain let them run JavaScript on a site that was meant to block it. Kevin Gervot and Adam Kues published the work on October 28, 2026, in a write-up titled Cache Me If You Can. They showed a working cross-site scripting (XSS) bug through the /cdn-cgi/image/ endpoint on cloudflare.com. The write-up does not list a CVE or a patch status, so readers should check with Cloudflare. Discover more Cybersecurity news subscription Computer security consulting Cloudflare XSS flaws. Cloudflare sits in front of 24.3% of all websites. When a site joins Cloudflare, the company adds a managed /cdn-cgi/ path to that site's own domain. Features such as bot checks, Web Analytics, Access, and Image Transformations live there. Because these pages load from the customer's own domain, a bug in them runs with that site's trust. Other researchers had already found Content Security Policy (CSP) bypasses in this path. CSP is a browser rule set that limits which scripts a page may run. Cloudflare cleans SVG images with svg-hush, a Rust tool built on the xml-rs library. The tool checks the file, then writes it back out. The researchers found that xml-rs escapes normal attribute values but writes namespace values (the xmlns setting) raw. An attacker can hide a quote mark in that value and break out of it. The filter has already approved the file by then, so the script tag slips through. Cloudflare serves these images with a strict policy of default-src 'none', which blocks scripts. However, the endpoint passes along Cache-Control headers from the source image. The HTTP rules allow a form such as no-cache="Content-Security-Policy", which tells a cache to drop the named header. Only Chromium follows this rule, and it accepts any header name. The CSP stays in place on the first load. After Chromium saves the page, the policy is gone. A known CTF trick then forces Chromium to reload the saved copy. The attacker opens the page in a new window, moves that window to another site, and calls history.back. The opener link keeps the page out of the back/forward cache, so Chromium uses its disk cache, and the script runs. A related cache-based CSP bypass covered earlier by Cyber Security News relied on the same bfcache fallback. Image Transformations only fetches images from allowed sources. The default setting is "This zone only". The fetcher follows redirects without checking the final address. Any open redirect on an allowed site therefore lets an attacker load an image from anywhere. Discover more Buy Routers Computer security tools Cyber attack prevention The team wanted a method that needed no open redirect. They found that once Cloudflare Access is on for any hostname in a zone, /cdn-cgi/access/logout works on every hostname in that zone. Its returnTo setting accepts any cloudflare.com subdomain. A redirect on a Cloudflare research host then sent the fetcher to the attacker's file. That completed the chain on zones with strict source settings. The team then tested the cache trick elsewhere. On Netlify Image CDN, they used it to drop both the CSP and the Content-Type header. Chromium then guessed the file type from its content and treated an SVG starting with a doctype as HTML. A processing instruction hid the script from the SVGO cleaner, which only checks elements. The researchers say Netlify's hosted code is not public, so they could not confirm it matches the open-source version. Amazon S3 and Google Cloud Storage also allow signed links to override response headers. Such links can set response-content-type and response-cache-control. This matters for buckets behind custom domains or proxies that pass query strings along. The idea builds on earlier Content-Type override research and the S3 GetObject overrides. The main lesson is that you shouldn't trust only a file's body. Headers passed through by an image service or storage layer become part of your security. Teams should avoid forwarding Cache-Control and X-* headers from untrusted sources. They should also set X-Content-Type-Options: nosniff and review which sources their image tools may fetch. Closing open redirects helps too. Past work shows that even strong filters can fail, as in WAF bypass research on XSS payloads. Layered defenses still matter. Gurubaran KS is a cybersecurity analyst, and Journalist with a strong focus on emerging threats and digital defense strategies. He is the Co-Founder and Editor-in-Chief of Cyber Security News, where he leads editorial coverage on global cybersecurity developments. 0-Hour Cyber Security Alerts! Get the latest Cyber security News sent directly to your inbox. Discover more Cyber attack news Security alerts service Audit Security

The AI spam flood behind A difficult bug hunting search. Cloudflare says a hosted AI model returned 155 responses containing other customers' data. A separate audit highlights the growing burden of AI-generated bug reports. Up next. Published on 27 October 2026 AI This post was created with the assistance of artificial intelligence (AI). Buying for a business? Offer from Amazon Get business pricing on monitors, keyboards and dev gear * Business-only prices and quantity discounts * Tax-exempt purchasing * Multiple users, one account, clear invoices As an affiliate, EarnQA, Inc. earn on qualifying purchases. Cloudflare reported that its hosted GLM-5.3 model returned 155 responses containing data from other customers' requests between August 27 and September 9, 2026. In a separate security-audit example, Jump Crypto says AI agents likely found or wrote nearly all reports submitted to a Firedancer contest, leaving reviewers to sort 809 submissions into 127 unique findings. Cloudflare disclosed October 26 that its hosted GLM-5.3 model returned 155 responses containing data from other customers' requests over a 14-day period. A separate Jump Crypto audit contest offers a contrasting security problem: the company received 809 submissions that it says were reduced to 127 unique findings, with AI agents likely responsible for nearly all the reports. Together, the cases show how AI can create both security risks in deployed services and more work for the people reviewing bug reports. Cloudflare traced the leak, which ran from August 27 to September 9, to a mismatch in its configuration combined with a bug in the open-source inference engine SGLang. The affected endpoint was its hosted @cf/zai-org/glm-5.3 model on Workers AI. According to Cloudflare, only prompts longer than 681,280 tokens could trigger the issue, despite the service advertising a context window of 1,048,576 tokens. Discover more Audit Quality Try Cloud Tools Try Dev Tools The incident involved the model's key-value cache, a store of intermediate data used to generate responses. Cloudflare said cache pages were not cleared between requests, a practice it described as common and useful for performance. When a too-long prompt was rejected in one part of its split inference setup, a queue in another part checked whether the request had finished but not whether it had been rejected. That allowed decoding to read cache pages that still contained data from other requests. Cloudflare says the affected responses returned HTTP 200 and could appear coherent. Security researcher Gadi Evron of Knostic reported the issue through HackerOne on September 8. Cloudflare says it took the model offline 38 minutes after declaring an incident and restored a fixed version later that evening. It found no evidence of deliberate exploitation, and says the affected requests appeared consistent in timing and volume with ordinary long-context use. Separately, Jump Crypto's $1 million Firedancer audit contest drew reports from 162 researchers. Jump says those 809 reports amounted to 127 unique findings and believes AI agents found or wrote nearly every submission. At a glance report When: Cloudflare published its incident repor... The development A Cloudflare incident report and a Jump Crypto audit contest illustrate two different security effects of AI: a customer-data leak in hosted inference and a surge of reports that are costly to review. Thorsten Meyer AI Cloudflare Workers AI · GLM-5.3 Infographic 01 · Cross-request KV cache exposure How a long prompt read someone else's data. A memory pool smaller than the advertised context window, plus an engine bug that let rejected requests through, made one hosted model attend over other customers' leftover pages. 155 responses that contained other customers' data 14 days exposure window, 27 Aug to 9 Sep 2026 38 min from declaring the incident to taking the model offline none evidence of deliberate exploitation, per Cloudflare The mismatch. tokens; Cloudflare knew before launch and expected an error * Context windowadvertised1,048,576 * KV pool before the fixprefill GPUs681,280 * KV pool after the fixabout twice the window~2.04 M Only prompts longer than 681,280 tokens could reach the faulty path. The eight pages. Cloudflare's own example of one over-long request P0 written now P1 left over P2 left over P3 left over P4 left over P5 left over P6 left over P7 left over * Decode reserves 8 pages for the long prompt. * Prefill rejects it and swaps in a one-token placeholder... * ...but the rejected request still passes the handoff checks. * Prefill writes one page; decode reads all eight. * The client gets HTTP 200 and a coherent reply, partly built on someone else's data. Why pages hold old data. speed trade-off * GPU memory is a shared pool of fixed-size pages * Pages are not zeroed between requests; the next one overwrites * Bookkeeping is the only wall between customers The fix. 9 Sep, 19:40 UTC * Pool resized so every valid prompt fits * Engine retires rejected requests before any memory transfer * Upstream: SGLang v0.5.20 to v0.5.22; operators should run v0.5.22+ Still open. not in the report * Whether and how affected customers were notified * How many customers' requests contributed the leaked data * What kind of data it was Two costs of ai-assisted security. The Cloudflare incident matters because it involved customer data crossing request boundaries in a hosted AI service. A customer submitting an unusually long prompt could receive text associated with another customer's request. Cloudflare's report gives a count of affected responses and a technical explanation, but does not state how many customers were affected or describe how they were notified. The audit example points to a different pressure on security teams: generating bug reports has become cheaper, but validating, deduplicating and investigating them still takes human time. Jump's contest figures do not establish that AI-generated reports were invalid; the company's reported 127 unique findings came from 809 submissions. But the gap between submissions and unique findings shows why raw report volume is a poor measure of useful security work. For service operators, the leak underscores the need to test what a model returns - not just whether an inference request completes successfully. For bounty programs and researchers, the challenge is maintaining useful disclosure channels when automated tools can produce reports at scale.