Code Mode Sandbox Escape: Prompt Injection to Host Native Code via workerd

In plain language

Imagine an AI assistant that is allowed to write little programs so it can call many tools in one go—faster than asking for each tool separately. Those programs were supposed to run in a locked room shared by many tenants: thin walls (language isolates) instead of separate buildings (VMs). Researchers showed the walls had cracks in the glue between JavaScript and native code. With a carefully steered prompt, the model could write a program that smashed through those cracks—running native code on the host, or even reading secrets belonging to another customer in the same process. Cloudflare has patched its managed service and published a fixed open-source runtime build; teams that self-host the runtime, or copy “agent writes code in a sandbox” patterns, should treat sandbox trust as a production control—not a comfort story.

The Incident

An operator turns on Code Mode: instead of one structured tool call at a time, the model writes TypeScript against a typed API that wraps the tools. A user (or an injected document) nudges the model toward “helpful” compression or URL-matching code. The program looks ordinary—`node:zlib`, `URLPattern`, loops, local transforms. It runs inside workerd, the same in-process runtime that isolates Cloudflare Workers tenants with V8 isolates.

Then the glue fails. A use-after-free in `node:zlib`’s `deflateParams()` path leaves a dangling native pointer; later flushes write into freed heap. In the research demos, that becomes a path from prompt injection → model-written TypeScript → memory corruption → native code on the host, fully outside the isolate. A parallel bug class in `URLPattern` lets one Worker’s JavaScript reach across the shared process heap and swipe another tenant’s secrets—cross-tenant heap swipe—without needing a full escape.

Here is why “we reuse the Workers sandbox” was not enough.

Why existing thinking failed

The comfort story was sophisticated and widely believed:

- “Code Mode runs untrusted model code in workerd—the same boundary that isolates millions of Workers.”

- “V8 isolates + the cage + memory protection keys contain compromise.”

- “Prompt injection is a content problem; the sandbox is a separate, solid layer.”

- “Agent-generated TypeScript is just another Worker script.”

That story fails when native C++ glue (JSG / Node reimplementations) allocates objects on the tcmalloc heap outside the cage and MPK protections. Prompt injection becomes a code-execution entry point the moment the intended product mode is “the model writes the program.” Soft tool-call allowlists never see the payload if the model’s program reaches a buggy native API first.

Research proves it

