Hacker dirottano traffico web sfruttando server NGINX compromessi e le vulnerabilità critiche in n8n sono un problema

Gli hacker stanno dirottando traffico web su larga scala sfruttando server NGINX compromessi, senza ricorrere a vulnerabilità del software ma abusando di configurazioni legittime modificate in modo malevolo. Parallelamente, una vulnerabilità critica in n8n consente a utenti autenticati di ottenere esecuzione di codice remoto, aprendo la strada a compromissioni complete di workflow automation, credenziali e infrastrutture cloud. Le due campagne, sebbene tecnicamente distinte, mostrano una convergenza preoccupante: ambienti Linux, software open-source diffuso e rilevamento estremamente complesso.

Come funziona la campagna di hijacking su NGINX

La campagna analizzata da Datadog Security Labs non sfrutta bug di NGINX, ma iniezioni dirette nei file di configurazione. Gli attori malevoli ottengono un accesso iniziale ai server, spesso tramite pannelli di hosting compromessi come Baota, e modificano i virtual host inserendo blocchi location apparentemente legittimi. Questi blocchi utilizzano direttive standard come proxy_pass, rewrite e proxy_set_header per intercettare solo alcune richieste, lasciando il resto del traffico intatto. Il risultato è un man-in-the-middle silenzioso, dove l’utente finale non percepisce alcuna anomalia e il servizio continua a funzionare regolarmente.

La selettività è uno degli elementi più insidiosi. Gli script prendono di mira percorsi specifici come /pg/, /slot/, /casino/, /game/ o /live/, spesso associati a contenuti commerciali o ad alto valore. In altri casi intercettano sezioni informative come /help/, /news/ o /support/. Tutto il resto del sito rimane invariato.

Toolkit multistadio e persistenza invisibile

L’attacco è orchestrato tramite un toolkit multistadio basato su script shell, progettato per adattarsi a configurazioni diverse. Il primo stadio scarica i moduli successivi usando curl o wget, ma include un fallback che invia richieste HTTP raw via /dev/tcp, aggirando ambienti dove gli strumenti standard sono assenti o monitorati. Gli stadi successivi analizzano directory comuni come /etc/nginx/sites-enabled o i percorsi specifici del pannello Baota, utilizzando utility come awk, csplit e hash MD5 per evitare di corrompere configurazioni valide e per non reiniettare blocchi già presenti. Prima di applicare le modifiche, ogni configurazione viene validata con nginx -t, riducendo il rischio di downtime e rendendo l’attacco quasi indistinguibile da un normale aggiornamento di configurazione. Le mappe dei domini compromessi vengono salvate in file temporanei e poi esfiltrate verso un server di comando e controllo, identificato come 158.94.210.227. Questo consente agli attaccanti di misurare l’efficacia della campagna e di scalare rapidamente su nuovi target.

Chi viene colpito e perché è difficile accorgersene

I target principali includono domini asiatici con TLD come .in, .id, .bd, .th, ma anche siti governativi (.gov) ed educativi (.edu). In questi casi, l’impatto è particolarmente grave perché il traffico intercettato può includere dati sensibili, sessioni autenticare o informazioni istituzionali. La difficoltà di rilevamento nasce dal fatto che non c’è exploit di rete né comportamento anomalo evidente. I log di accesso mostrano richieste apparentemente legittime, gli header originali vengono preservati e il traffico raggiunge comunque la destinazione finale, passando però attraverso infrastrutture controllate dagli attaccanti. Senza file integrity monitoring o controlli manuali sulle configurazioni NGINX, l’iniezione può rimanere attiva per mesi.

Le vulnerabilità critiche in n8n: un secondo fronte aperto

In parallelo, la piattaforma di automazione n8n è stata colpita da una vulnerabilità critica di sandboxing, tracciata come CVE-2026-25049. Il problema consente a utenti autenticati di creare workflow malevoli capaci di ottenere RCE completo sul server.

La falla nasce da un sandbox basato su AST incompleto, che presume che alcune variabili siano stringhe, ma non ne forza il tipo a runtime. Questa type confusion permette di aggirare i controlli e accedere a costrutti pericolosi come il Function constructor, ottenendo esecuzione di codice arbitrario. Ricercatori di Endor Labs e Pillar Security hanno dimostrato exploit funzionanti, mostrando come sia possibile passare da un semplice workflow a accesso completo al filesystem, furto di API key, token OAuth e pivot verso servizi cloud collegati.

Impatti concreti su ambienti enterprise e cloud

Nel caso di NGINX, l’impatto principale è la perdita di integrità del traffico. Gli attaccanti possono osservare, modificare o monetizzare le richieste intercettate, inserendo pubblicità malevole, phishing o redirect secondari. Nei contesti governativi ed educativi, questo mina direttamente la fiducia nei servizi digitali. Nel caso di n8n, l’impatto è ancora più diretto. Un attaccante può prendere il controllo dei workflow, intercettare dati in transito, modificare automazioni critiche o utilizzare l’istanza come punto di partenza per movimenti laterali. In ambienti multi-tenant, il rischio di esposizione cross-tenant diventa concreto.

Patch, mitigazioni e misure urgenti

Per n8n, la mitigazione è chiara e immediata. È necessario aggiornare senza indugio alle versioni 1.123.17 o 2.5.2, che correggono il problema di sandboxing. Dopo l’aggiornamento, è fondamentale ruotare la chiave N8N_ENCRYPTION_KEY e tutte le credenziali salvate, oltre a rivedere manualmente i workflow esistenti alla ricerca di espressioni sospette. Per NGINX, non esiste una “patch” unica. La difesa passa da monitoraggio continuo delle configurazioni, restrizione dei permessi sui file .conf, isolamento dei pannelli di gestione e blocco a livello di rete dei domini e IP noti associati alla campagna. L’uso di file integrity monitoring su directory come /etc/nginx e la revisione periodica dei blocchi location diventano pratiche essenziali.

Una lezione chiara per l’open source nel 2026

Questi due casi mostrano come, nel 2026, le minacce più efficaci non siano necessariamente zero-day sofisticati, ma abusi intelligenti di funzionalità legittime e assunzioni errate nel design della sicurezza. NGINX e n8n non sono intrinsecamente insicuri, ma la loro diffusione li rende bersagli ad alto rendimento. Per amministratori e team DevOps, il messaggio è netto: monitorare configurazioni e workflow è importante quanto patchare il software. In un ecosistema open-source sempre più centrale per governi e imprese, la sicurezza non può più essere reattiva, ma deve diventare continua e strutturale.

FAQ