Allarme Node.js: RCE critico nella libreria vm2. Intanto Google lancia la verifica crittografica per le app Android

La libreria vm2 per Node.js presenta una serie di vulnerabilità critiche che permettono agli attaccanti di evadere dal sandbox ed eseguire codice arbitrario direttamente sul sistema host. La falla più grave, identificata come CVE-2026-26956, sfrutta una gestione errata delle eccezioni tra ambiente isolato e processo ospite, trasformando il sandbox in un vettore di Remote Code Execution completo. Parallelamente, Google introduce un nuovo sistema di verifica pubblica delle app Android basato su registro crittografico append-only per contrastare manipolazioni della supply chain software. Le due novità affrontano scenari diversi ma complementari: da un lato la protezione dell’isolamento nei server Node.js, dall’altro l’integrità verificabile delle applicazioni distribuite su Android. Il caso vm2 coinvolge piattaforme SaaS, ambienti CI/CD, editor online e sistemi di automazione che eseguono codice non fidato all’interno di sandbox JavaScript. La nuova verifica Android rafforza invece la trasparenza dell’ecosistema mobile Google, garantendo che ogni applicazione distribuita corrisponda esattamente al binario approvato e pubblicato ufficialmente. Entrambi gli eventi mostrano quanto la sicurezza moderna dipenda sempre di più da isolamento robusto, verificabilità crittografica e audit continui delle componenti software più critiche.

vm2 permette sandbox escape ed esecuzione di codice arbitrario sull’host

La vulnerabilità più grave scoperta in vm2 sfrutta il modo in cui il motore V8 di Google gestisce le eccezioni WebAssembly tra sandbox e host Node.js. La libreria, utilizzata per eseguire codice JavaScript non fidato in ambienti isolati, fallisce nel sanitizzare correttamente alcuni oggetti di errore che attraversano il confine tra contesto sandboxed e processo ospite. Gli attaccanti possono generare un TypeError tramite coercizione Symbol-to-string e utilizzare l’eccezione risultante per recuperare riferimenti a oggetti dell’host. Una volta ottenuto accesso alla catena dei costruttori JavaScript dell’ambiente reale, il codice malevolo riesce a recuperare l’oggetto process di Node.js e ad avviare comandi arbitrari sul server. Un proof-of-concept pubblico dimostra come il bypass consenta di passare dal sandbox all’esecuzione completa di codice sull’host senza richiedere privilegi aggiuntivi. La falla colpisce in particolare Node.js 25 con supporto WebAssembly exception handling abilitato e trasforma vm2 da meccanismo di sicurezza a potenziale porta di compromissione totale del sistema. La criticità della CVE-2026-26956 deriva proprio dal fatto che vm2 viene spesso utilizzata in ambienti multi-tenant dove utenti esterni eseguono codice all’interno di infrastrutture condivise. Una singola evasione dal sandbox può quindi compromettere interamente il server che ospita la piattaforma.

Una dozzina di vulnerabilità critiche colpisce le versioni recenti di vm2

Nota di Sicurezza: Questo blocco di vulnerabilità dimostra un’elevata instabilità nei meccanismi di isolamento della sandbox in queste versioni. È fondamentale notare la presenza di ben tre CVE con punteggio massimo (10.0), che garantiscono l’uscita dalla sandbox e l’iniezione di codice diretto sull’host. Si raccomanda l’aggiornamento immediato almeno alla versione 3.11.2 per mitigare l’intera catena di exploit.

I ricercatori hanno identificato almeno dodici tecniche differenti per aggirare il sandbox di vm2. Oltre al bug principale legato alle eccezioni WebAssembly, le falle coinvolgono meccanismi come lookupGetter, gestione della proprietà species degli oggetti Promise, utilizzo improprio di inspect, manipolazione di SuppressedError e scenari di prototype pollution controllati dall’attaccante. Alcuni bypass permettono inoltre di aggirare le whitelist di NodeVM e caricare moduli normalmente proibiti come child_process, aprendo la strada all’esecuzione diretta di comandi di sistema. Vulnerabilità nei metodi BaseHandler.getPrototypeOf e neutralizeArraySpeciesBatch() consentono invece iniezione di codice e manipolazione della catena di esecuzione interna. Le versioni vulnerabili comprendono diversi rami della libreria, dalla 3.9.6 fino alla 3.11.1. Questo rende l’impatto estremamente ampio perché vm2 viene utilizzata da piattaforme di coding online, tool DevOps, orchestratori di automazione e servizi cloud che eseguono script utente dinamici. Gli sviluppatori che integrano vm2 nelle proprie applicazioni devono considerare la possibilità concreta di compromissione completa dell’infrastruttura ospite.

