n8n e vBulletin correggono due falle RCE nei server self-hosted

🛡️ Executive Summary

• Una sandbox escape permette agli editor autenticati di n8n di eseguire comandi con i privilegi del processo della piattaforma.
• Un exploit pubblico per vBulletin raggiunge la funzione PHP eval senza autenticazione sui forum self-hosted non aggiornati.
• n8n deve essere aggiornato alle versioni 2.31.5 o 2.32.1, mentre vBulletin richiede le patch di giugno o la versione 6.2.2.

n8n e vBulletin hanno corretto due vulnerabilità distinte capaci di portare all’esecuzione di codice sui server self-hosted. La prima consente a un utente autenticato con permessi di modifica dei workflow di uscire dalla sandbox delle espressioni JavaScript e avviare comandi con i privilegi del processo n8n. La seconda interessa il motore dei template di vBulletin e può essere sfruttata senza account, privilegi amministrativi o interazione di una vittima. Il rischio per i forum non aggiornati è aumentato dopo la pubblicazione di un proof of concept, mentre per n8n non risultano attacchi confermati al momento della divulgazione.

Una arrow function permette di uscire dalla sandbox di n8n

La vulnerabilità di n8n, identificata dall’advisory GHSA-gv7g-jm28-cr3m e valutata 8,7 su 10 secondo CVSS 4.0, interessa le versioni precedenti alla 2.31.5 e quelle comprese tra la 2.32.0 e la 2.32.1. Lo sfruttamento richiede un account autorizzato a creare o modificare workflow, ma non necessita dell’interazione di un secondo utente. Il problema si trova nel sistema che riscrive le espressioni JavaScript inserite nei flussi di automazione, normalmente utilizzate per accedere a dati come campi JSON, parametri e risultati prodotti dai nodi precedenti. n8n costruisce un abstract syntax tree e intercetta gli identificatori liberi per impedire che raggiungano direttamente il runtime Node.js sottostante.

Una gestione incompleta delle arrow function con corpo conciso permetteva però a una costruzione appositamente preparata di risolvere l’identificatore process nel contesto reale di Node.js invece che in quello controllato dalla sandbox. Da questa esposizione l’attaccante poteva raggiungere le funzioni necessarie per eseguire comandi sul sistema operativo con gli stessi privilegi assegnati al processo n8n. La falla è stata individuata mentre i ricercatori verificavano l’efficacia di una precedente correzione per CVE-2026-27577, mostrando come una patch mirata possa lasciare percorsi alternativi quando non vengono testate tutte le forme sintattiche equivalenti.

Le credenziali dei workflow aumentano l’impatto della falla

L’esecuzione di comandi non garantisce automaticamente privilegi amministrativi sul server, perché il payload opera inizialmente nel contesto dell’utente utilizzato per avviare n8n. L’impatto può comunque diventare critico nelle installazioni che affidano alla piattaforma credenziali per database, servizi cloud, applicazioni SaaS e sistemi interni. Un aggressore potrebbe cercare la variabile N8N_ENCRYPTION_KEY, utilizzata per proteggere i segreti conservati dalla piattaforma, e tentare di decifrare le credenziali associate ai workflow. Potrebbe inoltre interrogare endpoint raggiungibili soltanto dalla rete interna, accedere ai volumi montati nei container, modificare automazioni esistenti o creare nuovi flussi destinati a sottrarre dati nel tempo. La vulnerabilità conferma un rischio già emerso con Windmill e le piattaforme di automazione esposte a esecuzione di codice e abuso degli agenti: un workflow builder non è soltanto un’interfaccia applicativa, ma un punto di concentrazione per token, API, database e processi aziendali. La compromissione di un account con facoltà di modifica deve quindi essere trattata come un possibile accesso all’host e non come un semplice abuso delle funzioni disponibili nell’interfaccia.

n8n corregge la falla ma i workaround restano incompleti

Il problema è stato risolto nelle versioni 2.31.5 e 2.32.1, pubblicate il 22 luglio 2026. Gli amministratori devono aggiornare a una di queste release o a una versione successiva compatibile con il proprio ramo. L’advisory non indica una build corretta della serie 1.x e non chiarisce se il servizio n8n Cloud abbia mai esposto la stessa condizione, rendendo necessario verificare direttamente le comunicazioni del fornitore per gli ambienti gestiti. In assenza di un aggiornamento immediato, n8n consiglia di limitare l’accesso all’istanza e la possibilità di creare o modificare workflow esclusivamente a utenti completamente fidati, precisando però che queste misure non eliminano la vulnerabilità. I team devono controllare i flussi creati o modificati nelle settimane precedenti, cercando arrow function inattese, JavaScript offuscato e nodi inseriti senza una giustificazione operativa. Sul server è opportuno individuare shell, PowerShell, curl o wget generati come processi figli di n8n o Node.js, insieme a connessioni in uscita verso destinazioni sconosciute. Quando emergono attività sospette non basta applicare la patch: occorre ruotare token, password e chiavi utilizzati dai workflow, perché l’attaccante potrebbe averli già acquisiti.