Confirmed in Check Point Research’s Black Hat USA 2026 write-up [When Agentic Glue Melts](https://research.checkpoint.com/2026/when-agentic-glue-melts/) (Yarden Porat) and the companion PoC repository WhenAgenticGlueMeltsPOCs:

- Five memory-corruption issues in workerd native code; Cloudflare rated two Critical (including `node:zlib` `deflateParams()` UAF and an HTMLRewriter iterator UAF).

- Two end-to-end stories: Code Mode sandbox escape (prompt injection → zlib UAF → host native code) and cross-tenant heap swipe (URLPattern OOB read across shared process).

- Managed Cloudflare Workers / Code Mode fixed in production; self-hosted fix: workerd v1.20260619.1.

- No CVEs assigned (as of the public write-up / PoC README).

- Public PoCs drive workerd to an observable corrupted state; full exploit chains reserved for vetted researchers.

Reported: Workers’ scale (millions of developers / high share of Cloudflare traffic) as blast-radius context—not a claim of mass exploitation. Unknown: how many self-hosted vulnerable workerd pins remain in the wild; whether any tenant saw live abuse before the managed fix.

Engineering takeaway

If your agent stack lets the model write and run code next to tools, treat that path as hostile guest code with a native attack surface—not as “safer than MCP tool calls.” Pair SEC-M1 (injection defense) with TOL-M3 (exec / code-mode as high-impact), INF-M2 (runtime isolation honesty), AUTHZ-M1 (tenant isolation assumptions), and SCI-M2 (pin and patch the sandbox binary). The rest of this piece is the APRF Core map and the abuse path.

Why this matters

If agent-generated code can corrupt the shared process that hosts many tenants, secrets and neighbor isolation stop being theoretical—they become one steered program away. That hits platform engineers running Code Mode or any “LLM writes TypeScript in a sandbox” pattern, teams self-hosting workerd, multi-tenant edge/runtime owners who equate “isolate” with “VM,” AppSec reviewing agent tool runtimes, and product owners who assumed Workers-class sandboxes were out of scope for AI threat models.

What class of systems: Agents + Tools + Sandbox (+ multi-tenant API). Pure chat without code generation is less directly hit—unless you later bolt on Code Mode-style execution. RAG alone is not the vector; injection that reaches a code-writing agent is.

Can a startup ignore it? No if you self-host workerd / Code Mode-like sandboxes or let models emit executable programs against tools. Maybe if you only use Cloudflare’s managed Workers and stay current—and even then, inventory quarterly for self-hosted forks, local Code Mode experiments, and copied PoC Dockerfiles that pin vulnerable builds.

This is a sibling lesson to last week’s FrontMCP CodeCall escape: different product, same class—sandbox trust fails at the object/native boundary, not at the prompt filter.

Timeline

Root Cause

Code Mode collapses multi-step tool use into a single model-written TypeScript program that runs on workerd. Isolation is in-process V8 isolates, not per-tenant VMs. Defenses (V8 cage, MPK, L2 process sandbox) assume certain compromise models; they do not fully cover native objects allocated by workerd’s JSG / Node glue on the process heap.

The agent-facing failure chain:

1. Attacker (or poisoned content) injects instructions into the Code Mode agent.

2. Model emits TypeScript that exercises buggy native APIs (`zlib` params flush, `URLPattern`, etc.).

3. Memory corruption yields arbitrary read/write or host native code—escape—or cross-isolate heap disclosure—tenant isolation break.

4. Impact: host RCE and/or neighbor secrets; L2 sandbox may still limit FS/network, but the security story of “isolate = safe guest” is already broken for many threat models.

Root cause class: unsafe trust in in-process sandbox + agent-generated code as the primary tool-orchestration path, with prompt injection as the delivery mechanism.

APRF Lens

Failure class (APRF / threat-map vocabulary): Sandbox Escape via Prompt Injection → Unsafe Code Execution / Tool Abuse, with Privilege Escalation and Sensitive Information Disclosure on the cross-tenant path. Informative map only—not certification. Soft link: /aprf/threats/.

Profile: Core. Lenses: Agents (code-writing tool orchestration).

Check families in play (all IDs exist in APRF 0.11.0; selected with threat-map support):

Good evidence would look like: Code Mode / exec-tool policy (who may enable it); workerd (or equivalent) version attestation ≤90 days; tenant-isolation tests or platform attestations; injection eval gates before production; logs linking request → model → generated program → tool bindings; patch currency for the sandbox binary.

Standing caveat: APRF assessments can miss evidence. A repository is not the only source of truth. Runtime config, cloud IAM, secrets stores, vendor consoles, CI variables, production prompts, deployed model/tool versions, and human processes often never appear in source control. Absence of a finding is not proof of readiness. Threat-map rows are informative alignment—not proof a Check would have prevented this research.

Abuse Path Analysis

- PI → CM: Prompt injection is a first-class input when the product intends the model to write programs — cut with SEC-M1 (and content screening), not “sandbox will catch it.”

- CM → TS → ZL: Code Mode / exec-class capability without high-impact gates — TOL-M3 + inventory TOL-M1.

- ZL → MC → HOST: Native glue UAF / corruption → escape — INF-M2; treat as unsafe code execution, not a prompt issue alone.

- MC → PEER: Shared-process heap read — AUTHZ-M1 / multi-tenant isolation honesty.

- HOST → SEC/IMP: Secrets and impact — SEC-M4; detect with OBS-M1; reduce recurrence with SCI-M2 (patch pin).

Abuse path confidence: High — CPR documents both end-to-end demos; PoCs reproduce vulnerable workerd states publicly. Speculative only for “your specific managed tenant was hit.”

Standing caveat (brief): Repo/PoC evidence cannot prove your production host’s IAM, prompts, or patch lag.

Relevant Controls

Patterns from the public PoC repo (not a production victim)

Repo: yardenporat353/WhenAgenticGlueMeltsPOCs @ `34acae89…` (2026). How we looked: manual pattern review of README + per-bug `Vulnerability.md` / `Run.md` / Dockerfiles — not a full APRF Auditor score of Cloudflare or of this research harness.

Frame: educational pattern library that pins vulnerable workerd builds so bugs are observable. Exploitation payloads are intentionally omitted from the public tree.

Signals that map to this incident:

- zlib UAF write path documents the exact native glue failure Code Mode demos abused.

- URLPattern OOB PoCs illustrate cross-tenant read primitives on shared-process isolation.

- Dockerfiles make SCI-M2 concrete: teams can accidentally run vulnerable pins “for research” on shared CI agents.

What would improve a production agent host using Code Mode-like patterns: treat Code Mode as TOL-M3; require injection gates (SEC-M1); attest patched runtime (SCI-M2 / INF-M2); never assume isolate = cross-tenant secrecy without AUTHZ-M1-grade evidence.

Limits / blind spots: PoCs are not an agent product; no production prompts, IAM, or MCP inventory here. Managed Cloudflare was already fixed—do not read PoC Dockerfiles as the live edge. Soft language only: Not Demonstrated for production readiness; further review required for any real deployment.

Review confidence: Medium — strong primary research; PoC is illustrative, not a scored Core assessment.

How to Prevent It

Immediate (24–72h)

- Self-hosted workerd / Code Mode: upgrade to ≥ v1.20260619.1; rebuild images; restart.

- Inventory where Code Mode or “model writes TypeScript in a sandbox” is enabled; disable if unused.

- If self-hosted exposure was possible: rotate provider keys and tenant secrets reachable from that process.

- Block vulnerable PoC images from shared CI/dev clusters.

30 days

- Policy: Code Mode / exec-class tools require explicit enablement + owner (TOL-M3).

- Add injection eval gates before production agents that can emit code (SEC-M1).

- Attest runtime digests in deploy admission (SCI-M2).

- Document threat model: in-process isolate ≠ VM isolation (INF-M2 / AUTHZ-M1).

- Wire OBS alerts for sandbox native faults / unexpected process crashes during agent runs (OBS-M1).

Longer term

- Prefer architectures where tool orchestration does not require unbounded model-written native-reachable APIs—or isolate that tier in a stronger boundary (VM/container per untrusted program).

- Continuous patch pipeline for agent runtimes (treat workerd like a kernel for agents).

- Red-team Code Mode with injection → code-gen scenarios as a standing gate.

Engineering Lessons

1. Prompt injection is a code-execution entry point when the product asks the model to write programs.

2. Reusing a popular sandbox does not transfer its threat model—glue code outside the cage is still in scope.

3. Isolate ≠ tenant secrecy on shared-process designs; prove isolation or don’t claim it.

4. Exec-class agent features need high-impact gates—inventory and default-deny beat “it’s sandboxed.”

5. Patch the runtime binary, not only the agent prompts—SCI discipline applies to sandboxes too.

Could this happen to you?

- [ ] You use agents

- [ ] You expose tools to models

- [ ] You let models write/run code (Code Mode or similar)

- [ ] You self-host workerd / Workers-like isolates

- [ ] You run multi-tenant workloads in one process

- [ ] You pin neither runtime images nor agent frameworks

If two or more apply, treat the Relevant Controls table as a gate checklist this week.

Continues in the APRF Incident Corpus

- Related: MCP Sandbox Escape: CodeCall Host RCE (CVE-2026-67531) — different product, same sandbox-escape class.

- Related: OpenAI / Hugging Face sandbox-escape — containment failures under agent/CI pressure.

Soft CTA: self-attest against Core (questionnaire—not certification) at /aprf/assess/. For repo/evidence-backed runs, use the open APRF Auditor skill.

FAQ

Would assessing the public PoC repo with APRF have “caught” Cloudflare? No. The PoC is an educational vulnerable pin, not Cloudflare’s production service. A Core run would mostly show missing production evidence—not a vendor FAIL scorecard. The Check Point advisory and patch notes remain the source of truth for the bugs and fixes.

How is this different from the FrontMCP CodeCall escape? FrontMCP leaked live host objects (Zod) across a JS membrane. This research broke native glue under an in-process isolate used for agent-generated TypeScript—and also showed cross-tenant heap reads. Same failure class (sandbox escape), different mechanism and blast radius.

What can APRF miss outside the repo? Production Code Mode flags, managed vs self-hosted runtime versions, tenant packing, IAM, secret stores, real prompts, and whether L2 process sandbox limits were relevant to your threat model. Repo scans cannot invent that runtime truth.

Do we need CVEs to act? No. CPR + Cloudflare’s fixed workerd build are enough to inventory and patch. Lack of CVE IDs does not mean lack of severity—Cloudflare rated two issues Critical.

Is managed Workers “fine” now? CPR states managed production was fixed. Self-hosted and experimental Code Mode stacks still need version discipline. Confirm your actual binary/digest.

References

1. Yarden Porat, Check Point Research — When Agentic Glue Melts: Exploiting Cloudflare Code Mode and Workers

2. PoCs — yardenporat353/WhenAgenticGlueMeltsPOCs @ `34acae89a9e5dfdb689b19ff1e9f9ba954c1080c`

3. workerd — cloudflare/workerd (fixed release v1.20260619.1 per CPR / PoC README)

4. APRF 0.11.0 Check catalog + threat map — /aprf/spec/, /aprf/threats/

5. Related corpus — FrontMCP CVE-2026-67531 APRF Incident Analysis