Cisa ha aggiunto la vulnerabilità CVE-2025-68613 di n8n al catalogo Known Exploited Vulnerabilities, confermando che la falla è stata sfruttata attivamente e imponendo alle agenzie federali statunitensi di applicare la correzione entro il 25 marzo 2026 secondo la direttiva BOD 22-01. La vulnerabilità riguarda il sistema di valutazione delle espressioni della piattaforma di automazione e consente a un attaccante autenticato di eseguire codice arbitrario con i privilegi del processo n8n, arrivando alla compromissione completa dell’istanza. Nello stesso scenario di allerta, il plugin Ally per WordPress, sviluppato da Elementor, è stato corretto per una vulnerabilità SQL injection non autenticata che colpisce centinaia di migliaia di siti e può consentire l’estrazione di dati sensibili dal database. (cisa.gov)
Cosa leggere
La vulnerabilità di n8n entra nel radar prioritario della Cisa
L’inserimento di n8n nel catalogo KEV non è un passaggio formale qualunque, ma un segnale molto preciso per tutto il mondo della sicurezza: la falla non è più soltanto teorica, ma rientra in quelle vulnerabilità che la Cisa considera concretamente pericolose per le reti reali. La scheda KEV relativa a CVE-2025-68613 conferma che il problema riguarda un improper control of dynamically-managed code resources e impone alle agenzie del ramo esecutivo civile federale di intervenire entro il 25 marzo 2026, una finestra molto stretta che riflette l’urgenza del rischio.
CVE-2025-68613 n8n Improper Control of Dynamically-Managed Code Resources Vulnerability
Anche se l’obbligo diretto vale per il perimetro federale statunitense, la stessa Cisa raccomanda a tutte le organizzazioni di adottare la stessa priorità, perché il KEV viene utilizzato proprio per segnalare le vulnerabilità che stanno già entrando nelle catene d’attacco operative.
Come funziona la falla RCE in n8n
Il cuore del problema è nel sistema con cui n8n valuta le espressioni all’interno dei workflow. Secondo l’advisory di sicurezza pubblicato dal progetto su GitHub, la piattaforma contiene una vulnerabilità Remote Code Execution che permette, in condizioni specifiche, a un utente autenticato di far valutare espressioni in un contesto non sufficientemente isolato dal runtime sottostante. In termini pratici, questo significa che chi ha accesso alla creazione o modifica dei workflow può arrivare a eseguire comandi sul server, leggere dati sensibili, alterare processi di automazione e utilizzare l’istanza come trampolino per ulteriori movimenti laterali. La gravità è elevatissima perché n8n gestisce spesso chiavi API, token, credenziali cloud e flussi aziendali critici, quindi una compromissione non si limita al singolo nodo applicativo ma può propagarsi a ecosistemi molto più ampi. (GitHub)
La patch esiste da dicembre, ma il rischio resta alto
Il progetto n8n ha corretto il problema con la versione 1.122.0, pubblicata il 19 dicembre 2025 nell’ambito dell’advisory ufficiale. Nella stessa comunicazione il vendor ha raccomandato l’aggiornamento immediato, spiegando che la release introduce salvaguardie aggiuntive per limitare la valutazione delle espressioni. Il punto critico, però, è che la disponibilità della patch non coincide automaticamente con la messa in sicurezza del parco installato. Nelle piattaforme di automazione self-hosted, il ritardo nell’aggiornamento è spesso dovuto a dipendenze applicative, workflow legacy o timori di regressione. È proprio in questo intervallo che le falle critiche diventano interessanti per gli attaccanti: la documentazione tecnica è pubblica, la patch rivela indirettamente la superficie del bug e la finestra tra disclosure e remediation diventa terreno fertile per exploit opportunistici. (GitHub)
Le mitigazioni temporanee non bastano senza upgrade
Il team di n8n ha indicato anche alcune mitigazioni temporanee, come la limitazione dei permessi di creazione e modifica dei workflow ai soli utenti pienamente fidati e l’esecuzione della piattaforma in un ambiente hardenizzato con privilegi OS e accesso di rete più restrittivi. Si tratta di misure utili per ridurre la superficie di attacco, ma lo stesso advisory chiarisce che non eliminano completamente il rischio. In un contesto enterprise questo significa che i controlli di compensazione possono guadagnare tempo, ma non sostituiscono la patch. Se l’istanza è esposta o se all’interno dell’organizzazione esistono account con privilegi di editing workflow, la probabilità di abuso rimane concreta. La vera remediation resta quindi l’aggiornamento a 1.122.0 o successiva, accompagnato da una revisione dei privilegi applicativi e da una rotazione delle credenziali eventualmente memorizzate nella piattaforma. (GitHub)
Il caso Ally mostra quanto WordPress resti esposto ai plugin vulnerabili
Parallelamente alla vicenda n8n, un’altra falla critica riguarda Ally, plugin WordPress di Elementor dedicato all’accessibilità e all’usabilità. Secondo Wordfence, la vulnerabilità interessa le versioni 4.0.3 e precedenti e consente a un attaccante non autenticato di eseguire una SQL injection in grado di sottrarre informazioni dal database. La patch è stata introdotta con la versione 4.1.0, ma la finestra di esposizione resta significativa perché la base installata del plugin è molto ampia e una quota rilevante di siti non ha ancora aggiornato. La pericolosità del caso non dipende soltanto dalla tecnica, ampiamente conosciuta da anni, ma dal fatto che ancora oggi plugin molto diffusi finiscono per esporre query costruite in modo insicuro, lasciando aperta la porta a estrazione di dati, recupero di hash di password o ricognizione interna sul contenuto del database. (Wordfence)
La falla SQL injection in Ally e il ruolo della disclosure
La vulnerabilità nel plugin Ally è stata scoperta dal ricercatore Drew Webber e, secondo i report pubblicati nel settore, nasce dall’uso non corretto di input URL all’interno della funzione get_global_remediations(), dove il parametro utente non viene sanitizzato in modo adeguato prima di essere inserito nella query SQL. Il risultato è una forma di blind SQL injection che può essere sfruttata senza autenticazione in determinate configurazioni, in particolare quando il plugin è collegato a un account Elementor e il modulo di remediation è attivo. È un dettaglio importante, perché limita l’esposizione a una porzione della base installata, ma non ne riduce la gravità operativa: i siti vulnerabili possono comunque diventare target di scansioni automatiche e campagne opportunistiche. La patch del 23 febbraio 2026 nella versione 4.1.0 è quindi un aggiornamento che va trattato come prioritario, soprattutto sui siti pubblici con elevata visibilità.
Perché queste due vicende parlano della stessa crisi di sicurezza
A prima vista n8n e Ally sembrano casi diversi: da un lato una piattaforma di automazione workflow in ambienti spesso enterprise, dall’altro un plugin WordPress installato su siti pubblici. In realtà i due episodi raccontano la stessa fragilità strutturale del software moderno. Entrambi i prodotti gestiscono logica applicativa critica e, in entrambi i casi, una singola vulnerabilità consente di passare da una funzione apparentemente ordinaria a una compromissione molto più ampia. In n8n il rischio è la presa di controllo del server e dei segreti operativi; in WordPress è l’accesso al database e all’infrastruttura informativa del sito. In tutti e due gli scenari, il vero moltiplicatore del danno è la tempestività della patching strategy: quando l’aggiornamento tarda, il tempo lavora a favore di chi attacca. (cisa.gov)
Cosa devono fare adesso amministratori e aziende
Per n8n la priorità assoluta è verificare la versione in uso e portare immediatamente le istanze almeno alla 1.122.0, limitando nel frattempo i permessi di editing workflow e riducendo l’esposizione pubblica delle interfacce. È altrettanto importante valutare una rotazione delle credenziali conservate nella piattaforma, perché in uno scenario di compromissione pregressa non basta chiudere il bug: bisogna trattare come potenzialmente esposti i segreti già memorizzati. Sul fronte WordPress, chi utilizza Ally deve aggiornare senza ritardo alla 4.1.0 e verificare se il sito espone configurazioni che rendono attivo il vettore descritto dai ricercatori. In entrambi i casi, logging, WAF, controllo delle anomalie e scansioni esterne restano fondamentali, ma non sostituiscono la remediation. Il messaggio, anche questa volta, è semplice: le vulnerabilità già sfruttate non si gestiscono con prudenza attendista, ma con patch rapide e revisione dell’esposizione.
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.
