← Tutti gli approfondimenti STRUMENTI E COSTI

n8n ha corretto 15 falle di sicurezza: tre domande per sapere se tocca a te

Il 14 ottobre 2026 n8n ha pubblicato 15 correzioni di sicurezza. Se il tuo n8n è quello in cloud, ci pensa n8n. Se è installato su un server, spesso messo in piedi da un consulente o da un conoscente, qualcuno deve aggiornarlo. Tre domande per capire se ti tocca, e cosa chiedere a chi te l’ha installato.

n8n è il programma che collega fra loro le app che usi e fa partire da solo i passaggi ripetitivi: un modulo del sito che finisce nel gestionale, un messaggio che parte quando arriva un ordine. Il 14 ottobre 2026, alle 11:29 UTC (le 13:29 in Italia), il team di sicurezza di n8n ha pubblicato nella sua community un avviso con 15 falle corrette: 5 che chiama «alte» e 10 «medie».

Chi usa n8n in cloud, cioè sui server di n8n, non deve fare niente: l’avviso scrive che la sua istanza viene aggiornata in automatico. Chi ha n8n su un server proprio deve controllare la versione e, se è più vecchia di quelle corrette, aggiornarla: l’avviso dice «at your earliest convenience», cioè appena possibile.

Quello che segue l’ho letto il 14 e il 15 ottobre 2026 sull’avviso e su ciascuna delle 15 schede che n8n pubblica su GitHub. Non sono un esperto di sicurezza informatica e non ho provato nessuna falla: riporto cosa dicono le fonti, e quando una frase è una mia lettura lo scrivo.

Cosa dice l’avviso, e cosa non dice

• I numeri. 15 falle: 5 «alte» e 10 «medie». Nessuna ha un codice CVE, il numero con cui le falle di sicurezza vengono catalogate a livello internazionale: l’avviso usa solo gli identificativi di GitHub.
• Le versioni. «v1 patched in v1.123.85, beta patched in v2.44.1, stable patched in v2.43.5». Cioè: la correzione c’è nella 1.123.85 per chi è sul vecchio ramo 1, nella 2.43.5 per il ramo 2 indicato come «stable» e nella 2.44.1 per il ramo «beta». Alcune falle erano già corrette in versioni precedenti, per esempio la 2.41.4: le tre dell’avviso sono quelle che le comprendono tutte.
• Chi deve muoversi. Il cloud no. Il server proprio sì, se la versione è più bassa. E chi è già all’ultima correzione del suo ramo, scrive l’avviso, non deve fare niente.
• Cosa non c’è. L’avviso e le schede che ho letto non parlano di sfruttamenti, né attivi né passati, e non dicono quante installazioni siano coinvolte. Non lo so, e non voglio farlo sembrare più grave o meno grave di quello che le fonti dicono.

Un’avvertenza sui numeri: sulle schede di GitHub, una delle cinque falle che l’avviso chiama «alte» (quella sui segreti delle credenziali nei dati di errore) risulta «moderata», con punteggio 5,3. Non cambia cosa fare, ma i due elenchi non coincidono del tutto.

Le falle in parole semplici

Quindici schede sono tante, ma si raggruppano in quattro tipi. Il criterio è mio, non di n8n: guardo cosa serve a qualcuno per approfittarne.

• Serve già un account dentro n8n (11 falle: le 5 alte e 6 medie). Un utente, anche con permessi bassi, poteva leggere password o token rimasti nei dati di un errore (nei nodi Git, MongoDB, Google Cloud Storage e SeaTable); leggere e modificare le tabelle di dati di altri progetti; ottenere il valore di credenziali a cui non aveva diritto; usare, se aveva solo il ruolo di chat, strumenti che quel ruolo non prevede; bloccare il servizio con un flusso costruito apposta; far eseguire uno script nella pagina di n8n di un altro utente che apre l’indirizzo di un webhook, cioè di un collegamento che fa partire un flusso.
• Un flusso che passa dati esterni dentro un filtro (2 falle). Nei nodi Quick Base, Microsoft Outlook e SharePoint v1, un valore costruito apposta può cambiare cosa cerca il filtro: per esempio far restituire tutti i contatti di una casella invece di uno. Resta dentro i permessi della credenziale salvata, e riguarda solo chi usa quei nodi con dati che arrivano da fuori, come un modulo del sito. Le schede non dicono se serva un account: il punteggio di GitHub indica «privilegi bassi».
• Chi conosce l’indirizzo del webhook di Slack (1 falla). Se il nodo Slack Trigger è usato e nella credenziale manca il «signing secret», la scheda scrive che chi conosce l’indirizzo poteva far mandare il token di accesso a Slack a un server a sua scelta.
• Un clic su un link preparato (1 falla). Vale solo se sul computer c’è l’app Local Gateway di n8n, installata e in esecuzione: il clic poteva collegarla a un’istanza di n8n controllata da un altro.

