Aggiorna subito n8n se gestisci un’installazione self-hosted o un ambiente in cui più utenti possono modificare i workflow. La correzione elimina una falla nel sandbox delle espressioni che, in alcune versioni, poteva permettere a un utente autenticato di eseguire comandi sul sistema operativo con i privilegi del processo n8n.
Cosa è successo
n8n ha corretto una vulnerabilità ad alta gravità nel motore che interpreta le espressioni dei workflow. Il problema interessava le versioni precedenti alla 2.31.5 e la serie 2.32.0 prima della 2.32.1. La falla è stata classificata come High con punteggio CVSS 8.7 e risulta corretta nelle versioni 2.31.5 e 2.32.1.
In pratica, un utente con credenziali valide e permessi di modifica dei workflow poteva sfruttare un difetto nel sandbox per far eseguire istruzioni sul server. Non serviva l’interazione di un altro utente per attivare l’attacco.
Perché è importante
Il rischio non riguarda solo l’applicazione in sé, ma anche ciò che l’applicazione può raggiungere dall’host compromesso. Se n8n usa credenziali archiviate, chi attacca potrebbe arrivare a dati sensibili, servizi interni, database collegati o endpoint cloud accessibili dalla macchina.
Per molti ambienti, questo significa che un semplice account di editing dei workflow può diventare un punto di ingresso verso l’infrastruttura. Se il server espone segreti o connessioni privilegiate, l’impatto può essere elevato.
Cosa devi fare adesso
- Aggiorna n8n alle versioni corrette, cioè 2.31.5 o 2.32.1 a seconda del ramo installato.
- Non affidarti solo alle restrizioni temporanee su accesso all’istanza o modifica dei workflow: sono misure utili, ma non sostituiscono la patch.
- Controlla i workflow creati o modificati di recente, soprattutto se contengono espressioni insolite, funzioni arrow o JavaScript offuscato.
- Verifica i processi figli del servizio n8n o di Node.js alla ricerca di shell, PowerShell, curl o wget.
- Ruota le credenziali se trovi segnali di esecuzione sospetta o accessi anomali a host e servizi interni.
Come funzionava il problema
n8n usa espressioni come ={{ $json.email }} per recuperare dati dal contesto del workflow. Dietro le quinte, un rielaboratore dell’AST tenta di indirizzare gli identificatori JavaScript verso il contesto controllato da n8n invece che verso il runtime Node.js.
Nella versione vulnerabile, una particolare gestione delle arrow function lasciava un vuoto: una forma compatta come () => process poteva far emergere il vero oggetto globale process di Node.js invece della versione sandboxata. Questo apriva la porta a un secondo passaggio, perché process permette di accedere a funzionalità di sistema molto potenti.
Il problema non finiva lì. Le verifiche sulle proprietà statiche nei member expression non coprivano tutti i casi in cui la proprietà veniva richiesta in modo dinamico. Gli analisti hanno usato questa differenza per raggiungere process.getBuiltinModule, caricare child_process ed eseguire un comando sull’host.
Impatto reale per gli ambienti esposti
In una distribuzione dove n8n conserva credenziali con privilegi ampi o può parlare con sistemi interni critici, l’abuso di questa falla può trasformare un account di workflow editing in un vettore di compromissione del server. Da lì, l’attaccante può tentare movimenti laterali, consultare dati protetti o manipolare automazioni sensibili.
Questo rende particolarmente importante limitare i permessi di editing ai soli utenti realmente affidabili e monitorare con attenzione i cambiamenti ai flussi di lavoro. Tuttavia, la misura davvero efficace resta l’installazione della versione corretta.
Segnali da cercare nei log e nei sistemi
Gli amministratori dovrebbero concentrarsi su alcuni indicatori pratici:
- creazione o modifica recente di workflow con espressioni insolite;
- uso di JavaScript poco leggibile o deliberatamente offuscato;
- avvio di shell interattive o comandi di sistema da parte del processo n8n;
- comparsa di PowerShell, curl o wget come processi figli;
- accessi anomali a credenziali archiviate o servizi interni dopo l’esecuzione di workflow sospetti.
Se questi segnali compaiono, conviene trattare l’istanza come potenzialmente esposta e verificare sia la configurazione sia l’integrità dei dati sensibili.
Contesto della vulnerabilità
La falla si inserisce in una serie di problemi legati al sandbox delle espressioni che n8n ha dovuto correggere nel tempo. In questo caso, il problema è stato individuato durante l’analisi di una precedente correzione e poi segnalato tramite il programma di divulgazione della vulnerabilità.
La patch introduce una gestione dedicata per le arrow function, in modo che un identificatore semplice all’interno di un corpo conciso venga instradato correttamente nel contesto dati controllato da n8n. Questo riduce il rischio che il runtime Node.js venga raggiunto per errore.
Cosa significa per chi usa n8n ogni giorno
Per l’utente comune, il messaggio è semplice: se usi n8n, controlla la versione adesso. Per chi amministra un ambiente di produzione, la priorità è verificare gli account con diritti di modifica e assicurarsi che l’istanza non sia esposta a utenti non fidati.
L’aggiornamento è particolarmente urgente quando n8n ha accesso a segreti, database, API interne o risorse cloud. In questi casi, una falla nel sandbox non resta confinata all’applicazione, ma può diventare un problema di sicurezza più ampio per tutta l’infrastruttura.
Technical Deep Dive
La vulnerabilità riguarda il meccanismo di riscrittura delle espressioni usato da n8n per isolare il codice del workflow dal runtime sottostante. Il sistema tenta di intercettare identificatori liberi e reindirizzarli verso una data context controllata, invece di lasciarli risolvere nel contesto globale di Node.js.
Secondo l’analisi tecnica, in 2.31.4 la logica di VariablePolyfill.ts trattava ArrowFunctionExpression in un ramo di no-op. Questo lasciava scoperto un caso in cui una concise arrow body, ad esempio () => process, poteva risolvere process come globale reale. Il fix inserito nelle versioni corrette aggiunge invece un gestore specifico per ArrowFunctionExpression, così che l’identificatore venga riscritto nel contesto dati atteso.
Il secondo punto debole riguardava i controlli sulle proprietà dei member expression. Le verifiche statiche non intercettavano sempre le richieste di proprietà passate come argomento dinamico a Reflect.get(). In questo modo, un attaccante poteva recuperare process.getBuiltinModule, caricare il modulo child_process e arrivare all’esecuzione di comandi sul sistema ospite.
L’elemento chiave è la combinazione dei due difetti: uno riguardava la mancata trasformazione dell’identificatore, l’altro la capacità di aggirare i controlli sulle proprietà. Separatamente, ciascun difetto non bastava; insieme, consentivano l’escape dal sandbox. Questo spiega perché i test non abbiano coperto il percorso completo e perché la correzione richieda sia la gestione esplicita delle arrow function sia una revisione delle assunzioni sulle property resolution.
Le versioni interessate sono state identificate come <2.31.5** e **>=2.32.0,<2.32.1. Gli amministratori dovrebbero verificare il ramo installato, aggiornare al release corretto e poi rivedere i workflow esistenti alla ricerca di costrutti JavaScript anomali. In ambienti sensibili, è opportuno affiancare all’upgrade una rotazione delle credenziali e un controllo dei processi generati dal servizio.
Dal punto di vista difensivo, i log di sistema e i tracciamenti dei job automation possono offrire indizi utili: spawn inattesi di shell, utility di download o processi di scripting figli del demone n8n meritano un’analisi immediata. Se l’istanza gestisce credenziali ampie, il rischio non è solo l’abuso del workflow editor, ma anche l’accesso a risorse che quell’editor può orchestrare indirettamente.
Fonte: https://thehackernews.com/2026/07/n8n-sandbox-escape-lets-workflow.html