vBulletin espone una RCE senza autenticazione

La seconda falla, identificata come CVE-2026-61511, interessa il motore dei template di vBulletin e consente a un utente non autenticato di raggiungere la funzione PHP eval(), ottenendo l’esecuzione di codice sul server che ospita il forum. Le versioni indicate come vulnerabili comprendono vBulletin 6.2.1 e precedenti e 6.1.6 e precedenti, anche se la documentazione pubblica non definisce con precisione il limite inferiore dell’intervallo. L’attacco non richiede un account, accesso al pannello amministrativo o interazione da parte di un moderatore. I dettagli tecnici pubblicati mostrano che una richiesta costruita appositamente può manipolare il percorso con cui il sistema elabora le operazioni matematiche nei template runtime e trasformare un comportamento previsto dall’applicazione in un canale per l’esecuzione arbitraria. Il rischio riguarda le installazioni self-hosted, mentre i servizi vBulletin Cloud risultano già corretti dal fornitore. Diversamente dalla vulnerabilità di n8n, limitata agli utenti con permessi sui workflow, la falla di vBulletin espone direttamente l’interfaccia raggiungibile da Internet e può quindi prestarsi a scansioni automatizzate contro grandi quantità di forum.

L’exploit pubblico riduce il tempo per aggiornare i forum

vBulletin ha distribuito alla fine di giugno patch dedicate alle versioni 6.2.1, 6.2.0 e 6.1.6, seguite il 1° luglio dalla versione corretta 6.2.2. I dettagli dell’exploit sono diventati pubblici il 27 luglio, quasi quattro settimane dopo la disponibilità iniziale delle correzioni. Il proof of concept pubblicato contiene un errore di un solo carattere che ne impedisce l’esecuzione senza modifiche, ma la svista è banale da correggere e non limita la comprensione della vulnerabilità. Non risultano al momento attacchi confermati e CVE-2026-61511 non compare nel catalogo Known Exploited Vulnerabilities di CISA, ma la disponibilità di una catena pubblica modifica immediatamente la valutazione del rischio. Gli operatori possono adattare il codice, automatizzare la ricerca delle versioni esposte e tentare di installare webshell, creare utenti amministrativi o modificare i template per mantenere l’accesso. La situazione richiama gli attacchi contro WordPress e Joomla basati su falle pubbliche e server rimasti senza patch, nei quali il passaggio dalla divulgazione alla scansione di massa può essere molto più rapido dei normali cicli di manutenzione.

Le due RCE richiedono risposte operative differenti

La cornice comune è l’esecuzione di codice in piattaforme self-hosted, ma condizioni e gravità operative non devono essere confuse. In n8n l’attaccante deve già possedere un account con facoltà di modifica dei workflow, mentre vBulletin espone un percorso pre-auth direttamente raggiungibile dalla rete. n8n assegna ufficialmente alla propria falla una severità alta con punteggio 8,7; per CVE-2026-61511 non risultava ancora disponibile un punteggio ufficiale consolidato al momento della pubblicazione dei dettagli. Nessuna delle due vulnerabilità è stata confermata come sfruttata attivamente, ma soltanto quella di vBulletin dispone ora di un exploit pubblico. Gli amministratori di n8n devono aggiornare, revisionare i workflow e proteggere le credenziali centralizzate, mentre i gestori di vBulletin devono verificare immediatamente la release installata, applicare la patch del proprio ramo o passare alla 6.2.2 e cercare modifiche recenti a file PHP, template, account amministrativi e processi del web server. La documentazione ufficiale della sandbox escape di n8n chiarisce che le restrizioni sugli utenti costituiscono soltanto mitigazioni temporanee, mentre l’analisi tecnica della RCE pre-auth di vBulletin mostra il percorso che conduce fino a eval(). Le due falle confermano che una piattaforma può diventare critica non soltanto per il servizio che espone, ma per le credenziali, i dati e i sistemi raggiungibili dal processo compromesso.