CVE-2026-92953

vm2 TypedArray/ArrayBuffer Intrinsic Mutation Sandbox Escape (CVE-2026-92953)

Initial Access Execution Last updated:

Detects usage and exploitation risk of vm2 versions 3.11.0 through 3.11.7, which contain an incomplete fix for host-prototype pollution. The default VM allows sandboxed code to mutate host TypedArray and ArrayBuffer intrinsics, enabling prototype pollution that can lead to sandbox escape and arbitrary code execution on the host (CVSS 10.0). This detection surfaces vulnerable vm2 installs via package manifests and SCA telemetry, and identifies runtime behavior consistent with intrinsic mutation attempts within Node.js processes that embed vm2.

Vulnerability Intelligence

Public PoC

What is CVE-2026-92953 vm2 TypedArray/ArrayBuffer Intrinsic Mutation Sandbox Escape (CVE-2026-92953)?

vm2 TypedArray/ArrayBuffer Intrinsic Mutation Sandbox Escape (CVE-2026-92953) (CVE-2026-92953) maps to the Initial Access and Execution tactics — the adversary is trying to get into your network in MITRE ATT&CK.

This page provides production-ready detection logic for vm2 TypedArray/ArrayBuffer Intrinsic Mutation Sandbox Escape (CVE-2026-92953), covering the data sources and telemetry it touches: Microsoft Defender for Endpoint - Software Inventory, Microsoft Defender for Endpoint - Process Events. The queries below are rated critical severity at medium confidence, and ship for 7 SIEM platforms — KQL, SPL, Elastic, QRadar, Sumo, YARA-L, LogScale.

MITRE ATT&CK

Tactic
Initial Access Execution
Microsoft Sentinel / Defender
kusto
// Detect vulnerable vm2 package via Defender for Endpoint software inventory
DeviceTvmSoftwareInventory
| where SoftwareVendor =~ "npm" and SoftwareName =~ "vm2"
| extend ver = parse_version(SoftwareVersion)
| where ver >= parse_version("3.11.0") and ver <= parse_version("3.11.7")
| project DeviceName, SoftwareName, SoftwareVersion, DeviceId
// Correlate with runtime: node processes reading package.json or spawning children indicative of escape
| join kind=leftouter (
    DeviceProcessEvents
    | where FileName in~ ("node.exe", "node")
    | where ProcessCommandLine has "vm2" or ProcessCommandLine has_any ("TypedArray", "ArrayBuffer", "__proto__", "constructor.prototype")
    | project DeviceId, InitiatingProcessCommandLine, ProcessCommandLine, Timestamp
) on DeviceId
| project DeviceName, SoftwareVersion, ProcessCommandLine, InitiatingProcessCommandLine, Timestamp

Identifies endpoints with vulnerable vm2 (3.11.0–3.11.7) in software inventory and correlates with Node.js runtime activity referencing vm2 or intrinsic mutation primitives.

critical severity medium confidence

Data Sources

Microsoft Defender for Endpoint - Software Inventory Microsoft Defender for Endpoint - Process Events

Required Tables

DeviceTvmSoftwareInventory DeviceProcessEvents

False Positives

  • Legitimate developer workstations running vm2 in test harnesses that reference TypedArray/ArrayBuffer in benign code.
  • Security scanning or SCA tooling that enumerates vm2 and prototype keywords for inventory purposes.
  • CI/CD build agents transiently installing vm2 during dependency resolution before upgrading.

Sigma rule & cross-platform mapping

The detection logic for vm2 TypedArray/ArrayBuffer Intrinsic Mutation Sandbox Escape (CVE-2026-92953) (CVE-2026-92953) above is provided in a vendor-neutral form so you can deploy it on any SIEM. The same logic is shipped here as native KQL (Microsoft Sentinel / Defender), SPL (Splunk), Elastic (Elastic Security (EQL)), QRadar (IBM QRadar (AQL)), Sumo (Sumo Logic CSE), YARA-L (Google Chronicle / SecOps), LogScale (CrowdStrike LogScale (CQL)) queries. In Sigma terms, this detection targets the following logsource:

logsource:
  category: process_creation
  product: windows

Browse the community-maintained Sigma rules for this technique:


Testing Methodology

Validate this detection against 3 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.

  1. Test 1Install vulnerable vm2 version

    Expected signal: npm install process events and a package.json/package-lock.json referencing [email protected]; SCA inventory records vm2 3.11.7.

  2. Test 2Node process evaluating TypedArray intrinsic access

    Expected signal: Node.js process launch with command line referencing TypedArray/__proto__ intrinsic access.

  3. Test 3Simulated sandbox escape child-process spawn

    Expected signal: Node.js parent process spawning a shell/id child process and writing /tmp/vm2-escape-proof.


Response Playbook

