n8n Ni8mare (CVE-2026-21858) è il tipo di vulnerabilità che trasforma una piattaforma di automazione in un trampolino per l’esecuzione di codice remoto: una catena pulita, ripetibile e devastante che parte da una confusione di Content-Type e arriva a forzare sessioni admin e lanciare comandi sul sistema. Nello stesso periodo, Outlook Encrypt Only si inceppa in una build precisa, interrompendo flussi di posta cifrata in ambienti enterprise, mentre Zestix capitalizza su credenziali cloud rubate dagli infostealer per entrare in decine di aziende, spesso dove l’assenza di MFA rende l’accesso un semplice login.
n8n Ni8mare: dalla confusione Content-Type al controllo completo dell’istanza
n8n nasce come motore di automazione e integrazione: webhook, workflow, nodi che parlano con servizi esterni, e connettori capaci di infilarsi dentro i flussi operativi di un’azienda. Proprio questa natura, quando viene compromessa, rende l’impatto più serio di un semplice bug “applicativo”. Ni8mare, identificata come CVE-2026-21858 con CVSS 10.0, colpisce le versioni precedenti a 1.121.0 e si presenta con un tratto che, in ambito difensivo, fa scattare tutti gli allarmi: è una RCE non autenticata che non richiede credenziali per innescare la fase iniziale.
La sequenza tecnica è importante perché spiega perché la falla non è solo “grave”, ma anche “semplice”. Il cuore del problema è una confusione sul Content-Type nella gestione delle richieste verso endpoint webhook, dove la pipeline di parsing del body si comporta in modo diverso in base agli header. Da un lato, per multipart/form-data, entra in gioco un parser dedicato; dall’altro, per content type differenti, viene usato un percorso di parsing generico. Fin qui tutto normale. Il punto è che una parte della logica che gestisce il ritorno dei dati del webhook, in particolare nello scenario “form”, richiama funzioni che presuppongono la presenza di strutture coerenti per i file caricati, senza verificare in modo rigoroso che il body sia stato effettivamente trattato come upload e che quei campi derivino dal parser previsto.
Questo apre a un trucco concettualmente banale e operativamente letale: l’attaccante invia una richiesta dichiarata application/json, costruisce un body JSON che sovrascrive la struttura attesa dei file, e forza un campo di percorso, un filepath, verso file sensibili del filesystem. A quel punto, una funzione di copia file, progettata per trattare oggetti binari caricati via form, diventa un “file copier” arbitrario. È qui che la vulnerabilità cambia colore: non è più solo “read”, è “read ovunque”.
L’esempio più iconico è la lettura di /etc/passwd, utile per validare che la primitive funzioni e per capire come l’ambiente containerizzato o la VM espongano il filesystem. Ma la vera escalation non passa da /etc/passwd. Passa da un file che in un ambiente n8n self-hosted è spesso il cuore del sistema: il database SQLite dell’istanza. Se l’attaccante riesce a estrarre /home/node/.n8n/database.sqlite, può ottenere elementi che, in combinazione con la chiave segreta dell’applicazione, consentono un salto di livello. Dentro quel database possono comparire userId, email, e informazioni di autenticazione salvate sotto forma di hash o stringhe di supporto. Non sempre sono direttamente “password in chiaro”, ma spesso sono quanto basta per avviare una seconda fase: la forgiatura di sessione.
Il passaggio successivo è ancora più delicato, perché sposta l’attacco dal furto dati all’impersonificazione. Se l’attaccante riesce a leggere anche il file di configurazione, ad esempio /home/node/.n8n/config, può recuperare una chiave segreta utilizzata per firmare cookie o token di sessione. Con quella chiave, la logica di autenticazione può essere aggirata: diventa possibile creare un cookie “valido” per l’applicazione, come un n8n-auth firmato, e presentarsi all’interfaccia web come un utente già autenticato. A quel punto l’attaccante non è più un esterno. È un admin.
E quando l’attaccante è admin, n8n torna a fare ciò per cui è stato progettato, ma al servizio di chi lo sta abusando. L’automazione diventa payload. Un workflow malevolo può includere nodi capaci di eseguire comandi, come un nodo di tipo “Execute Command”, e trasformare l’istanza in un punto di controllo. È il classico finale da manuale: l’RCE applicativa si traduce in comandi sul sistema, con tutte le conseguenze, dal furto di integrazioni a accessi a servizi terzi, fino al movimento laterale.
Questo scenario è particolarmente grave perché n8n, in molte installazioni reali, è collegato a servizi che hanno valore immediato: archivi documentali, CRM, strumenti di ticketing, storage cloud, sistemi di marketing, e spesso credenziali API salvate come variabili di ambiente o segreti applicativi. In pratica, la compromissione di n8n non è solo compromissione di n8n: è compromissione della “colla” che unisce sistemi diversi. In un contesto enterprise, significa rischio di esfiltrazione rapida e silenziosa.
La timeline, per quanto qui conti soprattutto il risultato, rende evidente un punto: la patch è stata rilasciata il 18 novembre 2025, ma la divulgazione completa è arrivata il 7 gennaio 2026, dopo assegnazione CVE al 6 gennaio 2026. Questo intervallo è tipico della divulgazione responsabile, ma in un ecosistema di self-hosted diffuso e spesso esposto, significa anche che molte istanze restano indietro per inerzia. È proprio qui che la mitigazione si trasforma in priorità: aggiornare a 1.121.0 o superiore non è “best practice”, è contenimento del rischio.
La lezione più importante è che questa catena sfrutta un pattern che ritorna spesso nelle applicazioni Node.js e nelle piattaforme web moderne: fidarsi della forma di un oggetto in base a un percorso logico, senza revalidare che quella forma sia stata prodotta dal parser atteso. In un sistema che gestisce file, binari e webhook, questa fiducia diventa un’arma.
Outlook Encrypt Only: quando la cifratura diventa un blocco operativo
Accanto alla falla di n8n, che è un problema di sicurezza diretto e sfruttabile, c’è un’altra storia che sembra più “banale” ma che in azienda può essere altrettanto distruttiva: il bug di Outlook classico relativo ai messaggi Encrypt Only. Qui non si parla di un attaccante che entra. Si parla di un flusso critico che si spezza. E quando si spezza la cifratura, spesso si ferma la comunicazione.
Il comportamento segnalato è specifico e riproducibile: i destinatari non riescono ad aprire email protette “Encrypt Only” dopo un aggiornamento che porta Outlook alla Current Channel Version 2511 build 19426.20218. In pratica, il Reading Pane mostra un prompt o un messaggio che rimanda a credenziali di verifica, e al tentativo di apertura l’utente si ritrova con un allegato del tipo message_v2.rpmsg. Il contenuto resta inaccessibile. L’email “c’è”, ma non è leggibile. La cifratura, invece di proteggere, isola.
Il dettaglio più significativo è che una build precedente, 19426.20186, non presenta lo stesso problema. Questa differenza tra build consecutive indica una regressione: un cambiamento nel codice che gestisce il flusso di decrittazione, l’autenticazione per la lettura protetta o la gestione dei token necessari per sbloccare il contenuto.
In ambienti enterprise, questo bug può produrre un effetto domino. Se un’organizzazione ha policy che impongono Encrypt Only per categorie di comunicazioni, si trova improvvisamente a scegliere tra continuità operativa e aderenza alle regole di protezione. Nel peggiore dei casi, un team potrebbe essere tentato di “abbassare” la protezione per far circolare informazioni urgenti, creando un rischio indiretto: non perché Outlook venga compromesso, ma perché i processi saltano.
I workaround citati sono sintomatici del tipo di problema: salvare l’email prima dell’invio post-criptazione cambia la struttura del messaggio abbastanza da renderlo apribile, oppure eseguire un revert alla build precedente, operazione che in contesti gestiti richiede procedure IT, autorizzazioni e spesso una finestra di intervento. Anche qui, la vulnerabilità non è “exploitabile” nel senso classico, ma è un punto di fragilità sistemica: quando la sicurezza non funziona, le persone la aggirano.
Questo episodio ricorda perché la gestione degli aggiornamenti Office non può essere solo “auto”. In molte aziende, soprattutto dove la posta cifrata è parte dei processi, è necessario un canale di test e una governance delle build. Non per paranoia, ma perché un singolo bug può interrompere la catena di fiducia tra mittente e destinatario.
Infostealer e Zestix: la compromissione che parte da un PC e finisce nel cloud
La terza componente di questo quadro è quella più subdola, perché non dipende da una CVE singola e non richiede un exploit sofisticato. Dipende dalla realtà quotidiana: utenti che scaricano software, password salvate nel browser, sessioni che restano valide, e portali cloud esposti senza un secondo fattore.
Secondo quanto riportato, il threat actor Zestix avrebbe compromesso circa 50 imprese globali, sfruttando credenziali rubate da malware infostealer come RedLine. Il punto qui è che l’infostealer non “buca” il cloud con una vulnerabilità. Buca l’endpoint umano: il dispositivo del dipendente, spesso fuori dal perimetro controllato, e poi porta quelle credenziali a un livello in cui l’accesso diventa legittimo dal punto di vista tecnico.
Il workflow criminale è spietatamente efficiente. Le credenziali rubate finiscono in log aggregati, vengono indicizzate, e poi filtrate cercando URL e domini aziendali, in particolare quelli di servizi cloud e strumenti collaborativi. Se un portale, come alcuni ambienti di file sharing o strumenti di collaborazione, non impone MFA, l’attaccante entra con una semplice autenticazione. Non serve spear phishing. Non serve bypassare l’MFA. Non serve nemmeno essere creativi.
Un filo comune: l’identità come bersaglio e la superficie di attacco come somma
A prima vista, n8n Ni8mare, il bug di Outlook e la campagna infostealer sono storie diverse. In realtà hanno un denominatore comune: l’identità e il controllo degli accessi. Ni8mare dimostra come si possa arrivare a forzare una sessione admin rubando chiavi e database. Outlook mostra come un errore nella gestione della protezione possa bloccare il contenuto e spingere verso workaround. Gli infostealer dimostrano che, se l’identità è rubata e l’MFA manca, non serve alcun exploit per entrare.
La mitigazione, in un contesto operativo serio, non è una singola azione. È una disciplina. Per n8n, significa aggiornare a 1.121.0 e trattare qualsiasi istanza esposta come una superficie ad alto rischio, perché i webhook sono, per definizione, aperture verso l’esterno. Per Outlook, significa gestire le build e testare flussi Encrypt Only prima di spingere aggiornamenti su larga scala. Per il cloud e gli infostealer, significa imporre MFA come baseline non negoziabile e monitorare continuamente credenziali compromesse, sessioni e accessi.
C’è anche una lezione di architettura: più un sistema è “integratore”, più è critico. n8n è un integratore. Quando cade, cade la fiducia tra sistemi. E quando un attaccante entra, non entra in un’app: entra in un nodo di scambio. Lo stesso vale per le identità cloud: non sono un servizio, sono la chiave di accesso a tutti i servizi. In un mondo dove workflow automation e SaaS sono diventati la spina dorsale di molte aziende, le vulnerabilità non colpiscono più solo la singola macchina. Colpiscono la catena operativa. E questa catena, oggi, si difende con patch rapide, controllo delle build, e identità blindate.
Domande frequenti su n8n Ni8mare (CVE-2026-21858)
Ni8mare è davvero una RCE non autenticata o serve un account n8n?
Ni8mare parte come vulnerabilità sfruttabile senza autenticazione nelle versioni precedenti a 1.121.0, perché l’attaccante può innescare la lettura di file e poi forzare l’accesso admin tramite chiavi e sessioni.
Perché la lettura di file porta fino all’esecuzione di comandi sul sistema?
Perché l’estrazione del database e della configurazione può esporre la chiave segreta necessaria a creare una sessione valida; una volta ottenuto l’accesso admin, un workflow con nodi di esecuzione comandi trasforma l’istanza in un punto di controllo.
Il bug Outlook Encrypt Only è una vulnerabilità di sicurezza?
Non è una CVE nel senso classico: è una regressione che impedisce la lettura dei messaggi cifrati in una build specifica, con impatto operativo e rischio indiretto perché può spingere gli utenti ad aggirare la cifratura.
Perché gli infostealer rendono “inutile” la sicurezza cloud senza MFA?
Perché con credenziali rubate l’accesso al cloud appare legittimo; senza MFA l’attaccante entra con un login normale e può esfiltrare dati senza dover sfruttare vulnerabilità del servizio.
Iscriviti alla Newsletter
Non perdere le analisi settimanali: Entra nella Matrice Digitale.
Matrice Digitale partecipa al Programma Affiliazione Amazon EU. In qualità di Affiliato Amazon, ricevo un guadagno dagli acquisti idonei. Questo non influenza i prezzi per te.
