vm2 EUVD-2026-81591

Requires that the host application (a) runs attacker-supplied JavaScript inside a vm2 NodeVM instance, AND (b) has explicitly added both the 'tls' and 'url' modules to the sandbox builtin allowlist - this is not vm2's default builtin set. Given those, the sandbox calls tls.setDefaultCACertificates() to overwrite the process-wide CA store. Realized impact is further LIMITED by the need for the host process to make subsequent outbound HTTPS connections and for the attacker to hold a network man-in-the-middle position to present the now-trusted forged certificate; without that positioning the trust-store change alone yields no data. Affects vm2 3.11.3 up to but not including 3.11.7.

This is a config-gated sandbox-integrity flaw, not a default-configuration remote exploit. The vendor CVSS 4.0 vector (AV:N/AC:L/PR:N/UI:N/VC:H/VI:H/VA:L/SC:H/SI:H/SA:L = 10.0) drives the maximum score largely on the scope-change metrics (SC:H/SI:H), reflecting that sandboxed code poisons the host process trust store. However, the score is optimistic on two counts. First, exploitation is gated on a non-default deployment: the operator must have exposed both the 'tls' AND 'url' builtins to NodeVM sandbox code, and must already be running untrusted JavaScript in vm2 (the inherent vm2 threat model). Second, PR:N/AC:L understate reality - the described technique (URLSearchParams host-realm arrays → tls.setDefaultCACertificates) is only the first stage; actual impact requires the host process to subsequently make outbound HTTPS calls AND the attacker to occupy a network man-in-the-middle position to present the now-trusted forged certificate, which is closer to AC:H. No EPSS score, no CISA KEV listing, and no public POC are present in the input, so there is no evidence of active or automated exploitation. Net: high theoretical severity for anyone already exposing tls/url builtins to untrusted sandbox code, but a narrow precondition set makes real-world priority moderate rather than critical. Verify the exact builtin allowlist in your deployment before triaging as urgent.

An application runs untrusted user JavaScript inside a vm2 NodeVM and has allowed the 'tls' and 'url' builtins into the sandbox. The attacker's script calls tls.setDefaultCACertificates() (using URLSearchParams to construct the required host-realm array) to inject an attacker-controlled CA into the process-wide trust store, so any later HTTPS request the host makes will silently trust the attacker's forged certificates, enabling interception and injection of that traffic. No public exploit code is identified at time of analysis, though the vendor advisory (GHSA-98xx-8mx4-x7cm) describes the mechanism.