Critical vm2 Flaw Lets Sandboxed Code Read and Write Host Memory via Shared Buffer Pool

A newly disclosed GitHub Security Advisory (GHSA-fcqc-726x-5wfc, tracked as CVE-2026-92947) reports that the vm2 Node.js sandboxing library exposes the host process's shared Buffer allocation pool to code running inside the sandbox. Node's small-allocation helpers — Buffer.allocUnsafe(), Buffer.from(array), Buffer.from(string), and Buffer.concat() — reuse a pooled ArrayBuffer that is shared between host and sandbox contexts. According to the advisory, sandboxed code can read uninitialized or recently-freed host memory out of this pool, and in some cases write back into it, with a public proof-of-concept against [email protected] confirming host-realm string data leaking into the sandbox.

This matters because vm2 is widely used specifically to run untrusted or third-party JavaScript in isolation — plugin systems, code-execution-as-a-service platforms, CI/build tooling, and bots that evaluate user-submitted scripts. A sandbox escape at the memory-disclosure level defeats the core security guarantee these tools are deployed for: the advisory's reported CVSS of 10.0 and "poc-public" exploit status reflect that this is a full breach of the trust boundary, with potential for sensitive data exposure (secrets, tokens, or other host-process memory contents) and, per the advisory, possible denial-of-service from writes into the shared buffer.

Defenders should first inventory where vm2 is in use — directly or as a transitive dependency — anywhere untrusted code is executed, and treat any such sandbox as compromised rather than trusted until a fix is confirmed. At a high level, watch for anomalous process behavior or data exfiltration originating from services known to run vm2 sandboxes, and consider hunting for unexpected network egress or file access immediately following sandboxed script execution. Given vm2 has had prior sandbox-escape issues, longer-term mitigation should include evaluating migration to actively maintained isolation mechanisms (e.g., separate OS processes/containers or V8 isolates with no shared heap) rather than relying solely on an in-process JS sandbox for untrusted code.

This is a same-day, developing item — no vendor patch status or further vendor commentary is reflected in the advisory as captured here. Track the original GitHub Security Advisory for updates: GHSA-fcqc-726x-5wfc.