Google introduce la verifica pubblica crittografica per le app Android

Mentre la community Node.js affronta il problema vm2, Google introduce un nuovo sistema di verifica pubblica per le applicazioni Android distribuite ufficialmente. Il meccanismo utilizza un registro crittografico append-only simile al modello Certificate Transparency già utilizzato nel settore TLS. Ogni applicazione Google prodotta dopo il primo maggio 2026 genera una voce pubblica verificabile che certifica l’autenticità esatta del binario distribuito. Gli utenti e i ricercatori possono controllare il registro tramite tool open source pubblicati da Google per verificare che il software installato corrisponda realmente alla versione approvata e rilasciata dall’azienda. Il sistema copre non soltanto le app standalone ma anche Google Play Services e i moduli Mainline del sistema operativo Android. La verifica aggiunge quindi un livello ulteriore rispetto alla tradizionale firma digitale, garantendo non solo l’integrità tecnica del pacchetto ma anche la prova pubblica che Google abbia effettivamente autorizzato quel preciso binario.

La verifica Android contrasta gli attacchi supply chain avanzati

Gli attacchi supply chain moderni puntano spesso a modificare software legittimo mantenendo intatte le firme digitali originali o sfruttando infrastrutture di build compromesse. Il nuovo sistema di verifica pubblica Android affronta direttamente questo problema introducendo una fonte crittografica verificabile pubblicamente che registra ogni release ufficiale. Gli utenti possono così confrontare l’app installata sul dispositivo con il registro pubblico per verificare che corrisponda esattamente alla build autorizzata da Google. Se il binario non compare nel ledger, significa che non è stato rilasciato come versione di produzione ufficiale. Questo approccio aumenta notevolmente la trasparenza della supply chain Android e riduce il rischio di manipolazioni silenziose distribuite tramite canali compromessi. Google estende inoltre un concetto già utilizzato internamente con Pixel Binary Transparency, rendendolo disponibile all’intero ecosistema Android. L’iniziativa rafforza sia la fiducia degli utenti sia la capacità dei ricercatori di sicurezza di verificare autonomamente autenticità e integrità delle applicazioni distribuite.

vm2 e Android mostrano due facce della sicurezza moderna

Le vulnerabilità di vm2 e il nuovo sistema di verifica Android affrontano problemi differenti ma evidenziano una tendenza comune: la necessità di rendere gli ecosistemi software più verificabili, trasparenti e resilienti contro attacchi sofisticati. Nel caso vm2, il problema nasce dalla difficoltà estrema di isolare realmente codice non fidato all’interno di ambienti JavaScript complessi. Nel caso Android, Google cerca invece di garantire che il software distribuito non possa essere alterato senza lasciare tracce verificabili pubblicamente. Gli sviluppatori Node.js devono aggiornare immediatamente vm2 alle versioni corrette per evitare compromissioni complete dei server. Gli utenti Android ottengono invece un nuovo strumento per verificare direttamente l’autenticità delle applicazioni Google installate sui propri dispositivi. Entrambi gli scenari dimostrano quanto la sicurezza software moderna richieda approcci multilivello che combinano sandbox robuste, auditing continuo e trasparenza crittografica pubblica.

Aggiornare vm2 è ora essenziale per tutte le piattaforme Node.js

Gli sviluppatori che utilizzano vm2 devono verificare immediatamente la versione installata e aggiornare senza ritardi alle release corrette, incluse 3.11.2 e 3.10.5. Le piattaforme che eseguono script utente o codice non fidato rappresentano il contesto più esposto e rischiano compromissioni complete dell’infrastruttura host in caso di exploit riuscito. La community Node.js ha reagito rapidamente pubblicando patch e documentazione tecnica dettagliata, ma il caso sottolinea ancora una volta quanto sia complesso costruire sandbox realmente sicure sopra ambienti dinamici come JavaScript e V8. Anche piccoli errori nella gestione delle eccezioni o dei prototipi possono infatti trasformarsi in bypass critici dell’intero sistema di isolamento. Nel frattempo Google continua il rollout della verifica pubblica Android, spingendo verso un modello in cui la trasparenza crittografica diventa parte integrante della fiducia software. L’evoluzione parallela di queste due vicende mostra chiaramente che la sicurezza moderna non dipende più soltanto dalla prevenzione degli attacchi ma anche dalla capacità di verificare pubblicamente integrità, autenticità e comportamento delle componenti software più sensibili