CVE-2026-92952: vm2 3.11.4 through 3.11.6 Sandbox Symbol Filtering Bypass
vm2 versions 3.11.4 through 3.11.6 incompletely filter Node.js registered internal symbols across the sandbox boundary. The extraction filters in lib/setup-sandbox.js and the cross-realm symbol checks and write traps in lib/bridge.js use a fixed list of known dangerous registered symbols that omits nodejs.stream.disturbed and nodejs.stream.errored, which are exposed on host WebStream prototypes on newer Node.js releases (validated on Node.js v25.8.0). When the embedder exposes a host WebStream object and the host stream/web module to the sandbox, sandbox code can obtain the real host symbols via Object.getOwnPropertySymbols(streamWeb.ReadableStream.prototype) and use them as write keys on host stream objects, corrupting host-visible stream state — for example making stream.Readable.isDisturbed() return false for an already-consumed stream. This can bypass host logic that relies on Node's public stream-state helpers to enforce one-shot body consumption, reject errored streams, or decide whether a stream is safe to hand to another component. It is not a host code-execution primitive in the reported proof of vulnerability. This is an incomplete fix for the earlier nodejs. symbol filtering issue. Fixed in vm2 3.11.7.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
vm2to a version that resolves this vulnerability.Fixed in 3.11.7 - Upgrade
Upgrade
vm2to a version that resolves this vulnerability.Fixed in 3.11.7Patch vm2 3.11.7
Event History
Frequently Asked Questions
Which deployments are exposed to this issue?
Deployments using vm2 versions 3.11.4 through 3.11.6 are exposed when the embedder makes both a host WebStream object and the host stream/web module available to sandboxed code. The reported behavior was validated on Node.js v25.8.0, where the relevant symbols are present on host WebStream prototypes.
What does an attacker need to exploit the flaw?
An attacker needs the ability to run code inside the vm2 sandbox and access to the exposed host WebStream object and stream/web module. The sandbox code can enumerate symbols on streamWeb.ReadableStream.prototype and use the omitted registered symbols as write keys on host stream objects.
What is the practical impact of exploitation?
An attacker can corrupt host-visible stream state, such as causing stream.Readable.isDisturbed() to report false for a stream that has already been consumed. This may bypass application logic that enforces one-time body consumption, rejects errored streams, or decides whether a stream is safe to pass to another component; the reported proof of vulnerability does not provide host code execution.
What can be done if updating vm2 is not immediately possible?
Do not expose host WebStream objects or the host stream/web module to vm2 sandbox code. Review any host decisions based on public Node stream-state helpers, especially checks for consumed or errored streams, because those results may be manipulated when the vulnerable exposure exists.