vm2 EUVD-2026-81611

The application must use vm2 (<=3.11.5) to execute untrusted/attacker-controlled JavaScript inside a VM sandbox - this is vm2's normal use case, so no special product configuration is required. The bufferAllocLimit option does NOT need to be set: default new VM() and any configuration are affected because the ArrayBuffer/SharedArrayBuffer/TypedArray constructors are never subject to the cap. The only real prerequisite/limiter is the vm2 trust boundary itself: the attacker must already be able to submit code into the sandbox. Impact is materially worse in memory-constrained runtimes (Docker/Kubernetes/AWS Lambda) where OOM-kill is triggered by smaller allocations.

This is a real but bounded issue whose severity is entirely a function of vm2's threat model. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N/VA:H, score 8.7) is availability-only - VC:N/VI:N confirm no confidentiality or integrity impact, consistent with CWE-770 (uncontrolled resource consumption). The 'network/unauthenticated' framing is technically correct only because vm2's entire purpose is to execute untrusted attacker-supplied JavaScript; the attacker must already be able to run code inside the sandbox, so this is a sandbox resource-control bypass, not a classic remote pre-auth flaw. Exploitation status: publicly available exploit code exists (a working POC is embedded in the GHSA advisory) but there is no EPSS score and no CISA KEV listing, so there is no evidence of active in-the-wild exploitation - POC availability and active exploitation are distinct signals and only the former is present. Practical severity is amplified in memory-constrained deployments (Docker/K8s/Lambda) where a single synchronous allocation can OOM-kill the host process, but limited by the fact that it grants only DoS, not code execution or data theft (contrast the RCE escape in the same product, CVE-2026-92934). Net: a legitimate defense-in-depth bypass worth patching for anyone relying on bufferAllocLimit, but availability-only and gated behind already running attacker JavaScript.

An application uses vm2 to sandbox user-submitted JavaScript and sets bufferAllocLimit expecting memory-abuse protection. An attacker submits new ArrayBuffer(1024*1024*1024) (or a loop of TypedArray allocations), which bypasses the cap and allocates gigabytes of host RSS in one synchronous call that vm2's timeout cannot interrupt, OOM-killing the process. A working POC demonstrating this bypass is published in the GHSA advisory.