The vulnerability in vm2 allows code running in a sandboxed environment to forcibly manipulate the host application's TLS trust store. By calling tls.setDefaultCACertificates() from the sandbox, attackers can replace the global list of trusted certificate authorities with ones of their choosing. This enables subsequent HTTPS requests from the host process to accept attacker‑controlled certificates, creating a path for man‑in‑the‑middle attacks, data exfiltration, and credential compromise. The weakness arises from incorrect authorization (CWE-732) permitting unrestricted access to the node tls module from restricted code.

Vulnerable versions are vm2 3.11.3 through 3.11.6, distributed by patriksimek. The issue manifests when the module exposes the host's tls API to sandboxed code that has access to the tls and url built‑ins. The fix is implemented in version 3.11.7, which removes the unprotected exposure of the tls module.

The CVSS score is 10.0, indicating an exploitable vulnerability with full confidentiality, integrity, and availability impact. Although the EPSS score is not available, the high CVSS combined with the ease of manipulation via NodeVM and the lack of KEV listing suggests that a motivated attacker could exploit it. The attacker must be able to inject JavaScript into the vm2 sandbox with access to the tls and url modules; once this is achieved, the exploit can replace the system certificates and hijack traffic for any HTTPS client used by the host.