URLPattern out-of-bounds read in workerd
The URLPattern issue sits in the native C++ glue around workerd, not in JavaScript itself. That matters because the V8 isolate still gives a sense of separation, but the runtime has to cross into native code for bindings, arguments, and object handling. If that glue steps outside its bounds, the isolate boundary stops helping.
Cloudflare Workers and Code Mode both rely on workerd, so the same class of flaw can affect more than one deployment model. In Workers, the concern is cross-tenant exposure inside a shared process. In Code Mode, the concern is whether tool access and sandbox limits still hold once the runtime is doing unsafe memory work behind the scenes.
Why the V8 isolate boundary is only part of the story
V8 isolates separate execution contexts, but they do not turn a process into a hard security boundary. Native bindings still run in the same address space, and that is where memory-safety failures become interesting to an attacker. If the runtime can be pushed into an out-of-bounds read, the attacker is no longer limited to their own heap objects.
That is the key point for workerd memory corruption. The sandbox boundary is not just JavaScript versus the host. It also depends on every C++ path that handles input, marshals values, and returns results to the isolate. One bad read in that layer can leak nearby data without needing code execution.
The URLPattern path that lets native C++ glue step outside its bounds
URLPattern is a good example of how a high-level API can still end up in low-level trouble. The exposed surface looks safe enough from the outside, but the implementation has to translate structured pattern data into native runtime behaviour. If index checks slip or object bounds are misread, the runtime can read memory it should never touch.
In a shared process, that kind of read is not just a private crash risk. It can expose heap contents from another tenant if their data happens to sit nearby. Secrets do not need to be copied neatly for that to matter. A partial read can still reveal enough to be useful, and the garbage in the heap is often less random than people like to pretend.
Where the heap read lands and what an attacker can pull back
The practical concern is not abstract memory safety. It is what sits in memory at the time of the read. In a multi-tenant runtime, that can include fragments of another Worker’s state, tokens, or application data that were never meant to share a request path.
That is why the failure mode is serious in both Cloudflare Workers and Cloudflare Code Mode. Workers use V8 isolates inside one process for tenant separation. Code Mode layers a typed TypeScript API over MCP tools and blocks filesystem access and arbitrary network access, but it still depends on workerd to keep the native side honest. If the native side leaks memory, the rest of the sandbox starts to look decorative.
What to check in Workers and Code Mode deployments before the fix is trusted
The first thing to check is the runtime version. Self-hosted workerd and Code Mode deployments should be on v1.20260619.1. Anything older deserves suspicion, even if the surface behaviour looks fine. Memory corruption rarely advertises itself politely.
Managed Cloudflare Workers were fixed in production, so the risk profile is different there. Self-hosted nodes still need an explicit update, and any custom deployment that embeds workerd should be treated as part of the patch scope. If the runtime is old, the safe assumption is that the vulnerable path is still present until proven otherwise.
Verify the runtime version, update self-hosted nodes, and test the affected path
Version checks should be boring and direct. Confirm the exact workerd build in use, then update every node that runs it. Mixed versions are a tidy way to leave one bad instance behind and discover it later through logs or an incident response call.
Test the URLPattern path after patching, especially if the deployment uses custom bindings or has a narrow set of runtime features enabled. The point is not to “test security” in the abstract. It is to confirm that the runtime path handling still behaves as expected after the patch and that no old binary is quietly lingering in a container image or host package.
For Code Mode, the extra constraint is that tools are only reachable through bindings and the runtime blocks direct filesystem and network access. That helps, but it does not change the repair order. Fix the runtime first, then trust the sandbox less than you used to. That is usually the sensible way round.
