// 1 CRITICAL · 1 ZERO-DAY · 2 CVE · 4 EXPLOIT · 1 ADVISORY NELLE ULTIME 24H
Una vulnerabilità TOCTOU nella libreria Node.js isolated-vm permette guest-to-host escape con potenziale RCE. Le patch 6.2.0 e 7.0.1 correggono il bug nel C++ glue code.

Una vulnerabilità nel componente ExternalCopy della libreria isolated-vm per Node.js consente a codice JavaScript in esecuzione in sandbox di corrompere la memoria del processo host e dirottarne il flusso di controllo. La falla, identificata come GHSA-864f-rcv7-6rh4 senza CVE ancora assegnato, è stata divulgata il 20 agosto 2026 e correggiata nelle versioni 6.2.0 e 7.0.1. Il bug mina il presupposto architetturale su cui si fondano piattaforme AI agentic e automation come n8n, Mastra e Sim.ai: che il codice generato da modelli o utenti resti confinato entro i confini del V8 Isolate.

Punti chiave
  • La vulnerabilità è una type confusion nel C++ glue code di isolated-vm, non nel meccanismo di isolamento V8 Isolate, che rimane integro.
  • Il meccanismo di attacco sfrutta una condizione time-of-check/time-of-use (TOCTOU) nel transferList: un getter stateful restituisce valori diversi tra la validazione e il trasferimento dei dati attraverso il boundary della sandbox.
  • Un singolo ivm.Reference è sufficiente per scalare da crash controllato (DoS) a control-flow hijack con potenziale RCE sul sistema host.
  • La libreria registra circa 1 milione di download settimanali su npm; progetti con decine di migliaia di stelle GitHub tra cui n8n, Mastra, Sim.ai e Activepieces ne dipendono per l'esecuzione sicura di codice non attendibile.

Il meccanismo TOCTOU nel transferList: validare due volte, fidarsi mai

Il componente ExternalCopy di isolated-vm gestisce la serializzazione dei dati attraverso il confine tra host e V8 Isolate, l'unità di isolamento che Chrome utilizza per separare i tab del browser. Quando il codice JavaScript nel guest richiede di trasferire un array di oggetti attraverso questo boundary, ExternalCopy itera due volte sul transferList: la prima per validare il contenuto, la seconda per eseguire effettivamente il trasferimento. Tra le due passate, la matrice non viene rivalidata.

Questa finestra temporale è il cuore della vulnerabilità. Un attaccante può definire un getter stateful sulla proprietà length o sugli elementi del transferList, in modo che restituisca un ArrayBuffer valido durante la prima iterazione e un oggetto completamente diverso — controllato dall'attaccante — durante la seconda. La discrepanza genera type confusion nella memoria del processo host: il codice C++ opera su strutture dati che crede di tipo noto, mentre ne ha ricevuto altre. Da qui deriva la corruzione di memoria che consente il control-flow hijack.

Dal singolo ivm.Reference al controllo del processo host

Cristian-Alexandru Staicu di Endor Labs, il ricercatore che ha scoperto e riportato la vulnerabilità, ha dimostrato che il punto di ingresso minimo per l'attacco è estremamente ridotto. Non è necessario un accesso ampio o privilegiato alla sandbox: un solo ivm.Reference, il meccanismo standard con cui l'host concede qualsiasi capacità al guest, è sufficiente a innescare la catena.

"Starting from nothing but a single ivm.Reference, the standard way hosts hand a sandbox any capability at all, we escalated the bug from a controlled-address crash all the way to hijacking the host's control flow, demonstrating a full guest-to-host sandbox escape." — Cristian-Alexandru Staicu, Endor Labs

Il maintainer del progetto, Marcel Laverdet, ha quantificato lo spettro degli impatti dimostrati: il minimo è un crash affidabile a indirizzo controllato, equivalente a un denial-of-service; il massimo è il dirottamento del flusso di controllo del processo host, ovvero potenziale remote code execution sul sistema sottostante. La distanza tra questi due estremi, nel contesto di una sandbox progettata per contenere codice non attendibile, segna il collasso del contratto di sicurezza fondamentale della libreria.

L'architettura V8 Isolate regge, il binding layer cede

