Friday, 16 October 2026
1 agent hack today▼ 7 vs yesterday (8)

vm2 sandbox leaks host HTTPS tokens via shared Node agent

A GitHub advisory published on 1 October 2026 says code running inside vm2 3.11.6 can read the host application's bearer tokens and decrypted traffic.

By The Agentic Times ·

A locked glass box contains running machinery, yet invisible threads slip through its walls carrying glowing authentication keys back to the outer chamber.
A locked glass box contains running machinery, yet invisible threads slip through its walls carrying glowing authentication keys back to the outer chamber. · Illustration: The Agentic Times

Sandboxed code running in vm2 3.11.6 can steal the host application's HTTPS credentials and read its encrypted traffic in plaintext, according to a GitHub security advisory published on 1 October 2026. The flaw is tracked as CVE-2026-92940 under advisory GHSA-h85j-hv3c-qfgq and affects the npm package vm2, a sandbox used to run untrusted JavaScript inside Node.js processes.

The problem lies in how vm2 hands built-in Node modules to sandboxed code. When a NodeVM sandbox is explicitly allowed to require the https module, the advisory says vm2 passes through the host process's real https.globalAgent — the connection pool shared by every HTTPS request in the Node thread that does not supply its own agent. vm2 wraps the module as read-only, but the advisory notes that read-only wrapping only blocks property assignment. Calling a method such as .on() to register an event listener is forwarded to the real host object, where it mutates shared state.

That is enough to break the boundary. The advisory describes sandbox code subscribing to the agent's free event, which fires when a pooled connection is released after a request completes. Node supplies the listener with the TLS socket and the request options used for that connection. In a contained test described in the advisory, sandbox code that was allowed only the https builtin read the host's bearer token from the request headers, learned the private service hostname and port, attached a data listener to the released TLS socket and read the next host response body in plaintext, then sent an attacker-chosen authenticated POST using the stolen token and received confirmation that the service accepted the action.

The advisory stresses that none of this data was passed into the sandbox by the host application. "The host application never passed its credentials, request, response, socket, or destination into the sandbox," it states. They crossed the boundary only because vm2 exposes the process-global agent rather than a sandbox-local network module.

The listed impact is broad. According to the advisory, an attacker able to submit code to a NodeVM with https allowed can steal Authorization, Cookie, API-key and proxy-authorisation values, discover internal service hostnames and ports, read response headers and bodies on reused TLS connections, capture client-certificate and private-key options when the host supplies them through request options, perform authenticated actions with stolen credentials, and write to or destroy live host sockets to disrupt unrelated traffic. Where several sandboxes and host workloads share one process, the advisory says the issue can cross tenant boundaries.

The advisory frames this as the same class of problem for which other host builtins are already blocked. vm2's dangerous-builtin filter does not classify https as process-global, it says, because the module also offers legitimate network APIs that a sandbox may reasonably use. The suggested fix is for vm2 to stop exposing the host singleton and instead provide a sandbox-local module facade with its own agent.

A proof-of-concept is attached to the advisory. It runs a loopback HTTPS server with a temporary certificate and checks for four markers, including the leaked token and the server's acceptance of the attacker-chosen action. The advisory says the test fails unless both the confidentiality and integrity effects occur.

Hosts that supply a separate private agent for every sensitive HTTPS request avoid the shared singleton, the advisory notes, but that is not Node's default behaviour.

Sources

  1. github.comhttps://github.com/advisories/GHSA-h85j-hv3c-qfgq