10 mincritical
When Agentic Glue Melts: Exploiting Cloudflare Code Mode and Workers
Check Point Research discovered five memory-corruption vulnerabilities in workerd, the open-source runtime underlying both Cloudflare Code Mode and Cloudflare Workers. Two were rated Critical by Cloudflare: a use-after-free in node:zlib's deflateParams() and a use-after-free in HTMLRewriter's AttributesIterator. The researchers demonstrated two end-to-end exploits: a cross-tenant secret theft via a URLPattern out-of-bounds read on the shared tcmalloc heap (bypassing V8 sandbox and MPK), and a Code Mode sandbox escape from prompt injection to native host RCE via the zlib UAF. All bugs operate on the tcmalloc native heap, which is explicitly outside the V8 sandbox cage and memory protection keys. Cloudflare's managed environment is patched; self-hosted deployments must update to workerd v1.20260619.1. No CVEs have been assigned.
Sens:■ Immediate
Detection / Hunteropenrouter
What Happened
Security researchers found five serious flaws in the software engine (called workerd) that powers both Cloudflare's serverless platform (Workers) and its AI agent feature (Code Mode). Two of these flaws were rated as Critical by Cloudflare. The researchers showed that a malicious program running on Cloudflare's shared infrastructure could read another customer's private data (like API keys) from the same server, and that an AI agent could be tricked via prompt injection into writing code that breaks out of its security container and runs directly on the server. This matters because Cloudflare Workers handles over 10% of all traffic on Cloudflare's network and is used by millions of developers. Cloudflare has already fixed these issues in its own managed systems. Anyone running their own copy of workerd should update to version v1.20260619.1 immediately.
Key Takeaways
- Five memory-corruption vulnerabilities discovered in workerd's native C++ JSG glue layer; two rated Critical by Cloudflare (zlib UAF and HTMLRewriter UAF)
- Cross-tenant secret theft demonstrated via URLPattern out-of-bounds read on the shared tcmalloc heap, which sits outside both the V8 sandbox (cage) and memory protection keys (MPK)
- Full Code Mode sandbox escape achieved from a single prompt injection to native host RCE via the zlib use-after-free, including shellcode execution in a fixed RWX memory region
- Cloudflare's managed Workers environment is fixed in production; self-hosted workerd/Code Mode deployments must update to v1.20260619.1
- Native API glue layers (JSG marshaling, Node reimplementation, tcmalloc heap) represent a significant attack surface that is not covered by V8 sandbox mitigations and had minimal prior public scrutiny
Affected Systems
- Self-hosted workerd deployments (all versions prior to v1.20260619.1)
- Cloudflare Workers (managed, fixed in production)
- Cloudflare Code Mode (managed, fixed in production)
- workerd with nodejs_compat compatibility flag enabled (zlib vulnerability)
- workerd URLPattern API (both urlpattern_original and Ada-backed implementations)
Vulnerabilities (CVEs)
None identified.
Attack Chain
- Initial Access: Attacker deploys a malicious Cloudflare Worker to the shared tenant pool, or uses prompt injection to steer an AI agent in Code Mode to write attacker-controlled TypeScript
- Exploitation: Attacker-controlled JavaScript triggers a memory-corruption vulnerability in workerd's native C++ glue layer (URLPattern OOB read for cross-tenant, or zlib UAF for sandbox escape)
- Privilege Escalation: Memory corruption primitive is leveraged on the tcmalloc heap, which is outside both the V8 sandbox cage and memory protection keys, enabling arbitrary read/write across the process address space
- Cross-Tenant Access / Sandbox Escape: Attacker sweeps the shared heap for another tenant's secrets (URLPattern path) or corrupts VFS FileImpl metadata to achieve arbitrary read/write and deploys shellcode to a fixed RWX memory region (zlib path)
- Execution: Hijacked function pointer (zlib write callback) redirects control flow to attacker shellcode, achieving native code execution on the host outside the V8 isolate
Detection Availability
- YARA Rules: No
- Sigma Rules: No
- Snort/Suricata Rules: No
- KQL Queries: No
- Splunk SPL Queries: No
- EQL Queries: No
- Other Detection Logic: No
No detection rules are provided in the article. Proof-of-concept exploit code was released as part of the Black Hat USA 2026 presentation but is not included in the blog post. Defenders should consult the Black Hat presentation materials for PoC details.
Detection Engineering Assessment
copy:
| Dimension | Rating | Rationale |
|---|---|---|
| EDR Visibility | Low | The exploits operate entirely within a single workerd process using in-process memory corruption. EDR agents monitoring host-level process behavior may see the final shellcode execution (reverse shell) but the memory-corruption primitives themselves are internal to the V8 isolate and tcmalloc heap, which is not typically visible to EDR. |
| Network Visibility | Low | The cross-tenant secret theft exploit operates entirely in-process with no network communication. The sandbox escape reverse shell would generate outbound network traffic, but only at the final stage. The initial exploitation and heap manipulation produce no network artifacts. |
| Detection Difficulty | Very Hard | The memory corruption occurs entirely within a single process's user-space heap. The V8 sandbox, MPK, and L2 sandbox are all bypassed via the tcmalloc heap which has no instrumentation. Detecting the exploitation requires visibility into native heap manipulation inside a running process, which most organizations do not have. The only potentially detectable stage is the final reverse shell connection from the sandbox escape path. |
Required Log Sources
- workerd process crash logs and core dumps
- V8 isolate telemetry and error reporting
- Host-level process execution logs for shellcode reverse shell detection
- Outbound network connection logs from workerd host processes
- Cloudflare Workers audit logs for anomalous Worker deployments
Hunting Hypotheses
copy:
| Hypothesis | Telemetry | ATT&CK Stage | FP Risk |
|---|---|---|---|
| Consider hunting for workerd processes initiating unexpected outbound network connections, which could indicate the sandbox escape reverse shell stage has been triggered | Host network connection logs, process network activity telemetry, outbound connection alerts from workerd or related processes | Execution | Medium - legitimate Workers may make outbound connections; focus on connections to unusual destinations or from processes that should be sandboxed |
| Consider hunting for workerd process crashes or abnormal terminations, which could indicate failed memory-corruption exploitation attempts during the URLPattern OOB or zlib UAF trigger | Process crash logs, core dump generation events, workerd restart events, application error logs | Exploitation | High - workerd crashes can occur from benign bugs, OOM conditions, or normal operational issues |
| Consider hunting for Workers or Code Mode programs that construct URLPattern objects with nested capture groups (e.g., patterns containing nested parentheses like (ab(cde))), which is the trigger for the OOB read vulnerability | Application-level logging of URLPattern construction, WAF or API gateway inspection of Worker code uploads, Code Mode prompt and generated code logging | Exploitation | Medium - nested regex groups are a legitimate pattern-matching technique; focus on patterns specifically designed to create group-count mismatches |
| Consider hunting for Workers that call handle.params() on zlib handles shortly after handle.write() with Z_NO_FLUSH, which is the specific sequence triggering the zlib use-after-free | Application-level instrumentation of node:zlib API calls, Code Mode generated code analysis, runtime API call tracing | Exploitation | Low - the specific sequence of write(Z_NO_FLUSH) followed by params() with pending data is unusual in normal compression workflows |
| Consider hunting for SQL queries in Durable Objects storage that use ALTER TABLE RENAME TO _cf_KV, which is the specific technique for bypassing the SQL authorizer to inject deserialized data | Durable Objects SQL query logs, storage.sql.exec call logging, database query audit trails | Exploitation | Low - renaming tables to _cf_KV-prefixed names is not a legitimate application pattern |
Control Gaps
- V8 sandbox (cage) does not cover the tcmalloc native heap where all exploit primitives operate
- Memory protection keys (MPK) do not protect tcmalloc allocations, confirmed by Cloudflare
- L2 process sandbox (namespaces + seccomp) does not prevent in-process memory corruption between tenants
- SQL authorizer in Durable Objects does not validate ALTER TABLE RENAME destination names
- No fuzzing or hostile-input testing for V8's structured-clone deserializer used by internal types
- JSG glue layer between JavaScript and native C++ had minimal public security scrutiny compared to V8 itself
Key Behavioral Indicators
- workerd process spawning unexpected child processes or initiating reverse shell connections
- URLPattern construction with nested capture groups creating group-count mismatches between V8 regex and URLPattern nameList
- Sequence of zlib handle.write() with Z_NO_FLUSH followed by handle.params() with changed level/strategy
- HTMLRewriter element handler that iterates attributes while simultaneously calling setAttribute in a loop to trigger reallocation
- Durable Objects SQL queries containing ALTER TABLE ... RENAME TO _cf_KV pattern
- VFS file operations with abnormally large position offsets indicating inflated data.size metadata
False Positive Assessment
Low - The exploit techniques described (nested URLPattern groups, zlib Z_NO_FLUSH + params() sequence, HTMLRewriter attribute iteration during setAttribute loops, ALTER TABLE RENAME TO _cf_KV) are highly specific and unlikely to occur in normal application behavior. The only stage with meaningful false positive risk is process crash detection, which can result from many benign causes.
Recommendations
Immediate Mitigation
defender takeaway
- Verify against your organization's incident response runbook and team escalation paths before acting. If you operate self-hosted workerd or Code Mode deployments, update to workerd v1.20260619.1 immediately to close all five vulnerabilities
- Consider auditing which of your services depend on self-hosted workerd and verify whether the nodejs_compat flag is enabled, as the zlib UAF requires this compatibility flag
- If you use Cloudflare's managed Workers or Code Mode, verify that no action is needed as production has been fixed, but consider reviewing your Worker deployments for any that may have been exploited during the vulnerability window
- Consider reviewing Durable Objects storage for any tables that may have been renamed to _cf_KV-prefixed names, indicating potential authorizer bypass exploitation
Infrastructure Hardening
- Evaluate whether enabling the V8 sandbox (cage) on self-hosted workerd deployments is feasible, noting that the specific FileImpl exploitation technique would not work as-is with the cage enabled, though the underlying UAF remains
- Consider implementing additional monitoring on the tcmalloc heap layer if your workerd deployment supports it, since this memory region is outside both the V8 sandbox and MPK protections
- If running self-hosted workerd, consider evaluating whether the L2 process sandbox (Linux namespaces + seccomp) is properly configured to limit the blast radius of any sandbox escape
- Consider reviewing whether the fixed RWX mapping at 0xaaaaf0000000 can be disabled or randomized in your workerd build configuration to raise the bar for the sandbox escape exploit chain
User Protection
- Consider implementing additional input validation on any Code Mode or AI agent integrations that accept untrusted prompts, treating prompt injection as a code-execution entry point
- If your organization uses Cloudflare Workers for sensitive workloads, consider evaluating whether co-located tenants pose a risk and whether dedicated isolates or alternative deployment models are available
- Consider monitoring for any unexpected outbound connections from workerd host processes that could indicate a successful sandbox escape reverse shell
Security Awareness
- Consider incorporating the concept that AI-generated code in Code Mode is untrusted code execution into your security awareness training, treating prompt injection as equivalent to code injection
- Consider educating development teams that the native API glue layers in JavaScript runtimes (not just V8 itself) are part of the security boundary and deserve security review
- Consider adding workerd version monitoring to your vulnerability management program, as this runtime had minimal public scrutiny and may have additional undiscovered vulnerabilities
MITRE ATT&CK Mapping
MITRE ATT&CK Mapping5 techniques
Tactic
Execution
Tactic
Privilege Escalation
Tactic
Lateral Movement
Additional IOCs
- Other:
0xaaaaf0000000- Fixed RWX (read-write-execute) memory mapping address in self-hosted workerd (V8 sandbox off) used for shellcode deployment during sandbox escape; not an IOC but a notable technical indicator for exploit detection
