CVE-2026-92940 Splunk · SPL

Detect vm2 HTTPS Credential Exposure via globalAgent (CVE-2026-92940) in Splunk

Detects presence and exploitation indicators of CVE-2026-92940, a CWE-668 (Exposure of Resource to Wrong Sphere) flaw in the npm package vm2 versions >= 3.11.3 through <= 3.11.6. In affected versions, sandboxed code running inside vm2 can reach the host's https.globalAgent, exposing host HTTPS client credentials (TLS client certificates, private keys, and in-flight TLS session material) to untrusted sandboxed scripts. The CVE carries a CVSS of 10.0 with a public proof-of-concept. This detection surfaces vulnerable vm2 installs via package manifests/lockfiles, Node.js processes loading the vulnerable module, and runtime behaviors consistent with sandbox-driven access to globalAgent and outbound TLS connections. Remediation is upgrade to vm2 >= 3.11.7.

MITRE ATT&CK

Tactic
Defense Evasion Credential Access Collection

SPL Detection Query

Splunk (SPL)
spl 
(index=osquery OR index=edr sourcetype="package:inventory" OR sourcetype="osquery:results") (name="vm2" OR path="*node_modules*vm2*")
| rex field=version "^(?<maj>\d+)\.(?<min>\d+)\.(?<pat>\d+)"
| eval vuln=if((maj==3 AND min==11 AND pat>=3 AND pat<=6),"vulnerable","not_vulnerable")
| where vuln="vulnerable"
| stats values(version) as versions values(path) as paths min(_time) as firstSeen by host name
| convert ctime(firstSeen)
critical severity medium confidence

Finds hosts with an installed vm2 version in the vulnerable range 3.11.3-3.11.6 using package/software inventory telemetry.

Data Sources

Software inventory / osqueryEDR package inventory

Required Sourcetypes

osquery:resultspackage:inventory

False Positives & Tuning

  • Inventory entries for vm2 that have since been upgraded but not yet rescanned
  • Non-production or cached node_modules trees reported by inventory
  • Version strings mis-parsed from unusual pre-release tags

Other platforms for CVE-2026-92940

Microsoft Sentinel (KQL) Elastic Security (Elastic) IBM QRadar (QRadar) Sumo Logic CSE (Sumo) Google Chronicle (YARA-L) CrowdStrike LogScale (LogScale) All platforms (combined) →

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: File create events for node_modules/vm2/package.json showing version 3.11.6; npm/node process execution.

  2. Test 2Run vm2 sandbox referencing globalAgent

    Expected signal: Node.js process event with command line referencing vm2 and globalAgent.

  3. Test 3Lockfile pins vulnerable vm2 range

    Expected signal: File events for package-lock.json and node_modules\vm2\package.json with version 3.11.5.

Last updated: 2026-10-02 Research depth: standard
References (6)

Response Playbook

Triage

  1. Confirm the installed vm2 version on the host (npm ls vm2 / inspect node_modules/vm2/package.json) and verify it falls within >= 3.11.3 and <= 3.11.6.
  2. Determine whether the vm2 instance executes untrusted or user-supplied code — if the sandbox only runs trusted first-party scripts, exposure risk is materially lower.
  3. Identify what HTTPS client credentials the host process holds (TLS client certs, private keys, mutual-TLS configs) that https.globalAgent could expose to sandboxed code.
  4. Review outbound TLS connections initiated by the Node process around the time vm2 executed untrusted code for anomalous destinations.

Containment

  1. Upgrade vm2 to >= 3.11.7 across all affected services and redeploy; where upgrade is blocked, isolate or disable the sandbox endpoint accepting untrusted code.
  2. Rotate any HTTPS client certificates, private keys, and credentials that were reachable via the host's https.globalAgent while the vulnerable vm2 was running.

Evidence Collection

  1. Capture node_modules/vm2/package.json, lockfiles, and the application code paths that instantiate the vm2 sandbox.
  2. Collect Node.js process telemetry, network connection logs, and any available sandbox audit logs showing scripts executed through vm2.

Escalation Criteria

  • !Escalate to IR if the vulnerable vm2 instance executes untrusted/user-submitted code AND the host holds HTTPS client credentials.
  • !Escalate if outbound TLS connections to unexpected destinations coincide with sandbox execution, indicating possible credential or traffic exfiltration.

Investigation Guide

Related Techniques

[object Object][object Object]

Forensic Artifacts

  • >node_modules/vm2/package.json version string
  • >Application source instantiating new VM/NodeVM from vm2
  • >Node.js process network connection logs showing TLS egress
  • >Lockfiles (package-lock.json/yarn.lock) pinning vulnerable vm2 range

Tuning Guidance

Suppress hosts confirmed on vm2 >= 3.11.7 by joining against patch/inventory data. Scope file-path matches to production node_modules trees and exclude CI/build and developer test directories. Prioritize alerts where the vm2 sandbox executes untrusted code and the host holds HTTPS client credentials; downgrade matches that are inventory-only with no runtime execution.

Hunting Queries

Enumerate hosts carrying vm2 package artifacts in the vulnerable 3.11.3-3.11.6 range.

Hunting — KQL
kql 
DeviceFileEvents | where FolderPath has_cs "node_modules" and FolderPath has_cs "vm2" and FileName == "package.json" | project DeviceName, FolderPath, Timestamp
Hunting — SPL
spl 
index=osquery name=vm2 | rex field=version "^(?<maj>\d+)\.(?<min>\d+)\.(?<pat>\d+)" | where maj==3 AND min==11 AND pat>=3 AND pat<=6 | table host version path

Atomic Red Team Tests

Test 1 Install vulnerable vm2 version
linux

Install vm2 3.11.6 into a lab project to generate detectable package artifacts.

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 node_modules/vm2/package.json showing version 3.11.6; npm/node process execution.

Expected Detection

KQL/EQL file-path rules match vm2 under node_modules; SPL/osquery inventory flags version 3.11.6 as vulnerable.

Test 2 Run vm2 sandbox referencing globalAgent
linux

Execute a Node script that loads vm2 and references https.globalAgent to simulate credential-sphere access.

Command

bash 
cd /tmp/vm2lab && node -e "const {VM}=require('vm2'); const v=new VM(); console.log(v.run('typeof process'));" ; node -e "const https=require('https'); console.log(!!https.globalAgent)"

Cleanup

bash 
rm -rf /tmp/vm2lab

Expected Telemetry

Node.js process event with command line referencing vm2 and globalAgent.

Expected Detection

Process-based KQL/CQL/YARA-L rules match node command line containing vm2 or globalAgent.

Test 3 Lockfile pins vulnerable vm2 range
windows

Create a lockfile pinning vm2 in the vulnerable range to trigger manifest-based detection.

Command

powershell 
cmd /c "mkdir C:\vm2lab && cd C:\vm2lab && npm init -y && npm install [email protected]"

Cleanup

powershell 
cmd /c "rmdir /s /q C:\vm2lab"

Expected Telemetry

File events for package-lock.json and node_modules\vm2\package.json with version 3.11.5.

Expected Detection

Inventory and file-path detections flag the 3.11.5 install as within the vulnerable 3.11.3-3.11.6 range.

Related Detections

Tactic Hubs

TA0005Defense EvasionTA0006Credential AccessTA0009Collection

Related Techniques

T1212Exploitation for Credential AccessT1552.004Private Keys

Same Tactic: Defense Evasion

Popular Detections