Skip to content

Back to the catalog

How JavaScript Sandboxes Work | Blog | Endor Labs
endorlabs.comarticle

How JavaScript Sandboxes Work | Blog | Endor Labs

Endor Labs explains why vm2-style JavaScript sandboxes (shared heap, shared built-ins, shared Function constructor) suffered 20+ documented escapes via prototype pollution and Function constructor abuse, and how V8 Isolates (used by isolated-vm) fix this by giving guest and host separate heaps and built-ins. It also discloses GHSA-864f-rcv7-6rh4, a critical isolated-vm vulnerability in the ExternalCopy/Reference C++ binding layer that let guest code corrupt host memory across the isolate boundary, patched in isolated-vm 7.0.1/6.2.0.

TL;DR Deep dive on why vm2 sandboxes were escapable and how V8 Isolates (isolated-vm) fix it, plus disclosure of GHSA-864f-rcv7-6rh4, a critical isolated-vm sandbox escape in the native copy/reference binding code.
Document

What it is

An Endor Labs explainer on JavaScript sandbox architecture, anchored to GHSA-864f-rcv7-6rh4 — a critical vulnerability in isolated-vm that Endor Labs disclosed in August 2026 and the maintainer patched in 7.0.1 and 6.2.0. The value the summary misses is the downstream blast radius and the threat-model conclusion, not the vuln itself.

How it works

The escape did not defeat V8's Isolate boundary (separate heaps, separate built-ins). It exploited the glue: isolated-vm moves values across the boundary with ExternalCopy (serialize/rebuild) and Reference (a handle the host deliberately exposes), and that copying runs in C++ code holding raw pointers into both heaps at once. Guest code could make the host's C++ follow a guest-controlled value, escalating from a controlled crash to redirecting host execution. Per the page: a single Reference was enough to reach the vuln.

Preconditions / Affected

Any Node.js service embedding a vulnerable isolated-vm (before 7.0.1 / 6.2.0) that runs untrusted or model-generated code and exposes at least one capability across the boundary. The page names specific consumers to check your dependency chain against:

  • Rocket.Chat — sandboxes integration scripts
  • Directus, Budibase — run user-authored automation scripts
  • Mastra — model-generated tool orchestration
  • n8n — recommends it for isolating Code-node scripts

isolated-vm reportedly sees over a million downloads a week, so transitive exposure is likely.

What to do

  • Upgrade isolated-vm to 7.0.1 (or 6.2.0 on the 6.x line).
  • Audit for the listed products and any other embedder in your tree; a vulnerable copy can arrive transitively.
  • Treat the audit as capability-scoped, not just isolate-scoped: the boundary is the Isolate plus every capability you hand across it. Inventory each Reference and ExternalCopy surface you expose to guest code — each one is attack surface, and one is enough.

Caveats

The page states plainly that V8's memory isolation was never defeated — only the C++ binding layer around it — so the Isolate model itself is not called into question. The article gives no exploit code, no CVSS figure, and no detection signatures beyond the fixed version numbers. Its Chrome-comparison for Isolates is described by the author as "directionally right rather than exact" (Chrome relies mainly on OS process isolation).

Organisations named here

  • GHSA-864f-rcv7-6rh4

Technologies named here

  • isolated-vm
  • vm2
  • V8
  • Node.js

Techniques named here

  • Prototype pollution / redefining built-in prototypes
  • Function constructor abuse
  • Object graph traversal via shared heap
  • Type confusion via stateful getter