Questo pezzo riguarda una fetta precisa di lettori: chi ha n8n installato su un server proprio — in azienda o su un VPS — per far girare le automazioni interne. Se usi n8n solo dal servizio in cloud, o se le tue automazioni girano su Zapier o Make, puoi saltare.
Per tutti gli altri: è uscita una falla con punteggio 8,7 su 10, e le versioni corrette sono la 2.31.5 e la 2.32.1.
Cosa succede
L’advisory è il GHSA-gv7g-jm28-cr3m. Il problema sta nella sandbox delle espressioni, cioè la gabbia che dovrebbe impedire al codice scritto dentro un workflow di uscire e toccare il sistema sottostante.
Due lacune permettono di scavalcarla: le arrow function non venivano riscritte correttamente, e i controlli sulle proprietà non intercettavano l’accesso dinamico tramite Reflect.get(). Il risultato è che si arriva all’oggetto process di Node.js — e da lì si eseguono comandi di sistema con i privilegi del processo n8n.
La falla è stata trovata da Security Joes, mentre verificava la tenuta di una correzione uscita a febbraio.
Perché in una piccola impresa il danno non si ferma a n8n
Qui sta il punto che conviene capire bene. n8n non è uno strumento isolato: è il posto dove sono salvate le credenziali di tutto il resto. La casella di posta aziendale, il gestionale, il CRM, il database, magari l’account che manda le fatture o quello che legge i movimenti.
Chi riesce a eseguire comandi sul server può arrivare alle chiavi di cifratura, e con quelle decifrare le credenziali salvate. A quel punto non ha compromesso lo strumento delle automazioni: ha in mano gli accessi a tutto ciò che quelle automazioni toccano.
In una piccola impresa l'installazione di n8n contiene, in un unico punto, le credenziali della posta, del gestionale, del CRM, dei database e dei servizi cloud collegati. Compromettere il server che lo ospita non significa perdere le automazioni: significa consegnare a qualcun altro le chiavi di tutti i sistemi a cui quelle automazioni sono connesse.
Il perimetro reale del rischio
Diciamo anche cosa non è, perché l’allarmismo su queste cose fa più danni della notizia.
Per sfruttare la falla serve un accesso autenticato con permessi di modifica dei workflow. Non è una porta aperta su internet che chiunque può spingere. Il rischio concreto riguarda chi ha più persone con accesso all’editor — collaboratori, consulenti esterni, agenzie — oppure chi ha un’installazione raggiungibile dalla rete con credenziali deboli o mai cambiate.
Al momento della pubblicazione del report non risultava sfruttamento in corso, e non risulta assegnato un identificativo CVE.
Cosa fare, in ordine
- Verifica la versione installata. Se è precedente alla 2.31.5, oppure è la 2.32.0, sei nel perimetro.
- Aggiorna alla 2.31.5 (se resti sul ramo precedente) o alla 2.32.1.
- Ricontrolla i workflow modificati di recente, cercando arrow function o JavaScript offuscato che non ricordi di aver scritto.
- Se hai il dubbio che qualcuno sia entrato, ruota le credenziali salvate nei workflow: sono quelle il vero bottino.
In breve
L’advisory GHSA-gv7g-jm28-cr3m (CVSS 8,7) riguarda le installazioni self-hosted di n8n: sono vulnerabili le versioni precedenti alla 2.31.5 e la 2.32.0, corrette la 2.31.5 e la 2.32.1. Un utente autenticato con permessi di modifica dei workflow può uscire dalla sandbox delle espressioni ed eseguire comandi sul server, arrivando alle chiavi di cifratura e quindi alle credenziali salvate.
Non risulta sfruttamento in corso e non è una falla aggredibile da chi non ha già un accesso. Ma in una PMI l’installazione di n8n concentra gli accessi a posta, gestionale e CRM: è il tipo di server che conviene aggiornare oggi, non alla prossima manutenzione. Restringere i permessi non sostituisce l’aggiornamento.