If your organization runs untrusted JavaScript inside Node.js — plugin systems, user-supplied scripts, workflow engines, multi-tenant SaaS automation, CI snippet runners — this advisory is aimed squarely at you. Researchers have disclosed a critical sandbox escape in isolated-vm, a widely used open-source library that wraps V8 isolates to execute JavaScript in a constrained environment. The flaw, tracked as GHSA-864f-rcv7-6rh4 (no CVE assigned as of this writing), affects all versions up to and including 7.0.0 and allows code running inside the sandbox to break out and execute on the host process.
Let that sink in: the entire purpose of isolated-vm is to be the security boundary between hostile JavaScript and your Node.js runtime. When the boundary fails, the attacker inherits everything the Node.js process can reach — environment variables, credentials, file system, internal network. With more than 2,900 GitHub stars and widespread use in serverless platforms, low-code tools, and developer infrastructure, the blast radius here is significant. Treat this as a priority-one review of anywhere you run tenant or user-controlled code.
Technical Analysis
Affected Component and Scope
- Package:
isolated-vm(npm), the popular Node.js binding around V8 isolates - Affected versions: All releases ≤ 7.0.0
- Advisory: GitHub Security Advisory GHSA-864f-rcv7-6rh4; no CVE identifier has been assigned yet
- Platforms: Any OS running Node.js with the vulnerable package installed — Linux, Windows, and macOS servers are all in scope
Why isolated-vm Is a High-Value Target
isolated-vm exists to solve one problem: safely executing JavaScript you don't trust. It is used to build V8 isolates with memory limits, CPU timeouts, and a restricted context, and it's commonly deployed in:
- Multi-tenant SaaS platforms running customer-defined scripts or webhooks
- Low-code / no-code workflow engines
- Serverless function runtimes and edge compute platforms
- Internal tooling that evaluates user-submitted expressions or transforms
In every one of these deployments, the threat model assumes sandboxed code is hostile. A sandbox escape collapses that assumption. Because isolated-vm code executes within the host Node.js process, a successful escape means arbitrary code execution with the privileges of the Node.js service account — often a service identity with access to databases, message queues, secrets stores, and internal APIs.
Attack Chain (Defender's Perspective)
- The attacker submits malicious JavaScript through whatever legitimate interface the platform exposes — a plugin editor, workflow step, function endpoint, or script field.
- The application executes the payload inside an isolated-vm context, assuming containment.
- The payload triggers the flaw to escape the isolate boundary and gain native access to the host process context.
- Post-escape, expect classic Node.js post-exploitation:
require('child_process')to spawn shells, readingprocess.envfor cloud credentials (AWS/GCP/Azure environment variables), writing to the filesystem for persistence, or making outbound network calls for C2 and exfiltration.
The most reliable observable signature of a successful escape is the Node.js process doing things Node.js shouldn't do: spawning shells, reading sensitive files, or opening unexpected outbound connections.
Exploitation Status
At the time of this writing, the advisory has been publicly disclosed and no CVE has been assigned. Public reporting does not yet confirm in-the-wild exploitation, and the flaw has not been added to CISA's Known Exploited Vulnerabilities catalog. However, sandbox escapes in widely deployed libraries have a short shelf life between disclosure and weaponization — once technical details circulate, exploit development against multi-tenant platforms typically follows within days. Assume motivated attackers are already working on it and act accordingly.
Detection & Response
Because exploitation requires malicious JavaScript to be fed into the sandbox, the highest-fidelity detections focus on post-escape behavior: the Node.js process performing host-level actions it has no legitimate reason to perform.
Sigma Rules
The following rules target the most reliable observables: Node.js spawning shell processes, and Node.js-initiated connections to unusual destinations. Tune the account/process allowlists to your environment before deploying.
---
title: Node.js Process Spawning Shell or Script Interpreter
id: 8c2f4a17-3b6e-4d91-a5c2-7e1f9b3d4a56
status: experimental
description: Detects a Node.js process spawning a shell or script interpreter, consistent with post-exploitation activity following an isolated-vm sandbox escape (GHSA-864f-rcv7-6rh4). Legitimate Node.js services rarely spawn child shells in production.
references:
- https://thehackernews.com/2026/08/isolated-vm-flaw-lets-sandboxed.html
- https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/08/12
tags:
- attack.execution
- attack.t1059
logsource:
category: process_creation
product: linux
detection:
selection_parent:
ParentImage|endswith:
- '/node'
- '/nodejs'
selection_child:
Image|endswith:
- '/sh'
- '/bash'
- '/dash'
- '/zsh'
- '/python'
- '/python3'
- '/perl'
- '/curl'
- '/wget'
- '/nc'
- '/ncat'
condition: selection_parent and selection_child
falsepositives:
- Build tooling and CI pipelines that legitimately invoke child processes from Node.js scripts
- Node-based monitoring agents
level: high
---
title: Node.js Process Spawning Shell or Script Interpreter (Windows)
id: 3d7a9c42-5f18-4b63-9e2a-1c4d8f6b2a97
status: experimental
description: Detects node.exe spawning cmd.exe, PowerShell, or other LOLBins, consistent with post-exploitation after an isolated-vm sandbox escape (GHSA-864f-rcv7-6rh4) on Windows hosts.
references:
- https://thehackernews.com/2026/08/isolated-vm-flaw-lets-sandboxed.html
- https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/08/12
tags:
- attack.execution
- attack.t1059.001
logsource:
category: process_creation
product: windows
detection:
selection_parent:
ParentImage|endswith: '\node.exe'
selection_child:
Image|endswith:
- '\cmd.exe'
- '\powershell.exe'
- '\pwsh.exe'
- '\wscript.exe'
- '\cscript.exe'
- '\rundll32.exe'
- '\certutil.exe'
- '\bitsadmin.exe'
condition: selection_parent and selection_child
falsepositives:
- Development workstations running build scripts (npm postinstall, node-gyp)
- Electron-based applications with embedded shells
level: high
---
title: Node.js Outbound Connection to Rare External Destination
id: 6b1e8d35-9a47-4c52-b8f3-2d5e7a9c1b48
status: experimental
description: Detects Node.js processes establishing outbound connections on uncommon ports, which may indicate C2 or exfiltration following an isolated-vm sandbox escape (GHSA-864f-rcv7-6rh4). Baseline known destinations for your Node.js services before enabling.
references:
- https://thehackernews.com/2026/08/isolated-vm-flaw-lets-sandboxed.html
- https://attack.mitre.org/techniques/T1071/
author: Security Arsenal
date: 2026/08/12
tags:
- attack.command_and_control
- attack.t1071
- attack.exfiltration
logsource:
category: network_connection
product: linux
detection:
selection:
Image|endswith:
- '/node'
- '/nodejs'
DestinationPort:
- 4444
- 5555
- 6666
- 7777
- 8888
- 1337
- 31337
filter_local:
DestinationIp|startswith:
- '10.'
- '192.168.'
- '172.16.'
condition: selection and not filter_local
falsepositives:
- Development and staging environments using non-standard service ports
level: medium
KQL (Microsoft Sentinel / Defender)
This query hunts for Node.js processes spawning shells or downloading content — the canonical post-escape behavior — across both Windows (DeviceProcessEvents) and Linux Syslog telemetry. Run it as a 7-day lookback and convert to an analytics rule with the noisy parent processes filtered out.
let ShellImages = dynamic(["cmd.exe","powershell.exe","pwsh.exe","wscript.exe","cscript.exe","rundll32.exe","certutil.exe","sh","bash","dash","zsh","python","python3","perl","curl","wget","nc","ncat"]);
union isfuzzy=true
(DeviceProcessEvents
| where TimeGenerated > ago(7d)
| where InitiatingProcessFileName =~ "node.exe"
| where FileName in~ (ShellImages)
| project TimeGenerated, DeviceName, AccountName, InitiatingProcessCommandLine, FileName, ProcessCommandLine, InitiatingProcessId, ProcessId),
(Syslog
| where TimeGenerated > ago(7d)
| where Facility == "user" or Facility == "audit"
| where SyslogMessage has_any ("node", "nodejs")
| where SyslogMessage has_any ("/bin/sh", "/bin/bash", "curl", "wget", "nc ", "python")
| project TimeGenerated, HostName, ProcessName, SyslogMessage)
| order by TimeGenerated desc
Velociraptor VQL
Use this artifact to sweep endpoints for Node.js processes with suspicious child processes or loaded from non-standard paths — useful when triaging whether a server running isolated-vm workloads shows signs of post-escape activity.
-- Hunt for Node.js processes spawning shells or running from unusual paths
SELECT Pid, Ppid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE Name =~ '(?i)node'
AND (
CommandLine =~ '(?i)(child_process|/bin/sh|/bin/bash|cmd\.exe|powershell|-e |eval)'
OR Exe =~ '(?i)(/tmp/|/dev/shm/|/var/tmp/|appdata\\local\\temp)'
)
Remediation Script
The following Bash script inventories your Node.js deployments for the vulnerable isolated-vm package and reports the installed version so you can prioritize patching. Run it against application servers, containers, and CI runners.
#!/bin/bash
# isolated-vm GHSA-864f-rcv7-6rh4 exposure audit
# Scans for vulnerable isolated-vm installations across common Node.js deployment paths
SEARCH_PATHS="/opt /srv /home /var/www /usr/local /app"
if [ -f ./package.json ]; then
SEARCH_PATHS=". $SEARCH_PATHS"
fi
echo "[+] Scanning for isolated-vm installations..."
find $SEARCH_PATHS -type d -name "isolated-vm" -path "*/node_modules/*" 2>/dev/null | while read -r dir; do
pkg="$dir/package.json"
if [ -f "$pkg" ]; then
version=$(grep -o '"version"[^,]*' "$pkg" | head -1 | grep -o '[0-9][0-9.]*')
echo "[!] FOUND isolated-vm v$version at: $dir"
major=$(echo "$version" | cut -d. -f1)
if [ "$major" -le 7 ]; then
echo " -> VULNERABLE: version <= 7.0.0 affected by GHSA-864f-rcv7-6rh4"
else
echo " -> Version above affected range; verify against the GitHub advisory for the fixed release"
fi
fi
done
echo ""
echo "[+] Checking for lockfile references (transitive dependencies)..."
find $SEARCH_PATHS -maxdepth 6 \( -name "package-lock.json" -o -name "yarn.lock" -o -name "pnpm-lock.yaml" \) 2>/dev/null | while read -r lock; do
if grep -q "isolated-vm" "$lock"; then
echo "[!] isolated-vm referenced in lockfile: $lock"
grep -A1 '"isolated-vm"' "$lock" | grep -o '"version"[^,]*' | head -3
fi
done
echo ""
echo "[+] Container images: run 'npm ls isolated-vm' inside each image or scan with trivy/grype"
echo "[+] Remediation: update isolated-vm to the patched release per https://github.com/laverdet/isolated-vm/security/advisories"
Remediation
- Upgrade isolated-vm immediately. All versions ≤ 7.0.0 are affected. Pin to the patched release published alongside the advisory and rebuild all affected services. Monitor the GitHub advisory (GHSA-864f-rcv7-6rh4) for the official fixed version and any subsequent CVE assignment.
- Inventory everywhere the package lives — including transitively. isolated-vm is frequently pulled in as a dependency of workflow engines and plugin frameworks, so
npm ls isolated-vmand lockfile analysis are mandatory. Don't forget container images and serverless build artifacts; scan with Trivy, Grype, or your existing SCA tooling. - Add defense in depth around untrusted code execution. Even after patching, never rely on a single sandbox layer. Run Node.js services that execute tenant code under a dedicated low-privilege service account, inside containers or separate VMs with seccomp/AppArmor profiles, with egress filtering and no cloud instance metadata credentials (use IMDSv2 restrictions or workload identity).
- Scrub the Node.js environment of secrets. Anything readable via
process.env— database passwords, API keys, cloud tokens — is the first thing a post-escape attacker harvests. Move secrets into a vault with short-lived, scoped credentials. - Restrict network egress. A successful escape is far less damaging if the Node.js process can only reach explicitly allowlisted destinations. Enforce egress policies at the security group / firewall / service mesh layer.
- Hunt before you patch. If any exposed service has been running isolated-vm with user-supplied code, assume attempted exploitation is possible and review process execution and network telemetry from those hosts for the indicators above — Node spawning shells, unexpected outbound connections, or credential-file access.
- Review logging coverage. Ensure process creation auditing (auditd on Linux, Sysmon on Windows) is enabled on every host that runs untrusted JavaScript workloads so future detections have telemetry to work with.
Conclusion
Sandbox escapes in isolation libraries are among the most consequential vulnerability classes for any platform that runs multi-tenant or user-supplied code. GHSA-864f-rcv7-6rh4 removes the security boundary that isolated-vm exists to provide, and every version through 7.0.0 is affected. The fix is straightforward — upgrade and rebuild — but the real work is verifying you know everywhere this library runs, hunting for post-escape behavior on exposed systems, and layering your architecture so the next sandbox escape doesn't become a full environment compromise.
Related Resources
Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.