CVE-2026-92944: escape critico dalla sandbox in vm2 per Node.js 26
Vulnerabilità critica (CVSS 9.3) in vm2 consente di sfuggire alla sandbox in Node.js 26. Cos'è, chi colpisce e come proteggersi.
CVE-2026-92944: escape critico dalla sandbox in vm2 per Node.js 26
In breve
È stata pubblicata una vulnerabilità critica (CVE-2026-92944, CVSS 9.3) nella libreria vm2, utilizzata per eseguire codice in ambienti isolati ("sandbox") all'interno di applicazioni Node.js [1]. Il difetto consente a codice non affidabile di sfuggire alla sandbox e di prendere il controllo del processo host quando viene eseguito su Node.js 26 [1][2]. Se la tua azienda sviluppa o utilizza applicazioni che eseguono codice di terze parti o di utenti tramite vm2, il primo passo da compiere oggi stesso è identificare dove viene utilizzata questa libreria e verificare la versione installata.
Cos'è e perché è importante
vm2 è uno strumento molto utilizzato dagli sviluppatori per eseguire codice JavaScript di origine non affidabile all'interno di un ambiente presumibilmente isolato dal resto dell'applicazione: plugin degli utenti, script personalizzati, correttori di esercizi di programmazione, motori di regole, ecc. L'idea è che, qualsiasi cosa accada all'interno di quel codice, esso non possa "uscire" né toccare il sistema reale.
Secondo la descrizione ufficiale del difetto, nelle versioni di vm2 comprese tra la 3.10.2 e la 3.11.6, un meccanismo interno del motore V8 (il protettore chiamato PromiseThenLookupChain) risulta obsoleto in Node.js 26, e questo consente a una funzione asincrona opportunamente costruita da un attaccante di aggirare le protezioni della sandbox tramite il metodo Promise.prototype.finally() [1]. Il risultato è che il codice "isolato" può arrivare a funzioni interne del sistema ed eseguire codice arbitrario con i privilegi del processo principale [1][2].
L'intelligence proprietaria del radar OCIRIA, che monitora le vulnerabilità rilevanti per le infrastrutture di sviluppo e produzione, classifica questo caso nella categoria dell'esecuzione remota di codice e segnala che la sua importanza risiede proprio nel fatto che infrange la premessa di isolamento: se la sandbox fallisce, l'intera applicazione — e potenzialmente altri dati e servizi nello stesso processo — risulta esposta [2].
Per quanto riguarda l'esistenza di uno sfruttamento attivo nel mondo reale, alla data di pubblicazione di questo articolo la CVE non figura nel catalogo delle vulnerabilità sfruttate conosciute (KEV) gestito dall'agenzia statunitense CISA [3]. Questo non significa che sia innocua — il suo punteggio di 9.3 la colloca tra le più gravi [1] — ma che non esistono evidenze documentate di campagne di attacco attive in questo momento.
Chi colpisce
Questa vulnerabilità interessa le organizzazioni che:
- Sviluppano o mantengono applicazioni Node.js che utilizzano la libreria vm2 per isolare l'esecuzione di codice di terze parti o di utenti.
- Hanno aggiornato o stanno distribuendo ambienti su Node.js 26, poiché il difetto si manifesta specificamente in questa versione del runtime a causa di una modifica nel motore V8 [1].
- Gestiscono piattaforme di tipo "codice come servizio": editor online, sandbox di test, motori di automazione, plugin o estensioni eseguite lato server, correttori automatici, ecc.
La verità strutturata gestita da OCIRIA non identifica vendor specifici interessati oltre al pacchetto vm2 stesso, pertanto raccomandiamo di non presumere che un determinato fornitore sia o meno esposto senza verificarlo direttamente.
Come sapere se sei vulnerabile
Non esiste un modo generico per "vederlo a colpo d'occhio": dipende da quali dipendenze utilizza il tuo codice e in quale ambiente viene eseguito. Raccomandiamo di:
1. Rivedere l'inventario delle dipendenze delle vostre applicazioni Node.js (package.json / package-lock.json) alla ricerca di vm2 e verificare la versione esatta installata.
2. Confermare quale versione di Node.js esegue ciascun servizio in produzione, prestando particolare attenzione a quelli che già girano su Node.js 26.
3. Verificare la superficie esposta dei vostri servizi e ambienti di sviluppo, specialmente quelli che accettano o eseguono codice esterno, per individuare punti di esposizione non controllati o non inventariati.
Come proteggerti
- Aggiorna vm2 a una versione corretta non appena il maintainer del progetto la pubblicherà; nel frattempo, considera di limitare o disabilitare temporaneamente le funzionalità che eseguono codice non affidabile se il rischio è elevato [2].
- Rivedi l'uso delle sandbox in generale: dato che questa famiglia di difetti (escape dalla sandbox) tende a ripetersi, valuta se la vostra architettura dipende eccessivamente da un unico meccanismo di isolamento a livello di processo, oppure se conviene rafforzarlo con isolamento aggiuntivo (container, macchine virtuali leggere, permessi del sistema operativo limitati).
- Verifica il codice eseguito in sandbox proveniente da fonti non affidabili: utenti esterni, plugin di terze parti o integrazioni poco controllate.
- Monitora gli avvisi di sicurezza delle librerie critiche che fanno parte della vostra catena di fornitura software, non solo dei framework principali.
- Dai priorità in base all'esposizione reale: se i vostri servizi non eseguono codice di terze parti in sandbox o non utilizzate Node.js 26, il rischio immediato è minore, ma conviene documentarlo per revisioni future.
Domande frequenti
Quanto è grave questa vulnerabilità?
Secondo NVD, ha un punteggio CVSS di 9.3, classificato come critico [1].
Questa vulnerabilità viene sfruttata attivamente?
Alla data di pubblicazione di questo articolo, non risulta nel catalogo delle vulnerabilità sfruttate conosciute (KEV) di CISA, pertanto non vi sono evidenze documentate di sfruttamento attivo [3].
Colpisce qualsiasi applicazione Node.js?
No. Interessa specificamente le applicazioni che utilizzano la libreria vm2 (versioni da 3.10.2 a 3.11.6) per eseguire codice in sandbox, e l'escape descritto si verifica nel contesto di Node.js 26 [1].
Cosa devo fare se non so se uso vm2?
Rivedi l'inventario delle dipendenze dei tuoi progetti Node.js e, se hai dubbi sull'esposizione reale dei tuoi sistemi, conviene effettuare una revisione più ampia della tua superficie esposta.
Fonti
- [1] https://nvd.nist.gov/vuln/detail/CVE-2026-92944
- [2] https://github.com/advisories/GHSA-27g9-p43v-cw3v
- [3] https://raw.githubusercontent.com/cisagov/kev-data/develop/known_exploited_vulnerabilities.json