What happened
vm2's NodeVM sandbox, when configured to allow the 'https' builtin module, exposes the host's actual https.globalAgent object to sandboxed code instead of an isolated proxy, because certain method calls bypass the read-only wrapper and are forwarded directly to the live host object.
Why it matters
vm2 is a common building block used by some JavaScript-based AI agent and code-interpreter tools to sandbox LLM-generated or user-submitted code; a host-object leak in the sandbox undermines the isolation guarantee that agentic code-execution features depend on, potentially enabling privilege escalation or lateral movement from an agent's code-exec sandbox to the host process.
Attack vector
When a NodeVM is explicitly configured to allow require('https'), the builtin module loader wraps the host module in a read-only proxy, but method calls like Agent.prototype.on() are forwarded to the underlying real host object rather than a sandboxed copy, exposing the host process's live https.globalAgent to sandboxed/untrusted code and enabling further sandbox-escape primitives.
Affected systems
vm2 versions 3.11.3 through 3.11.6
Mitigation
Upgrade to vm2 3.11.8 or later (which resolves this and 12 related sandbox-escape CVEs). vm2's maintainers also recommend avoiding same-process JS sandboxing as a sole security boundary — use separate processes/containers/VMs for genuinely untrusted code such as LLM-agent-generated scripts.