vm2 EUVD-2026-81598

Two conditions must both hold: (1) the host application runs attacker-controlled/untrusted JavaScript inside a vm2 NodeVM (the standard vm2 threat model), and (2) the embedder relies on vm.freeze() or vm.readonly() to protect host objects that are reachable from the sandbox - if no host objects are frozen/readonly, there is nothing to bypass and no impact. Exploitation is limited by high attack complexity (AC:H) and a present attack requirement (AT:P), and the impact ceiling is low: integrity-only mutation of read-only properties, with no confidentiality or availability impact and no code execution. The vulnerability is fixed in vm2 3.11.7; versions 3.9.6 through 3.11.6 are affected. vm2 being deprecated further narrows realistic exposure to legacy deployments.

This is a genuinely moderate, not critical, issue and the vendor CVSS 4.0 score of 6.3 (medium) reflects that honestly. The vector AV:N/AC:H/AT:P/PR:N/UI:N with only VI:L and SI:L (integrity-low on both the vulnerable and a subsequent system) tells the real story: this is an integrity-only protection bypass with no confidentiality (VC:N) or availability (VA:N) impact, and it carries a high attack complexity plus a present attack requirement (AC:H/AT:P), meaning exploitation is conditional rather than trivial. Exploitation status is no public exploit identified at time of analysis - there is no EPSS score, no CISA KEV listing, and no confirmed POC in the provided data (though the GHSA-633r-hq9m-c4ff advisory may contain technical detail). PR:N indicates no authentication is needed by the sandboxed script, which is expected: in the vm2 threat model the attacker IS the untrusted script already running inside the sandbox. Critically, unlike sibling vm2 CVEs in this wave (e.g. [[cve-2026-92956]], [[cve-2026-92957]], [[cve-2026-92955]]) this is NOT a full sandbox escape or RCE - it only lets sandboxed code defeat vm.freeze()/vm.readonly() and mutate host properties the embedder marked read-only. Real-world priority is therefore LOW-to-MEDIUM: it only matters to embedders who both run untrusted code in vm2 AND rely on freeze/readonly as a security boundary. The bigger contextual signal is that vm2 is deprecated and unmaintained, so any deployment is already outside vendor support.

An application runs untrusted plugin/user JavaScript inside a vm2 NodeVM and exposes a host configuration or capability object that it froze via vm.freeze() or vm.readonly(), trusting the sandbox to keep it immutable. The sandboxed script calls Object.getOwnPropertyDescriptor() or __lookupSetter__() on that object to retrieve the host-realm setter function, then invokes it directly to overwrite the supposedly read-only property. No public exploit code is identified, and the high attack complexity means the technique depends on the embedder actually having frozen host objects reachable from the sandbox.