CVE-2026-92947

vm2 Sandbox Escape via Shared Buffer Pool Host-Memory Disclosure (CVE-2026-92947)

Defense Evasion Execution Collection Last updated:

Detects usage and exploitation of the vm2 npm package versions <= 3.11.6, which contain a critical sandbox escape (CVE-2026-92947, CVSS 10.0). Sandboxed guest code can read and write host-realm memory by abusing Node.js's shared internal Buffer allocation pool (Buffer.allocUnsafe / Buffer.poolSize), allowing cross-realm memory disclosure and tampering that defeats vm2's isolation (CWE-200, CWE-653, CWE-668). This detection surfaces vulnerable vm2 installs in running Node.js processes, package manifests, and lockfiles, and flags Node processes exhibiting buffer-pool-abuse telemetry consistent with the public PoC (GHSA-fcqc-726x-5wfc). Fixed in vm2 3.11.7.

Vulnerability Intelligence

Public PoC

What is CVE-2026-92947 vm2 Sandbox Escape via Shared Buffer Pool Host-Memory Disclosure (CVE-2026-92947)?

vm2 Sandbox Escape via Shared Buffer Pool Host-Memory Disclosure (CVE-2026-92947) (CVE-2026-92947) maps to the Defense Evasion and Execution and Collection tactics — the adversary is trying to avoid being detected in MITRE ATT&CK.

This page provides production-ready detection logic for vm2 Sandbox Escape via Shared Buffer Pool Host-Memory Disclosure (CVE-2026-92947), covering the data sources and telemetry it touches: Microsoft Defender for Endpoint, DeviceFileEvents, DeviceProcessEvents. 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
Defense Evasion Execution Collection
Microsoft Sentinel / Defender
kusto
// Detect vulnerable vm2 package files and node processes loading vm2 (CVE-2026-92947)
let vulnCutoff = "3.11.7";
union isfuzzy=true
(
    DeviceFileEvents
    | where FolderPath has "node_modules" and FolderPath has_cs "vm2"
    | where FileName in~ ("package.json", "vm.js", "index.js")
    | project Timestamp, DeviceName, FolderPath, FileName, InitiatingProcessFileName, ActionType
),
(
    DeviceProcessEvents
    | where FileName in~ ("node", "node.exe")
    | where ProcessCommandLine has_cs "vm2" or ProcessCommandLine has "allocUnsafe" or ProcessCommandLine has "poolSize"
    | project Timestamp, DeviceName, FileName, ProcessCommandLine, InitiatingProcessFileName, AccountName
)
| sort by Timestamp desc

Surfaces vm2 package artifacts under node_modules and Node.js process launches that reference vm2 or Buffer-pool primitives (allocUnsafe/poolSize) used by the exploit. Confirm the installed vm2 version against the 3.11.7 fix.

critical severity medium confidence

Data Sources

Microsoft Defender for Endpoint DeviceFileEvents DeviceProcessEvents

Required Tables

DeviceFileEvents DeviceProcessEvents

False Positives

  • Legitimate applications that embed vm2 for plugin sandboxing and are already patched to 3.11.7+
  • Security scanners or SBOM tooling reading package.json files under node_modules
  • CI/CD build agents installing or auditing dependencies containing vm2 as a transitive package

Sigma rule & cross-platform mapping

The detection logic for vm2 Sandbox Escape via Shared Buffer Pool Host-Memory Disclosure (CVE-2026-92947) (CVE-2026-92947) 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 (lab)

    Expected signal: File create events for /tmp/vm2lab/node_modules/vm2/package.json and process events for npm/node install.

  2. Test 2Run Node process referencing vm2 and Buffer pool primitives

    Expected signal: ProcessRollup/DeviceProcessEvents record a node process command line containing 'vm2', 'allocUnsafe', and 'poolSize'.

  3. Test 3Windows Node vm2 invocation (lab)

    Expected signal: DeviceProcessEvents / Windows 4688 records node.exe with a command line containing vm2 and Buffer-pool keywords.


Response Playbook

Triage

  1. Identify the host and process: determine which Node.js application loaded vm2 and capture the full process command line and working directory.
  2. Confirm the installed vm2 version by inspecting node_modules/vm2/package.json and the project's package-lock.json/yarn.lock; any version <= 3.11.6 is vulnerable.
  3. Assess exposure: determine whether the vm2 instance executes untrusted or user-supplied code (plugin engines, serverless eval, template rendering), which is the precondition for exploitation.
  4. Review recent process telemetry for Buffer.allocUnsafe / Buffer.poolSize usage or crashes/segfaults in the Node process that may indicate exploitation attempts.

