Researchers at Check Point have found five memory corruption bugs in workerd, the open-source runtime Cloudflare uses to keep one customer's code from touching another's. Two of them are rated Critical by Cloudflare. Researcher Yarden Porat chained the bugs into two working attacks: one Worker reading another tenant's secrets straight out of shared memory, and a full escape from the sandbox Cloudflare built to run AI agent code.
The reach is the story. By Cloudflare's own published figures, Workers is built on by millions of developers, serves millions of requests per second, and carries more than 10% of all traffic on Cloudflare's network. The same runtime is also the sandbox underneath Code Mode, Cloudflare's newer approach to AI tool use, which hands a language model a typed TypeScript API and lets it write one program that calls the tools itself instead of emitting tool calls one at a time.
Why a memory bug here matters so much
Running code for an enormous number of customers at the network edge is too latency-sensitive for a container or a virtual machine per tenant, so Cloudflare isolates at the language level instead, using V8 isolates, the same primitive Chrome uses to separate browser tabs. The boundary between two paying customers is therefore a software boundary inside one shared process, not a kernel or hardware one.
Cloudflare layers defenses on top, on the assumption that V8 itself will eventually break: a cage that stops a corrupted JavaScript object from forging pointers outside it, hardware memory protection keys so one isolate cannot read another's pages, and a second-layer process sandbox built on Linux namespaces and seccomp. Check Point went around all of it by targeting workerd's own C++ glue code, the layer that hands Web and Node APIs to untrusted JavaScript. Native objects allocated by that code sit on a separate heap that neither the cage nor the memory protection keys cover.
How the two attacks work
The cross-tenant leak starts in URLPattern, a routing-style Web API that matches a URL against a pattern. When a pattern nests one capture group inside another, V8 counts two groups while workerd's own parser counted one, so the code pairing matched values with group names walks one step past the end of its name list and reads 24 bytes of whatever follows. Those bytes are then treated as a string object, pointer included, which turns an out-of-bounds read into an arbitrary one: control what sits after that list in memory and the API hands back the contents of an address of the attacker's choosing.
The sandbox escape starts from a prompt injection. The model is steered into writing attacker-controlled TypeScript, which triggers a use-after-free in workerd's reimplementation of Node's zlib module. A compression call leaves a raw pointer to a JavaScript output buffer sitting in zlib's state and never clears it. Once that buffer is garbage collected, a later call to adjust the compression level flushes pending data through the stale pointer, ending in native code execution on the host, fully outside the isolate.
What was actually demonstrated
This part deserves care. Both end-to-end exploits were verified against self-hosted workerd, not against Cloudflare's production platform. Check Point says plainly that it did not run them in production, because a crash on a shared host could have taken other customers' Workers down with it. The team's assessment is that the cross-tenant technique should carry over, since it runs entirely from the heap the mitigations do not protect, but it states it did not test that. It did confirm the underlying URLPattern read triggers in production in the newer implementation, which is backed by the Ada URL parsing library, and reported that bug to the Ada maintainers in parallel. The specific end-to-end path it demonstrated did not reproduce in production, because production carries a check the open-source build lacked.
What you should do
Cloudflare has already fixed its managed Workers environment in production, so customers who only use the hosted platform do not need to act. Anyone running workerd themselves, including self-hosted Code Mode deployments, should update to v1.20260619.1. The zlib bug is only reachable where Node compatibility is switched on, which applies to Workers using a compatibility date of 2024-09-23 or later, so that setting is worth checking on any self-hosted deployment. Check Point released proof-of-concept code alongside its Black Hat USA 2026 presentation, which shortens the window for anyone still running an old build.
The full write-up, including root cause analysis for all five bugs, is in Check Point Research's original report by Yarden Porat. It lands in a run of research aimed at the plumbing beneath AI agents rather than the models themselves: we recently covered bugs triggered by poisoned files in leading agent frameworks and an OpenAI agent that used a zero-day to escape its lab sandbox.
This briefing is provided by IntelFusions for informational and defensive purposes only. It is based on sources assessed to be reliable at the time of writing, and analytic judgments carry the confidence levels indicated. Indicators of compromise are defanged; re-arm them only in controlled environments. IntelFusions is not affiliated with the organizations named and makes no warranty as to completeness or accuracy.