Triage

  1. Confirm the affected host runs vm2 at a version in the range 3.11.0–3.11.7 by inspecting package.json/package-lock.json or `npm ls vm2` output; versions >= 3.11.8 are not affected.
  2. Determine whether the vm2 instance is exposed to attacker-controlled or untrusted script input (e.g., user-submitted code, plugins, template evaluation). Internal-only, trusted-input usage lowers immediate risk but still requires patching.
  3. Review recent Node.js process telemetry for the host for command-line or child-process activity referencing TypedArray/ArrayBuffer manipulation, unexpected shell spawns from the Node process, or outbound connections initiated post-evaluation.
  4. Correlate the detection timeframe with any sandbox evaluation endpoints or job queues that accept external code to scope potential exploitation.

Containment

  1. Upgrade vm2 to 3.11.8 or later across all affected hosts; if immediate upgrade is not possible, disable or gate the feature that evaluates untrusted code through vm2.
  2. Isolate hosts showing evidence of sandbox escape (unexpected child processes spawned by Node, new persistence, or outbound C2) from the network pending investigation.
  3. Rotate any secrets, tokens, or credentials accessible to the Node.js process if host compromise is suspected.

Evidence Collection

  1. Capture the exact vm2 version and dependency tree (`npm ls vm2`, package-lock.json) and the application code path that invokes the VM.
  2. Preserve Node.js process logs, stdout/stderr, and any EDR process-tree and network telemetry around the detection window.
  3. Collect submitted/evaluated script payloads from application logs or job queues for malware/exploit analysis.

Escalation Criteria

  • ! Escalate to incident response if Node.js processes embedding vm2 spawned unexpected shells, wrote new files outside the sandbox, or made unexpected outbound connections.
  • ! Escalate if the vulnerable vm2 instance is confirmed to evaluate externally controlled code reachable from the internet, given the CVSS 10.0 host-takeover impact.

Investigation Guide

Forensic Artifacts

  • > package.json / package-lock.json / yarn.lock entries pinning vm2 to a vulnerable 3.11.x version
  • > Node.js process command lines, process-tree children, and crash/error logs referencing TypedArray, ArrayBuffer, or prototype access
  • > Application job-queue or request logs containing the submitted script payloads evaluated by vm2

Tuning Guidance

Baseline the Node.js applications in your environment that legitimately use TypedArray/ArrayBuffer to reduce command-line keyword noise, and prioritize alerts from the SCA/inventory queries which deterministically identify vulnerable versions. Suppress runtime keyword matches on known developer or build hosts, and treat unexpected child-process spawns from Node as high-fidelity escape indicators regardless of keyword matches.


Hunting Queries

Hunts for unexpected child processes spawned by Node.js, a strong indicator of a successful vm2 sandbox escape.

Hunting — KQL
kql
DeviceProcessEvents | where InitiatingProcessFileName in~ ("node.exe","node") | where ProcessCommandLine !has "node" | project Timestamp, DeviceName, InitiatingProcessCommandLine, FileName, ProcessCommandLine | order by Timestamp desc
Hunting — SPL
spl
index=endpoint sourcetype=*process* parent_process="*node*" NOT process="*node*" | stats count by host, parent_process, process, process_command_line

Atomic Red Team Tests

Test 1 Install vulnerable vm2 version
linux

Installs a vm2 version within the affected range to validate SCA/inventory-based detection.

Command

bash
mkdir -p /tmp/vm2-test && cd /tmp/vm2-test && npm init -y >/dev/null 2>&1 && npm install [email protected] >/dev/null 2>&1 && npm ls vm2

Cleanup

bash
rm -rf /tmp/vm2-test

Expected Telemetry

npm install process events and a package.json/package-lock.json referencing [email protected]; SCA inventory records vm2 3.11.7.

Expected Detection

spl and sumo_logic inventory queries flag vm2 3.11.7 as vulnerable.

Test 2 Node process evaluating TypedArray intrinsic access
linux

Runs a Node.js script that references TypedArray/ArrayBuffer prototype access to validate runtime keyword detection.

Command

bash
node -e "const vm2=require('/tmp/vm2-test/node_modules/vm2'); const {VM}=vm2; try{new VM().run('Object.getPrototypeOf(Int8Array.prototype.__proto__)')}catch(e){console.log('ran')}"

Cleanup

bash
echo 'no cleanup required'

Expected Telemetry

Node.js process launch with command line referencing TypedArray/__proto__ intrinsic access.

Expected Detection

kql, elastic_eql, chronicle_yaral, and crowdstrike_cql runtime queries match the node command line.

Test 3 Simulated sandbox escape child-process spawn
linux

Simulates the post-exploitation signal of a vm2 escape by having Node spawn an unexpected child process.

Command

bash
node -e "require('child_process').execSync('id > /tmp/vm2-escape-proof')"

Cleanup

bash
rm -f /tmp/vm2-escape-proof

Expected Telemetry

Node.js parent process spawning a shell/id child process and writing /tmp/vm2-escape-proof.

Expected Detection

Hunting queries for unexpected Node child processes fire on the spawned process.

Related Detections