CVE-2026-100723 in vm2
Summary
by MITRE • 09/27/2026
vm2 before 3.12.2 does not apply its Buffer backing-store ownership invariant (byteOffset === 0 and buffer.byteLength === length) to Buffers returned from host builtin modules. When an application explicitly exposes Node's zlib module through NodeVM's builtin allowlist (require: { builtin: ['zlib'] }), zlib.deflateSync can return a Buffer backed by Node's shared small-buffer pool whose .buffer is the entire pool. Untrusted guest code can construct a full-width view of that ArrayBuffer (Buffer.from(result.buffer, 0, result.buffer.byteLength)) to read and modify bytes belonging to unrelated host buffers, disclosing and corrupting host-realm memory across the sandbox boundary.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/27/2026
The vulnerability identified in versions of vm2 prior to 3.12.2 represents a critical failure in the isolation boundaries between untrusted guest code and the trusted host environment within Node.js applications utilizing virtual machines for sandboxing. The core technical flaw stems from an incorrect implementation of Buffer backing-store ownership invariants, specifically the expectation that byteOffset equals zero and buffer.byteLength matches the allocated length when returning buffers to the caller. This invariant is not enforced for Buffers originating from host builtin modules exposed through the allowlist mechanism. When a developer explicitly permits access to Node's zlib module via the require configuration with builtins such as ['zlib'], functions like deflateSync may return Buffer objects that are backed by Node.js internal memory pools rather than freshly allocated isolated memory regions.
In this specific scenario, the returned buffer is often mapped against Node's shared small-buffer pool. This means the underlying ArrayBuffer associated with the guest-visible buffer actually spans a much larger contiguous block of host memory managed internally by Node.js for performance optimization. Because vm2 fails to enforce strict ownership rules or create proper copies that isolate this data, untrusted code operating within the virtual machine can exploit this architectural oversight. By constructing a full-width view of the underlying ArrayBuffer using methods such as Buffer.from with explicit offset and length parameters set to cover the entire pool size, guest code gains direct read and write access to memory segments belonging to unrelated host buffers.
The operational impact of this vulnerability is severe, constituting both an information disclosure and data corruption risk that breaches the fundamental security model of sandboxing. An attacker controlling untrusted input processed within the vm2 context can exfiltrate sensitive data stored in adjacent host memory regions, potentially including authentication tokens, private keys, or other application secrets residing in nearby buffers. Furthermore, the ability to write arbitrary bytes into these shared memory segments allows for heap corruption attacks that can destabilize the Node.js runtime process, leading to denial of service conditions or enabling further exploitation vectors such as arbitrary code execution if combined with additional vulnerabilities like type confusion bugs common in JavaScript engines and C++ addons interacting with V8.
This issue aligns closely with CWE-125 Out-of-bounds Read and CWE-787 Out-of-bounds Write, as the attacker accesses memory outside the intended bounds of the sandboxed buffer object. From a threat modeling perspective using MITRE ATT&CK for Enterprise, this behavior facilitates Data Exfiltration from Local System via Memory Access techniques (T1005) and potentially contributes to Privilege Escalation or Defense Evasion depending on how the corrupted memory affects subsequent execution flows. The failure to properly isolate buffer ownership violates principles of least privilege and secure sandboxing where guest code should never have direct pointer-level access to host memory structures without explicit copying mechanisms that ensure data independence.
Mitigation strategies must prioritize immediate upgrading to vm2 version 3.12.2 or later, which addresses this specific invariant enforcement issue by ensuring that buffers returned from builtin modules are properly isolated and do not expose the underlying shared pool structure to guest code. In environments where upgrading is not immediately feasible, developers should avoid exposing high-risk built-in modules like zlib directly through the allowlist if possible, opting instead for wrapper functions that process data in a controlled manner before returning results. Additionally implementing strict input validation on any data passed into vm2 contexts and monitoring for unusual memory access patterns can provide secondary layers of defense against exploitation attempts targeting this class of sandbox escape vulnerabilities.