vm2 NodeVM Sandbox Escape via https.globalAgent Exposes Host TLS Traffic and Credentials (CVE-2026-92940, CVSS 10.0)

A new GitHub Security Advisory (GHSA-h85j-hv3c-qfgq) discloses a critical vulnerability in vm2 3.11.6, tracked as CVE-2026-92940 with a reported CVSS score of 10.0 and a public proof-of-concept.

What was reported

According to the advisory, when a NodeVM sandbox is configured to allow the built-in https module, sandboxed code can subscribe to the free event on the host process's real https.globalAgent — the shared connection-pooling agent used by default for outbound HTTPS requests. Because vm2's read-only wrapper forwards method calls like .on() to the underlying host object, the sandbox can register a live listener on a process-global singleton rather than a sandbox-local instance.

The advisory describes that this lets sandboxed code receive the connection options and the live TLSSocket any time an unrelated host HTTPS request releases a pooled connection — exposing Authorization headers, request destinations, and plaintext response data from traffic the sandbox was never given. The reported PoC chains this into reading a host bearer token, capturing a plaintext response body, and replaying the stolen token to perform an attacker-chosen authenticated action against the host's private service.

Why it matters for defenders

This is a sandbox-escape-adjacent issue: any application embedding vm2 to run untrusted or semi-trusted JavaScript — and granting that sandbox access to the https builtin — may be exposing its own authenticated HTTP traffic to that code, even though the host never explicitly passed credentials, sockets, or requests into the sandbox. The advisory notes this effect specifically occurs when the host relies on the default global HTTPS agent rather than supplying a dedicated Agent per request. In multi-tenant setups where several sandboxes and host workloads share one Node.js process, this could also cross tenant boundaries.

What defenders should watch for or do now

• Inventory any services using vm2's NodeVM with the https (or related network) builtin enabled for sandboxed/untrusted code, and treat that configuration as high risk until patched or mitigated.
• As an interim mitigation per the advisory's root-cause analysis, ensure host code issues sensitive HTTPS requests with an explicit, dedicated agent rather than relying on the default https.globalAgent, which is the specific object this issue bridges into the sandbox.
• Review sandbox configurations to restrict or remove the https builtin from untrusted NodeVM instances where network access isn't strictly required.
• From a hunting perspective, consider auditing application logs for anomalous authenticated requests originating from sandbox/plugin-execution code paths, or unexpected reuse of service tokens across unrelated request contexts.
• Watch vendor/project channels for an official patched release of vm2 and prioritize upgrading embedding applications once available.

This is a freshly disclosed advisory and still developing — full remediation guidance and any official fix should be confirmed against the source. See the original GitHub Security Advisory for the complete technical details and PoC: GHSA-h85j-hv3c-qfgq.