Containment

  1. Upgrade vm2 to 3.11.7 or later across all affected services, or remove vm2 entirely in favor of an out-of-process/isolate-based sandbox (e.g. isolated-vm).
  2. For services that cannot be patched immediately, disable or gate the feature that evaluates untrusted code in vm2 and isolate the host at the network level.
  3. Rotate any secrets, tokens or keys that were resident in the memory of a Node.js process running vulnerable vm2 exposed to untrusted input.

Evidence Collection

  1. Preserve node_modules/vm2 contents, package-lock.json/yarn.lock, and the application source that invokes vm2 for version and usage confirmation.
  2. Capture a memory dump and process environment of the affected Node.js process if active exploitation is suspected, before remediation.
  3. Export process execution, file access and network logs for the host covering the window the vulnerable service was reachable.

Escalation Criteria

  • ! Escalate to incident response if the vulnerable vm2 instance was exposed to untrusted/user-supplied code and evidence of memory disclosure or arbitrary host code execution is present.
  • ! Escalate if secrets, credentials or customer data could have resided in the affected process memory, triggering data-breach handling.
  • ! Escalate to the application owners and change management if emergency patching to 3.11.7 requires a production deployment outside the normal window.

Investigation Guide

Forensic Artifacts

  • > node_modules/vm2/package.json and lockfile entries showing a version <= 3.11.6
  • > Node.js process memory dumps containing cross-realm Buffer references or leaked host objects
  • > Application logs showing evaluation of untrusted scripts, segfaults, or unexpected Buffer allocation errors

Tuning Guidance

Baseline which applications legitimately bundle vm2 and confirm they are on 3.11.7+. Suppress alerts for known-patched installs and for SBOM/dependency-scanning tooling that routinely reads node_modules. Prioritize alerts where the Node.js process is internet-facing or evaluates untrusted input, and treat the allocUnsafe/poolSize command-line indicators as higher-fidelity exploitation signals rather than mere presence of the package.


Hunting Queries

Enumerate hosts with vm2 package manifests to inventory potentially vulnerable installs, then verify versions against 3.11.7.

Hunting — KQL
kql
DeviceFileEvents | where FolderPath has_cs "node_modules" and FolderPath has_cs "vm2" and FileName =~ "package.json" | project Timestamp, DeviceName, FolderPath
Hunting — SPL
spl
index=* sourcetype=osquery:results path="*node_modules*vm2*package.json" | stats values(path) by host

Atomic Red Team Tests

Test 1 Install vulnerable vm2 version (lab)
linux

Installs vm2 3.11.6 to produce a vulnerable package artifact under node_modules for detection validation.

Command

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

Cleanup

bash
rm -rf /tmp/vm2lab

Expected Telemetry

File create events for /tmp/vm2lab/node_modules/vm2/package.json and process events for npm/node install.

Expected Detection

KQL/SPL file-artifact rules match the vm2 package.json path under node_modules.

Test 2 Run Node process referencing vm2 and Buffer pool primitives
linux

Executes a Node.js one-liner that references vm2 and the Buffer-pool primitives used by the PoC to generate process command-line telemetry.

Command

bash
node -e "const {VM}=require('/tmp/vm2lab/node_modules/vm2'); const b=Buffer.allocUnsafe(8); console.log('poolSize', Buffer.poolSize, b.length);"

Cleanup

bash
echo 'no artifacts to clean'

Expected Telemetry

ProcessRollup/DeviceProcessEvents record a node process command line containing 'vm2', 'allocUnsafe', and 'poolSize'.

Expected Detection

Process-based rules match on the node command line containing vm2/allocUnsafe/poolSize indicators.

Test 3 Windows Node vm2 invocation (lab)
windows

Runs a Node.js command on Windows referencing vm2 to validate Windows process telemetry coverage.

Command

powershell
node.exe -e "console.log('vm2 allocUnsafe poolSize test'); require('vm2');"

Cleanup

powershell
echo done

Expected Telemetry

DeviceProcessEvents / Windows 4688 records node.exe with a command line containing vm2 and Buffer-pool keywords.

Expected Detection

KQL DeviceProcessEvents and CrowdStrike CQL rules match the node.exe command line indicators.

Related Detections