vm2 EUVD-2026-87856

Exploitation requires the embedding application to explicitly expose Node's zlib module to the sandbox via NodeVM's builtin allowlist (require: { builtin: ['zlib'] }) - this is a NON-DEFAULT configuration; a stock vm2 sandbox without zlib exposure is not affected via this vector. It also requires the application to run attacker-controlled/untrusted guest JavaScript in vm2 (vm2's intended use), and for host secrets to be co-resident in Node's shared 64 KiB small-buffer pool at exploitation time. Limiting factors: the vulnerable product must be a pre-3.12.2 vm2 instance, zlib must be allowlisted, and success against specific host secrets depends on pool residency timing. No user interaction beyond running the untrusted script is needed.

The vendor CVSS 4.0 base score is 6.9 (Medium), and the vector is internally telling: it scores the vulnerable system as VC:N/VI:N/VA:N but the subsequent (host) system as SC:H/SI:L - correctly modeling this as a sandbox-to-host escape where the damage lands on the host realm, not the sandbox. AT:P (Attack Requirements: Present) captures the essential non-default gate: exploitation only becomes possible when the embedding application explicitly adds Node's zlib to the NodeVM builtin allowlist (require: { builtin: ['zlib'] }), which is NOT a default configuration. PR:N is accurate in the sense that guest script code is inherently untrusted and unauthenticated within the sandbox threat model - that is vm2's entire purpose. There is NO EPSS score and NO CISA KEV listing in the provided data, so there is no signal of active or widespread exploitation; the reporter is VulnCheck and the advisory (GHSA-489w-w794-jq94 / the code references GHSA-fcqc-726x-5wfc) contains proof-grade mechanics and canonical exploit snippets, so publicly available exploit code effectively exists. This is a real defense-in-depth failure with confirmed patch and clear technical PoC, but real-world priority is tempered by three factors: (1) the non-default zlib exposure requirement, (2) vm2 being officially deprecated (maintainers recommend migration away from it), and (3) no exploitation-in-the-wild signal. Note the CWE tagging: the advisory explicitly cites CWE-200 (disclosure) PLUS CWE-787 (out-of-bounds write / corruption), so labeling this purely 'Information Disclosure' understates the integrity impact - the sandbox can both read AND overwrite neighboring host buffers (secrets, tokens, DB rows).

An application uses vm2 (< 3.12.2) to run untrusted third-party or user-submitted JavaScript and has explicitly exposed Node's zlib module to the sandbox via require: { builtin: ['zlib'] }. Because zlib.deflateSync returns a Buffer backed by Node's shared 64 KiB small-buffer pool, the guest reads result.buffer to obtain the entire pool ArrayBuffer, builds a full-width Buffer.from(pool, 0, 65536) view, and reads/overwrites host secrets (session tokens, DB rows, decrypted material) that happen to share the pool. Canonical exploit code exists in the vendor advisory (VulnCheck / GHSA), including the diagnostic Buffer.from([0]).buffer.byteLength === 65536 leak proof.