Vulnerabilità grave nei workflow di n8n: qualsiasi utente può eseguire comandi sul server
L’ecosistema di n8n, una delle piattaforme open source più diffuse per l’automazione dei workflow, torna al centro dell’attenzione della comunità di cybersecurity dopo l’allarme di inizio anno per una vulnerabilità ad alta gravità che avrebbe potuto compromettere completamente i server su cui il software è installato. Il problema riguarda il motore che interpreta le espressioni JavaScript utilizzate nei flussi di automazione e rappresenta, di fatto, un nuovo metodo per aggirare le protezioni introdotte nei mesi scorsi dopo la correzione di una precedente vulnerabilità critica.
La falla è stata individuata dai ricercatori di Security Joes durante un’analisi della patch distribuita a febbraio per correggere la vulnerabilità CVE-2026-27577. L’obiettivo iniziale era verificare la presenza di possibili bypass residui e, proprio nel corso di questa attività, gli esperti hanno scoperto un nuovo percorso capace di eludere il meccanismo di isolamento delle espressioni, consentendo a un utente autenticato con privilegi di modifica dei workflow di arrivare fino all’esecuzione di comandi direttamente sul sistema operativo che ospita n8n.
Il problema interessa tutte le versioni precedenti alla 2.31.5 e quelle comprese tra la 2.32.0 e la 2.32.1 esclusa. Gli sviluppatori hanno corretto la vulnerabilità con le release 2.31.5 e 2.32.1, classificandola con l’identificativo GHSA-gv7g-jm28-cr3m e assegnandole un punteggio CVSS 4.0 di 8,7, sufficiente per essere considerata una vulnerabilità di livello elevato.
L’aspetto più delicato riguarda i privilegi necessari per sfruttare l’exploit, visto che non è richiesta alcuna interazione da parte di altri utenti né tecniche di phishing o social engineering. È sufficiente che un attaccante disponga di un account valido con autorizzazioni per creare o modificare workflow. In numerosi ambienti aziendali questa possibilità è concessa a sviluppatori, amministratori di processo o personale DevOps, ampliando sensibilmente la superficie di attacco nel caso in cui uno di questi account venga compromesso.
Dal punto di vista tecnico, la vulnerabilità nasce dal funzionamento del sistema con cui n8n interpreta le espressioni JavaScript inserite all’interno delle automazioni. Espressioni come ={{ $json.email }} vengono elaborate attraverso un meccanismo che riscrive l’albero sintattico del codice per impedire l’accesso diretto agli oggetti globali del runtime Node.js, sostituendo invece i riferimenti con un contesto dati controllato dalla piattaforma. Secondo l’analisi di Security Joes, una particolare gestione delle Arrow Function lasciava però scoperto uno scenario specifico. Quando il corpo della funzione era costituito da un identificatore particolarmente semplice, il sistema non applicava correttamente la riscrittura prevista, permettendo quindi di recuperare il riferimento reale all’oggetto process di Node.js anziché alla versione isolata prevista dalla sandbox.
Crediti: Shutterstock
La seconda parte dell’attacco sfrutta invece il comportamento di Reflect.get(), funzione che riceve il nome della proprietà come parametro invece di utilizzare un accesso diretto agli attributi dell’oggetto. Questo dettaglio consentiva di aggirare i controlli statici implementati da n8n sulle proprietà accessibili, recuperando funzioni normalmente irraggiungibili come process.getBuiltinModule. Da qui diventava possibile caricare il modulo child_process ed eseguire programmi direttamente sul sistema operativo. I ricercatori hanno verificato la validità della tecnica su diverse versioni della piattaforma, dalla 2.30.4 fino alla 2.31.4, sia utilizzando il pacchetto ufficiale distribuito da n8n sia installando localmente il software. Il confronto tra il codice sorgente delle versioni 2.31.4 e 2.31.5 conferma inoltre l’introduzione di un nuovo gestore dedicato proprio alle Arrow Function, che chiude una parte fondamentale della catena di attacco descritta nel report tecnico.
Gli esperti sottolineano inoltre che nessuno dei due comportamenti individuati sarebbe stato sufficiente, singolarmente, a compromettere il sistema. L’exploit completo nasce infatti dalla combinazione delle due debolezze, entrambe sfuggite ai test automatici implementati durante la precedente correzione. È anche questo il motivo per cui la nuova vulnerabilità rappresenta un’evoluzione diretta della CVE-2026-27577 e non una problematica completamente indipendente.
Le possibili conseguenze di un attacco riuscito sono particolarmente significative. Una volta ottenuta l’esecuzione di codice sul server, un aggressore potrebbe accedere alla variabile N8N_ENCRYPTION_KEY, utilizzata dalla piattaforma per proteggere le credenziali archiviate. In presenza di questa chiave diventerebbe teoricamente possibile decifrare password, token API e altri segreti memorizzati nei workflow, aprendo l’accesso a database, servizi interni, infrastrutture cloud e sistemi collegati all’istanza compromessa. Security Joes precisa di non aver osservato tentativi di sfruttamento reali durante la fase di ricerca e anche l’avviso pubblicato da n8n non riporta evidenze di attacchi avvenuti prima della distribuzione delle patch. Questo non riduce però l’urgenza dell’aggiornamento, soprattutto considerando che la piattaforma viene spesso utilizzata come punto di integrazione tra numerosi servizi aziendali, diventando un nodo privilegiato dal quale raggiungere sistemi particolarmente sensibili.
Per gli amministratori la raccomandazione principale rimane l’installazione immediata delle versioni corrette. Le misure temporanee suggerite inizialmente, come limitare l’accesso all’istanza ai soli utenti fidati o restringere le autorizzazioni di modifica dei workflow, vengono infatti considerate dagli stessi sviluppatori esclusivamente mitigazioni provvisorie e non una soluzione definitiva. Al tempo stesso, è consigliabile analizzare i workflow creati o modificati di recente verificando la presenza di funzioni JavaScript sospette o codice offuscato, oltre a controllare eventuali processi anomali come shell, PowerShell, curl o wget avviati dal processo Node.js associato a n8n. In presenza di qualsiasi attività sospetta, è opportuno procedere anche alla rotazione delle credenziali archiviate nella piattaforma, così da limitare eventuali movimenti laterali verso altri sistemi aziendali.