Cosa ne ricavo, ed è una lettura mia: se nel tuo n8n entrano solo tu e persone di cui ti fidi, la parte «account» pesa meno; se ci sono utenti che non conosci più, o l’account dimenticato di un ex collaboratore, pesa di più. Non vuol dire che puoi non aggiornare: come misura temporanea le schede dicono di limitare l’accesso a persone fidate, e avvertono che non basta a togliere il rischio.

Tre domande per sapere se tocca a te

• 1. È cloud o è un server tuo? Se chi te l’ha attivato ha parlato di «server», «VPS» o «Docker», è un’installazione propria. Se hai un abbonamento con n8n, di solito è il cloud. Nel dubbio, chiedilo: la risposta cambia tutto il resto.
• 2. Che versione è? Nell’editor di n8n c’è una pagina «About n8n» che mostra la versione: lo scrivono utenti della community, mentre nella documentazione ufficiale non ho trovato il percorso dei menu. Se non la trovi, fattela mostrare da chi lo gestisce. Il numero comincia per 1 o per 2 e deve essere almeno 1.123.85, 2.43.5 o 2.44.1, secondo il ramo. Un numero più basso, come 2.40 o 2.41, va aggiornato.
• 3. Chi ha un account? Chiedi l’elenco degli utenti e dei ruoli: nell’avviso e nelle schede si parla di «member», di «editor» e di utenti solo chat. Togli chi non lavora più sui flussi.

Cosa chiedere a chi te l’ha installato

Non devi saper aggiornare n8n. Devi saper fare le domande, e capire se la risposta è una risposta.

• Che versione c’è oggi, e quando è stata aggiornata l’ultima volta? Se non lo sa dire subito, è già un’informazione.
• Chi la aggiorna, e ogni quanto? La documentazione di n8n scrive «Try to update at least once a month», e spiega che aggiornare spesso evita di dover saltare più versioni in una volta e riduce il rischio che l’aggiornamento rompa qualcosa. Nella pagina dell’avviso sono elencati anche quelli del 20 agosto, del 2 e del 16 settembre e del 1 ottobre: gli aggiornamenti di sicurezza arrivano più spesso di una volta al mese.
• C’è una copia dei dati, prima di aggiornare? La documentazione sull’installazione con Docker indica che la cartella dei dati di n8n contiene anche le chiavi di crittografia: è la cosa da avere copiata prima di toccare qualunque cosa.
• Si prova prima da qualche parte? La documentazione suggerisce di provare l’aggiornamento su una copia di prova e cita la funzione «Environments». Non so se sia disponibile su ogni installazione: chiedilo.
• Chi ha un account, e serve ancora? È la domanda 3, detta a chi può rispondere.
• Vanno cambiati password o token? Le schede non dicono che serva per tutti. Per due casi lo indicano come misura: i token di Slack dei flussi con Slack Trigger e i token API di SeaTable. Per gli altri dipende da chi poteva vedere i dati degli errori: chiedi a chi gestisce se ha senso, soprattutto se i tuoi flussi usano Git, MongoDB, Google Cloud Storage o SeaTable.
• Quanto costa tenerlo aggiornato, e chi lo paga? Nel mio confronto fra gli strumenti ho scritto che n8n installato in proprio «non è gratis, è senza canone»: restano il server, gli aggiornamenti e i salvataggi. Se la risposta è «non so», sai già qual è il costo nascosto.

Cloud o server proprio, senza tifo

Il cloud ha un canone e i dati stanno sui server di n8n. L’installazione propria non ha canone e tiene i dati da te, ma porta con sé il lavoro che hai appena letto. Non c’è una risposta giusta per tutti: dipende da chi si ricorderà di aggiornare. Se alla domanda «chi lo aggiorna» la risposta è «nessuno in particolare», il canone smette di essere il costo principale. Se hai già qualcuno che lo fa ogni mese, e lo fa davvero, l’installazione propria regge. I prezzi e i conti li ho messi nel confronto Make, Zapier o n8n: quale conviene a chi.

Una seconda scadenza all’orizzonte

La documentazione di n8n ha una pagina sulle modifiche della versione 3.0: le installazioni fatte con npm, invece che con Docker, non sono più supportate, e alcuni nodi vecchi vengono tolti. La pagina prima dell’aggiornamento rimanda al «Migration Report», nelle impostazioni, che elenca cosa va sistemato nella tua istanza. Nella pagina la riga sotto il titolo dice «coming» e il testo «has been released», e l’avviso del 14 ottobre non cita versioni 3.x: non so dirti se sia già uscita. Se il tuo n8n è stato installato con npm, aggiungi una domanda a chi lo gestisce: cosa succede quando si passa alla 3.0?

Cosa non so dirti

• Se le falle siano state sfruttate. Non è indicato né nell’avviso né nelle schede che ho letto.
• Quante installazioni siano a rischio. Non è indicato.
• Se il tuo flusso usa proprio uno dei nodi citati. Dipende da come è costruito: lo sa chi l’ha costruito, o si guarda dentro n8n.
• Il resto della sicurezza del tuo server. Questo pezzo parla solo delle 15 correzioni del 14 ottobre.