Vm2 (<= 3.10.5) — CraftedSignal Threat Feedhttps://feed.craftedsignal.io/products/vm2--3.10.5/Trending threats, MITRE ATT&CK coverage, and detection metadata — refreshed continuously.Hugoenhello@craftedsignal.iohello@craftedsignal.ioThu, 07 May 2026 04:26:39 +0000vm2 Sandbox Escape via Buffer.alloc Memory Exhaustionhttps://feed.craftedsignal.io/briefs/2024-01-03-vm2-buffer-alloc-dos/Thu, 07 May 2026 04:26:39 +0000hello@craftedsignal.iohttps://feed.craftedsignal.io/briefs/2024-01-03-vm2-buffer-alloc-dos/A vulnerability exists in the vm2 npm package (<= 3.10.5) where sandboxed code can bypass the timeout protection by calling Buffer.alloc() with an arbitrary size, leading to memory exhaustion on the host system.The vm2 npm package, a sandbox environment for executing untrusted JavaScript code, is susceptible to a denial-of-service attack. Specifically, versions 3.10.5 and earlier allow sandboxed code to bypass the configured timeout by calling Buffer.alloc() with a large, attacker-controlled size. Because Buffer.alloc is a synchronous C++ native call, vm2’s timeout option cannot interrupt it. This bypass enables a malicious actor to exhaust the host system’s memory, leading to a crash. This is particularly impactful in memory-constrained environments like Docker containers, Kubernetes pods, and serverless functions (e.g., AWS Lambda), where a single request can trigger an out-of-memory (OOM) error, resulting in service disruption. The amplification factor can be significant, with a small HTTP request (e.g., 100 bytes) triggering a large memory allocation (e.g., 100MB+).

Attack Chain

  1. An attacker sends a malicious HTTP request to an application using vm2.
  2. The request contains JavaScript code intended for execution within the vm2 sandbox via an API endpoint (e.g. /api/execute).
  3. The malicious JavaScript code leverages Buffer.alloc() with a large size (e.g., Buffer.alloc(1024*1024*100)).
  4. The Buffer.alloc() call is proxied to the host environment through the bridge proxy in lib/bridge.js without size validation.
  5. The host system attempts to allocate the requested memory synchronously.
  6. In memory-constrained environments, the allocation exceeds available resources.
  7. The Node.js process crashes with a FATAL ERROR: Reached heap limit due to JavaScript heap exhaustion.
  8. The application becomes unavailable, resulting in a denial-of-service condition.

Impact

This vulnerability allows for denial-of-service (DoS) attacks. A single HTTP request containing malicious JavaScript code can crash the host Node.js process by exhausting its memory. The severity of the impact depends on the environment. In memory-constrained environments such as Docker containers or Kubernetes pods, the attack causes immediate process termination. Even in unconstrained environments where the memory allocation might succeed and be reclaimed, the attack can cause temporary performance degradation. The vulnerability affects all applications using vm2 version 3.10.5 or earlier in its default configuration.

Recommendation

  • Upgrade to a patched version of the vm2 package that addresses this vulnerability.
  • Apply rate limiting to the API endpoints that execute code within the vm2 sandbox to mitigate the impact of potential attacks.
  • Monitor application logs for FATAL ERROR: Reached heap limit messages, which may indicate exploitation attempts.
  • Deploy the Sigma rule to detect suspicious calls to Buffer.alloc with unusually large sizes.
  • Implement resource limits (e.g., memory limits) for processes running vm2 to prevent complete system exhaustion.
]]>highadvisorysandbox-escapedosmemory-exhaustionvm2vm2 Sandbox Escape via Promise Constructor Unhandled Rejectionhttps://feed.craftedsignal.io/briefs/2024-01-vm2-sandbox-escape/Wed, 03 Jan 2024 12:00:00 +0000hello@craftedsignal.iohttps://feed.craftedsignal.io/briefs/2024-01-vm2-sandbox-escape/A sandbox escape vulnerability exists in vm2 versions 3.10.5 and earlier that allows sandboxed code to crash the host Node.js process via a Promise constructor that triggers an unhandled rejection, leading to a denial-of-service condition.A sandbox escape vulnerability has been identified in vm2 versions 3.10.5 and earlier. This vulnerability enables malicious sandboxed code to crash the host Node.js process through a crafted Promise constructor that triggers an unhandled rejection. The root cause lies in the fact that Promise executor errors are not adequately caught and sanitized before they can propagate as unhandled rejections to the host process. This results in an immediate process crash, effectively causing a denial-of-service condition. Notably, the allowAsync: false setting, intended to mitigate asynchronous code execution, does not prevent this vulnerability and, paradoxically, can exacerbate the issue by blocking .catch() handlers, thereby guaranteeing that rejections remain unhandled. The CVE-2026-22709 patch (v3.10.2) only sanitized .then() and .catch() callback chains but left the executor-to-unhandledRejection path completely open.

Attack Chain

  1. Attacker crafts malicious JavaScript code designed to be executed within a vm2 sandbox.
  2. The malicious code constructs a Promise object using the Promise constructor.
  3. Within the Promise executor function, an Error object is created.
  4. The Error object’s name property is set to a Symbol().
  5. The code then attempts to access the stack property of the Error object, triggering V8’s internal FormatStackTrace function.
  6. FormatStackTrace attempts Symbol.toString(), resulting in a host-realm TypeError.
  7. Because no .catch() handler is attached, the error becomes an unhandled rejection.
  8. The unhandled rejection propagates to the host Node.js process, causing it to crash.

Impact

Successful exploitation of this vulnerability leads to a denial-of-service (DoS) condition. A single malicious request can crash the entire host Node.js process, disrupting service for all concurrent users. The persistent nature of this DoS, coupled with the ease of triggering it, renders the application unavailable even with standard recovery mechanisms like Docker restart policies or Kubernetes liveness probes. The attacker only needs to send a small request (approximately 150 bytes) to bring down the entire server, demonstrating a high amplification factor. All applications using vm2 are vulnerable, regardless of the allowAsync setting.

Recommendation

  • Upgrade to a patched version of vm2 that addresses this vulnerability. As of this writing, no patched version exists, but monitor the project for updates.
  • Implement rate limiting on API endpoints that execute user-provided JavaScript code to reduce the impact of DoS attacks.
  • Deploy the Sigma rule “Detect vm2 Sandbox Escape Attempt via Symbol Error Name” to identify attempts to exploit this vulnerability within your environment.
  • Monitor application logs for unhandled promise rejections, which could indicate exploitation attempts.
  • Consider implementing a custom error handler within the vm2 sandbox to catch and sanitize errors before they can propagate to the host process.
]]>highadvisoryvm2sandbox-escapedenial-of-servicenodejs