LAS VEGAS — A flaw in the way Cloudflare allowed customers to create and manage AI workflows in the cloud could have allowed one customer to upload a simple snippet of code to their cloud infrastructure that allowed them to steal sensitive data from other firms hosting on the same shared instance.
The flaw was found by researchers investigating Code Mode, a relatively new Cloudflare architecture that lets AI agents write and run code to complete tasks rather than calling one tool at a time. But Code Mode runs on workerd, the runtime underneath it. Workerd is the same software that runs every Cloudflare Worker, AI-powered or not.
See Related: Black Hat 2026: Old-School Bugs Crack Open AI Agent Frameworks
That meant a vulnerability found while studying an AI feature turned out to threaten Cloudflare’s platform far more broadly, extending the risk well past AI workloads to any customer running code on Workers.
In all, Check Point researchers Shahar Tal and Yarden Porat uncovered five vulnerabilities in workerd, the open-source runtime underlying Cloudflare Workers. Cloudflare rated two of the flaws critical.
“With Cloudflare, it actually turned out to be a much bigger story than we set out to find,” Tal told Security Point Break at Black Hat USA. Cloudflare’s Code Mode, an architecture that lets AI agents write and run code rather than call tools one at a time, was the original target. But Code Mode runs on workerd, which underpins every Worker running on Cloudflare’s platform.
This he said pushed the research into a broader context.
Unlike traditional cloud architectures, where each customer’s code runs inside its own dedicated virtual machine or container, fully separated from other customers’ machines, workerd can run multiple customers as lightweight, sandboxed environments called V8 isolates, similar to how a web browser keeps each open tab separate from the others, inside a single operating-system process.
The architecture provides speed and efficiency benefits, but it makes tenant isolation a critical security boundary. In practice, that means Company X and Company Y might have code running side by side on the very same machine — and the sandbox is the only thing standing between Company X’s tokens, credentials, and customer data and a stranger sitting right next to it.
What Check Point’s research found was that on a single compromised machine, Tal said, an attacker isn’t limited to one victim. A shared machine typically runs at least dozens of tenants at once, meaning a successful exploit could expose secrets belonging to many customers simultaneously, not just one.
“As many [tenants] as are running on that machine, and usually there are at least dozens,” Tal said. “Credentials, tokens, SSH keys — anything that they would hold to be secret in that tenant, we’re able to take,” he said.
Cloudflare confirmed the underlying bugs exist in its production environment, according to Check Point. But Check Point’s full demonstration of stealing another tenant’s secrets was carried out on a self-hosted workerd environment, not against live customer infrastructure.
None of the five vulnerabilities have been assigned a CVE.
One flaw in workerd’s URLPattern implementation let code read memory it wasn’t supposed to see. Check Point built that into a working attack that could search shared process memory, demonstrating it recovering another simulated tenant’s OpenSSH private key.
During the Check Point session “When Agentic Glue Melts: Exploiting Cloudflare Code Mode and Workers”, researchers showed how a malicious Worker could scan the shared heap until it located and printed a victim tenant’s key.
Exploiting it required little more than uploading attacker-controlled JavaScript to a Worker, Tal said. In Check Point’s demonstration, reading the targeted memory on the shared machine took less than half a second.
Workerd uses two different implementations to match URL patterns. One is built on Ada, an open-source URL-parsing library that Cloudflare also uses in Node.js and elsewhere. Cloudflare confirmed that this Ada-backed version could be triggered in its production environment, according to Check Point.
The researchers did not run the complete cross-tenant exploit against Cloudflare’s live infrastructure. Check Point’s public research post attributes this to the fact that the full end-to-end exploit was built against the original URLPattern implementation, which does not trigger in Cloudflare’s production environment at all.
Instead, the researchers demonstrated the attack against a self-hosted workerd deployment, the open-source version of the runtime that organizations can run independently of Cloudflare’s own platform.
There is no indication any customer, on Cloudflare’s managed service or running workerd independently, was actually affected. This was research Check Point conducted and demonstrated in a controlled setting.
Separately, Check Point found a use-after-free vulnerability in workerd’s node:zlib implementation – a different bug from the URLPattern flaw, but part of the same five-vulnerability set.
Researchers chained it into arbitrary memory read/write and, ultimately, native code execution: rather than stealing another tenant’s secrets. This attack let them break out of the sandbox entirely and run their own code on the host machine, starting from a prompt injection into Code Mode. That full exploit was also demonstrated against a self-hosted workerd environment, not Cloudflare’s production service.
Cloudflare rated two vulnerabilities critical: the zlib bug described above, and a separate use-after-free in workerd’s HTMLRewriter — a Workers feature commonly used to rewrite HTML as it streams through. Check Point’s published research names the bug and confirms its Critical rating but has not released further technical detail on how it works, unlike the URLPattern and zlib flaws.
The vulnerabilities were reported beginning in February and fixed before disclosure.
Cloudflare’s managed Workers environment has been patched, and workerd version 1.20260619.1 fixes the issues for self-hosted users. Check Point publicly presented the research at Black Hat USA and said Cloudflare had not assigned CVEs as of disclosure.
That decision not to assign CVEs became its own point of friction between the two companies, Tal said.
“They patched it, paid a great bounty, and ultimately decided not to assign CVEs,” Tal said.
Tal advises anyone who may have self-hosted a deployment of workerd outside Cloudflare’s managed environment is at risk.
The larger lesson, Tal said, is that securing AI infrastructure requires looking beneath the model.
SPB Interview: Shahar Tal on Breaking Cloudflare Workers’ Isolation
The following is the Cloudflare portion of Security Point Break’s Black Hat interview with Check Point researcher Shahar Tal. It has been lightly edited for clarity and repetition. The full video also includes discussion of Check Point’s separate research into vulnerabilities across AI agent frameworks.
SPB: I want to quickly talk about the Cloudflare research because, again, it was one of those “holy cow” pieces of research. Give us the short version.
Shahar Tal: With Cloudflare, we set out to research Code Mode, which is a relatively new architecture they released around how models should call tools.
SPB: So if I’m a developer building an agent on Cloudflare’s platform, this is something I might be using?
Shahar Tal: Right. You’re developing an agent. Code Mode runs on top of a sandboxing runtime called workerd.
And workerd is shared infrastructure used across Cloudflare Workers. So this became much wider than the agent or Code Mode itself.
We looked into that and fairly quickly found five very interesting vulnerabilities. Two of them were rated critical by Cloudflare.
With one of them, we were able to break kind of the most basic promise of the sandbox, which is to prevent cross-tenant contamination or leaks.
We were able to steal secrets or private data belonging to another tenant running in the same process.
SPB: So the interesting architectural point here is that different customers can have workloads running inside the same underlying process, and the sandbox is responsible for keeping those tenants separated.
Shahar Tal: Correct.
SPB: How difficult was the attack itself? Obviously the vulnerability research was deep, but once you figured it out, how complicated was exploitation?
Shahar Tal: That’s the interesting part. The research is deep, but exploitation is pretty easy once you understand it.
You need to upload attacker-controlled JavaScript to a Cloudflare Worker, and then the exploit payload runs.
In our demonstration, it took less than half a second, and we were able to read the memory we were targeting on that machine.
SPB: And that could mean another tenant’s secrets?
Shahar Tal: Yes. That was what we demonstrated.
