Critical Isolated-vm Vulnerability Leads to RCE on Host

1. Executive summary

A critical type confusion vulnerability in the isolated-vm Node.js library (GHSA-864f-rcv7-6rh4) enables sandboxed JavaScript to escape the V8 Isolate and achieve remote code execution on the host process. The flaw resides in the native C++ binding within the ExternalCopy function, which serializes data across Isolate boundaries; a time-of-check/time-of-use (TOCTOU) weakness allows an attacker-controlled getter to substitute values between validation passes, yielding an attacker-controlled pointer dereference. The vulnerability impacts all versions through 7.0.0 and is patched in versions 6.2.0 and 7.0.1. EMEA financial services that use isolated-vm to execute customer-supplied or third-party untrusted JavaScript — for example in server-side calculation engines, plugin sandboxes, or code-evaluation features — are exposed to full host compromise from within a sandbox designed to prevent exactly that.

2. Regulatory framing

No specific DORA/NIS2 article is directly engaged by this item. While the vulnerability could theoretically cause an ICT-related incident, the trigger is not distinctive to this item beyond the generic fact that a patchable vulnerability exists.

3. Technical analysis & attack chain

Affected component: isolated-vm — an open-source Node.js library (2,900+ GitHub stars, 190+ forks) providing access to the V8 JavaScript engine's Isolate interface for executing untrusted JavaScript in a sandboxed environment. No CVE identifier has been assigned at time of writing. Tracked as GHSA-864f-rcv7-6rh4.

Affected versions: All versions ≤ 7.0.0. Fixed versions: 6.2.0 and 7.0.1.

Vulnerability mechanism

The flaw is a type confusion in the native C++ glue code that serializes values across the V8 Isolate boundary via the ExternalCopy function. ExternalCopy copies data between Isolates by serializing in the source and reconstructing in the destination. For performance, it supports a transferList mechanism: large ArrayBuffer objects are listed, and the underlying memory is transferred by detaching the buffer from the source and handing it to the destination.

The reconstructor iterates over the byte array list (transfer_list) twice. The second pass trusts the values obtained in the first pass. However, because iterating the transfer_list JavaScript array can invoke a getter defined on an element, the getter can return a different value on the second iteration than on the first. This creates a time-of-check/time-of-use (TOCTOU) gap: the first pass validates a value, the getter substitutes it, and the second pass uses the attacker-controlled value — resulting in an unchecked cast on a re-read value and an attacker-controlled pointer dereference.

Attack chain

1. The host application creates a V8 Isolate via isolated-vm and executes untrusted (guest) JavaScript inside it.
2. The host exposes at least one ivm.Reference object into the sandbox — the mechanism through which the host exposes anything to the guest.
3. The guest JavaScript constructs a malicious transferList containing an element defined as a getter that returns a benign value on the first iteration and a crafted value on the second.
4. The guest triggers an ExternalCopy operation (or the host passes a caller-influenced array as transferList), causing the native C++ binding to iterate the transferList twice.
5. On the second pass, the getter returns the attacker-controlled value, which is cast without validation, producing a controlled pointer dereference.
6. This results in either a crash (denial-of-service) or control-flow hijack of the host process, enabling RCE on the host.

Key exposure conditions (per the isolated-vm advisory)

• Any embedder that runs untrusted code in an Isolate and shares even one Reference into it is affected.
• Host code that passes a caller-influenced array as transferList is affected directly, without any guest code involvement.

Root cause context: The vulnerability lived in the native glue code — the C++ binding that serializes values across the Isolate boundary. This layer is written in a memory-unsafe language, manipulates raw V8 handles and backing-store pointers, and re-reads attacker-controlled JavaScript objects during a security-sensitive operation. The fix in 6.2.0 and 7.0.1 prevents user JavaScript from running during the copy.

Confidence note: Technical detail is corroborated across SecurityWeek and The Hacker News, both citing EndorLabs as the original researcher. The BSI advisory (corpus-2) references vm2, a different Node.js sandbox library — this appears to be a related but distinct advisory and should not be conflated with the isolated-vm vulnerability. The GitHub advisory (corpus-3) concerns VMware Avi Load Balancer and is unrelated.

4. Mitigation & containment