Un aspetto cruciale della ricerca è la localizzazione precisa del fallimento. Il V8 Isolate, il primitive di isolamento del motore JavaScript di Google, non è compromesso. Il confine di isolamento tra processi ha retto. Ciò che è crollato è il codice di "colla" C++ che impacchetta e spacchetta i valori attraversando quel confine — il cosiddetto binding layer.

Staicu ha enfatizzato questa distinzione: "What was not broken was the isolation primitive itself... V8's Isolate boundary held. What failed was the C++ glue code that marshals values across that boundary." Il caso rientra in un pattern che la sua ricerca sta mappando sistematicamente: "That gap between 'the primitive is sound' and 'the system is safe' is where modern sandbox escapes increasingly live." La formulazione sintetizza un problema strutturale del software moderno, in cui componenti formalmente corretti sono avvolti in strati di integrazione che ne annullano le garanzie.

L'ecosistema AI agentic nel mirino: quando il codice generato è il nuovo normale

La vulnerabilità assume rilevanza strategica per via dell'adozione massiccia di isolated-vm in piattaforme dove l'esecuzione di codice generato da modelli linguistici o configurato da utenti è diventata operativa standard. Secondo DevOps.com, progetti con significativa visibilità open-source dipendono da questa libreria: n8n (oltre 200.000 stelle GitHub), Mastra (27.000 stelle), Sim.ai (29.000 stelle) e Activepieces (23.000 stelle). Altri utilizzatori includono Screeps, Fly.io, Algolia e TripAdvisor.

Queste piattaforme usano isolated-vm proprio per eseguire JavaScript non attendibile in ambienti controllati — workflow automation, agenti AI, script utente. Il paradigma agentic, in cui i modelli generano ed eseguono codice in autonomia, amplifica esponenzialmente la superficie di attacco: ogni istanza di esecuzione diventa un potenziale vettore, e la garanzia di contenimento diventa critica per la sicurezza dell'intero sistema. La scoperta di Staicu dimostra che questa garanzia, nel caso del binding layer C++, era illusoria.

Con circa 1 milione di download settimanali su npm e una comunità attiva (2.900 stelle GitHub, 190 fork), isolated-vm non è una libreria di nicchia. È infrastruttura. La sua compromissione si traduce in esposizione diffusa, spesso invisibile agli sviluppatori finali che assumono il sandboxing come dato di fatto.

Cosa fare adesso

  • Aggiornare immediatamente a isolated-vm versione 6.2.0 o 7.0.1, le uniche release che correggono la vulnerabilità; tutte le versioni fino alla 7.0.0 inclusa sono interessate.
  • Verificare se i sistemi in uso espongono ivm.Reference a sandbox potenzialmente malevoli, poiché anche un singolo riferimento di questo tipo è sufficiente a innescare l'exploit.
  • Auditare le dipendenze transitive: isolated-vm può essere incluso indirettamente tramite framework automation o piattaforme AI, non solo come dipendenza diretta dichiarata.
  • Monitorare l'assegnazione del CVE per GHSA-864f-rcv7-6rh4 e integrare il riferimento nei sistemi di gestione delle vulnerabilità non appena disponibile.

Il blind spot del binding layer e il futuro del sandboxing

La vicenda di isolated-vm non è un'anomalia isolata. È un campione di una categoria di vulnerabilità che prospera nella zona di confine tra primitive sicure e sistemi complessi: il binding layer che traduce astrazioni, il codice di serializzazione che attraversa boundary architetturali, la "colla" scritta in linguaggi memory-unsafe che avvolge motori formalmente verificati. Staicu lo ha sintetizzato come "A perfectly sound building block was undermined by the binding layer wrapped around it."

Per l'industria AI, dove l'esecuzione automatica di codice generato è in rapida espansione, la lezione è duplice: non basta scegliere primitive di isolamento robuste, è necessario verificare sistematicamente lo strato di integrazione che le rende utilizzabili. Il V8 Isolate funziona. Il C++ che lo rende accessibile da Node.js, in questo caso, no. E la differenza tra i due è la differenza tra una sandbox che contiene e una che illude.

Fonti

Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.

Fonti


Fonti e riferimenti
  1. securityweek.com
  2. thehackernews.com
  3. thomasharris6.wordpress.com
  4. devops.com
  5. csoonline.com
  6. podcast.securityweek.com