Check Point Research published a detailed analysis of vulnerabilities in workerd, the open-source runtime behind Cloudflare Workers and Cloudflare Code Mode. The research matters because it sits at the intersection of two trends many organizations are adopting quickly: edge/serverless platforms and AI agents that execute generated code.

The core issue is not “Cloudflare is unsafe.” Cloudflare says its managed Workers environment has already been fixed. The bigger lesson is that agentic tooling often depends on complex runtime glue, compatibility layers, and sandbox assumptions that defenders may not be monitoring closely enough.

What happened

Check Point found five memory-corruption vulnerabilities in workerd native C++ code. Two were rated Critical by Cloudflare. The research demonstrated two practical impact paths in a self-hosted environment:

  • Cross-tenant exposure risk: an out-of-bounds read path in URLPattern could allow one Worker to read data from another tenant’s process heap under the tested conditions.
  • Code Mode sandbox escape risk: a use-after-free issue in the node:zlib compatibility layer could be used as part of a chain that starts with prompt injection and ends in native code execution outside the intended agent sandbox.

Cloudflare’s hosted environment has been patched. Organizations running self-hosted workerd or Code Mode-style deployments should update to v1.20260619.1 or later and confirm their deployment pipeline is not pinning an older runtime.

Why SMBs and government contractors should care

Most small teams are not writing edge-runtime exploit chains. But many are adopting AI assistants, MCP tooling, serverless functions, and third-party automation faster than their security controls are adapting. This research is a clean reminder that the code an agent writes still runs somewhere, and that “sandboxed” does not automatically mean “low risk.”

For government contractors, the concern is broader than one platform. If an AI-enabled workflow can touch tickets, files, cloud consoles, CI/CD pipelines, or customer data, then the runtime boundary becomes part of the security boundary. That boundary needs the same discipline you would apply to any internet-facing service or privileged automation layer.

Defensive takeaways

  • Patch self-hosted runtimes fast: update workerd and any Code Mode deployments to the fixed release or later.
  • Inventory where agents execute code: document which AI tools can run scripts, call MCP tools, access cloud APIs, or handle customer data.
  • Limit agent permissions: bind tools to least-privilege roles. Avoid giving agent sandboxes broad filesystem, network, or cloud-admin access.
  • Separate tenants and trust zones: do not mix sensitive customer workloads, internal admin automation, and experimental AI execution in the same runtime boundary.
  • Treat prompt injection as an execution-path risk: if an agent can turn untrusted content into code or tool calls, prompt injection is not just a content-filtering problem.
  • Monitor the runtime layer: log agent actions, tool calls, generated code execution, abnormal crashes, and unexpected outbound network attempts.

Bottom line

AI security is not only about prompts and policies. It is also about the low-level software that agents rely on to interact with the world. As AI tooling becomes part of business operations, defenders need to evaluate the whole stack: model, prompt flow, tool permissions, runtime sandbox, patch cadence, and logging.

Original research: Check Point Research — When Agentic Glue Melts: Exploiting Cloudflare Code Mode and Workers.