
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.
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-vmto 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
ReferenceandExternalCopysurface 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
Related in AppSec
Flowise MCP Security Bypass Enables RCE
Inside an Oracle Database SQL Injection Attack | Huntress
OASIS