P1 — Within 24 hours

1. Identify all uses of isolated-vm across the estate. Search package.json, node_modules, and lockfiles for isolated-vm with version ≤ 7.0.0: npm ls isolated-vm grep -r "isolated-vm" package-lock.json yarn.lock pnpm-lock.yaml
2. Assess exposure: Determine whether any deployment meets either exposure condition: - Untrusted JavaScript is executed inside an Isolate AND at least one ivm.Reference is shared into it. - Host code passes a caller-influenced (user-controlled) array as transferList to ExternalCopy.
3. If exposed and processing untrusted input: Treat as critical. Prioritise immediate upgrade. As an interim containment measure, restrict or disable the feature that accepts and executes untrusted JavaScript until the patch is applied. If the service cannot be disabled, ensure the host process runs with minimal privileges and in an isolated container to limit blast radius of a sandbox escape.

P2 — Within 72 hours

4. Upgrade isolated-vm to a fixed version: - If on the 6.x branch: upgrade to 6.2.0. - If on the 7.x branch: upgrade to 7.0.1. npm install isolated-vm@7.0.1 # or npm install isolated-vm@6.2.0 Rebuild native bindings after upgrade (the fix is in C++ code, not pure JavaScript).
5. Audit transferList usage: Review all host-side code that calls ExternalCopy with a transferList parameter. Ensure no caller-influenced data reaches transferList without sanitisation. Even after patching, treat transferList inputs as security-sensitive.
6. Review ivm.Reference exposure: Enumerate all Reference objects shared into sandboxes. Minimise the attack surface by removing any Reference that is not strictly required.

P3 — Within 7 days

7. Implement defence-in-depth: Ensure host processes running isolated-vm operate under least-privilege (non-root, restricted filesystem, seccomp profile, network egress controls) so that a sandbox escape cannot pivot to broader system compromise.
8. Add dependency scanning: Ensure SCA tooling flags isolated-vm < 7.0.1 (or < 6.2.0) as a blocking finding in CI/CD pipelines.

5. Indicators of compromise

No indicators of compromise available in the source material. This is a vulnerability disclosure; no specific exploitation IOCs, malware payloads, or attacker infrastructure have been reported.

Behavioural indicators

6. Detection

Insufficient indicators to author detection rules. The source material describes a vulnerability mechanism but provides no malicious file artefacts, command-line strings, registry keys, mutex names, or network signatures that would constitute threat artefacts for YARA or Sigma rules.

Defenders should focus on behavioural detection: monitor Node.js host processes running isolated-vm for unexpected child process creation, anomalous outbound network connections, or crash patterns (SIGSEGV) following JavaScript execution workloads.

7. Sources

• SecurityWeek — "Critical Isolated-vm Vulnerability Leads to RCE on Host" — https://www.securityweek.com/critical-isolated-vm-vulnerability-leads-to-rce-on-host/ — 2026-08-21
• The Hacker News — "Isolated-vm Flaw Lets Sandboxed JavaScript Escape to Host for Potential RCE" — https://thehackernews.com/2026/08/isolated-vm-flaw-lets-sandboxed.html — 2026-08-21
• GitHub Security Advisory GHSA-864f-rcv7-6rh4 (referenced via The Hacker News; advisory text quoted in SecurityWeek)

8. Adverse Trace position

This is a critical-severity sandbox escape in a widely adopted Node.js isolation library. The vulnerability is architecturally significant: it defeats the core security promise of isolated-vm — safe execution of untrusted JavaScript — through a TOCTOU flaw in memory-unsafe C++ glue code. No CISA-KEV entry or confirmed in-the-wild exploitation has been reported as of publication, and no CVE has been assigned; attribution to any threat actor is not applicable. EMEA financial services running server-side JavaScript sandboxes for customer-facing calculation engines, plugin systems, or code evaluation features should treat this as a P1 remediation: upgrade to 6.2.0 or 7.0.1 immediately and audit all transferList and ivm.Reference usage. We will monitor for CVE assignment, KEV listing, and any evidence of active exploitation. Technical detail is corroborated across two independent publications citing EndorLubs as the originating researcher.

Read the original source →

Published via PulseTrace — Adverse Trace threat intelligence.