Una vulnerabilità definita “di massima severità” ha colpito n8n, la popolare piattaforma open source di automazione, esponendo potenzialmente più di 100.000 server a un takeover completo senza neppure richiedere l’accesso autenticato. La vulnerabilità, catalogata come CVE-2026-21858 e battezzata “ni8mare”, ha ottenuto il punteggio massimo di 10.0 nel sistema CVSS, classificandosi quindi nella categoria di rischio più elevata possibile.

Il bug è stato scoperto dal team di ricerca di Cyera, che ha pubblicato un’analisi tecnica dettagliata del problema. L’exploit consente a un aggressore non autenticato di eseguire codice arbitrario sui sistemi vulnerabili, prendendo così il controllo completo del server e dell’intera infrastruttura collegata. Non esiste alcuna mitigazione temporanea: l’unica soluzione è aggiornare immediatamente n8n alla versione 1.121.0 o successiva, dove la falla è stata corretta in modo definitivo.

n8n è una piattaforma ampiamente utilizzata per automatizzare processi e integrare applicazioni tramite flussi di lavoro personalizzabili. Con oltre cento milioni di Docker pulls e centinaia di migliaia di istanze attive, è diventato un punto di riferimento per aziende e sviluppatori che desiderano collegare servizi cloud, database, CRM, chatbot e API di terze parti. È proprio questa diffusione capillare, spesso in ambienti self‑hosted, a rendere la vulnerabilità particolarmente allarmante.

Secondo il rapporto di Cyera, la radice del problema risiede nel modo in cui n8n gestisce i webhook, ossia le chiamate che avviano i flussi automatizzati quando arrivano dati da fonti esterne come moduli web, sistemi di messaggistica o piattaforme di notifica. L’errore sfrutta un caso di “Content‑Type Confusion” per cui, manipolando gli header HTTP, un attaccante può sovrascrivere variabili interne del processo e indurre l’applicazione a eseguire istruzioni non previste. Questo stratagemma consente inizialmente di leggere file dal sistema sottostante, per poi ampliare l’attacco fino all’esecuzione remota di codice.

n8n vulnerabilità

In termini pratici significa che chiunque abbia visibilità di rete su un’istanza vulnerabile di n8n può appropriarsene completamente, senza conoscere alcuna credenziale. Peggio ancora, poiché n8n agisce come un hub centrale che gestisce connessioni verso database, servizi cloud e API aziendali, un’istanza compromessa diventa un punto d’accesso privilegiato all’intero ecosistema digitale di un’organizzazione.

Il ricercatore Dor Attias di Cyera ha sintetizzato l’impatto con una metafora incisiva, immaginando un’azienda di 10.000 dipendenti che utilizza un solo server n8n per orchestrare flussi di lavoro interni. La compromissione di quella macchina significherebbe consegnare agli attaccanti “le chiavi di tutto” tra credenziali API, token OAuth, connessioni a database, account cloud e archivi di file sensibili. Tutte informazioni centralizzate in un punto che, una volta violato, apre la strada a una cascata di intrusioni.

Questa centralizzazione spiega perché il bug “ni8mare” rappresenti un rischio sistemico più che un semplice problema software. n8n, per sua natura, è progettato per coordinare le comunicazioni tra sistemi eterogenei (Google Drive, Salesforce, OpenAI, sistemi IAM, piattaforme di pagamento o pipeline CI/CD) e comprometterlo equivale a colpire il cervello informatico di un’organizzazione.

Va riconosciuto che il team di sicurezza n8n ha reagito con tempestività. Cyera ha segnalato privatamente la vulnerabilità il 9 novembre 2025, ricevendo conferma della sua gravità già il giorno successivo. Il 18 novembre, meno di dieci giorni dopo, la versione corretta (1.121.0) era già disponibile, anche se il rilascio è avvenuto senza un annuncio pubblico di rilievo. Solo nei giorni scorsi, con l’assegnazione ufficiale del CVE, la questione è emersa alla ribalta mediatica.

Questa discrezione, però, ha un effetto collaterale pericoloso. Molte istanze auto‑gestite potrebbero infatti non essere state aggiornate, perché gli amministratori non sempre monitorano i canali ufficiali o le note di sicurezza. E proprio in ambienti self‑hosted n8n è più vulnerabile, essendo spesso esposto in rete per consentire comunicazioni tra diversi sistemi cloud o locali. Non intervenire significa lasciare aperta una porta spalancata verso asset di altissimo valore.