La scoperta di una nuova vulnerabilità in NGINX è stata seguita, nel giro di pochissimi giorni, da tentativi di exploit attivi in rete. La falla, identificata come CVE-2026-42945 e soprannominata “NGINX Rift”, sta attirando l’attenzione della comunità security proprio per la rapidità con cui è stato preso di mira dagli attaccanti.

Secondo i ricercatori di VulnCheck, le prime attività malevole sono state osservate già a ridosso della pubblicazione della CVE, con segnali rilevati persino su sistemi canary progettati proprio per intercettare comportamenti sospetti. Il quadro che emerge è quello di un ecosistema in cui la finestra tra disclosure pubblica e sfruttamento reale si è ridotta a pochi giorni, confermando una tendenza ormai strutturale per la quale gli attori offensivi monitorano costantemente feed di vulnerabilità, patch note e repository pubblici con una velocità spesso superiore a quella dei team di difesa.

La vulnerabilità interessa sia NGINX Open Source, sia NGINX Plus ed è stata classificata come heap buffer overflow con un punteggio CVSS di 9.2, quindi nel range delle criticità elevate. Il bug sarebbe rimasto latente all’interno del modulo rewrite del software per quasi 18 anni, risalendo addirittura al 2008, secondo le analisi pubblicate da Depthfirst. Un dettaglio che sottolinea quanto anche componenti largamente diffusi e considerati maturi possano contenere difetti profondi rimasti inosservati per cicli tecnologici interi.

La vulnerabilità può essere attivata tramite richieste HTTP appositamente costruite. In condizioni normali, il risultato dell’exploit è il crash del processo worker di NGINX, con conseguente riavvio del servizio. In scenari più particolari, però, la situazione può evolvere verso condizioni più critiche, soprattutto su sistemi privi delle protezioni standard del kernel Linux.

F5, che ha acquisito NGINX nel 2019, ha confermato che il problema si manifesta in presenza di specifiche configurazioni del server e che nella maggior parte dei casi si limita a un’interruzione del servizio. Tuttavia, in ambienti in cui tecnologie come ASLR non sono attive, esiste la possibilità teorica di arrivare all’esecuzione di codice arbitrario. Si tratta di uno scenario considerato poco probabile nella pratica moderna, ma sufficiente a mantenere alta l’attenzione degli operatori di sicurezza.

NGINX Rift server

Il sistema DepthFirst ha individuato 4 problemi di corruzione della memoria remota in NGINX (Fonte: DepthFirst)

La rapidità con cui si è passati dalla disclosure all’exploit è stata favorita anche dalla pubblicazione di un proof-of-concept pubblico avvenuta lo stesso giorno del rilascio delle patch. Questo elemento ha abbassato immediatamente la barriera di ingresso per attaccanti meno sofisticati, trasformando una vulnerabilità teoricamente complessa in un obiettivo rapidamente industrializzabile.

Dal punto di vista operativo, però, la situazione è meno uniforme di quanto la severità del CVSS potrebbe suggerire. Kevin Beaumont, ricercatore indipendente di sicurezza, ha evidenziato come le moderne distribuzioni Linux rendano l’esecuzione di codice remoto estremamente difficile in condizioni reali. La presenza generalizzata di ASLR attivo e altre mitigazioni a livello di sistema operativo riduce significativamente la probabilità di exploit completi. In questo senso, il rischio prevalente rimane quello di denial of service attraverso crash ripetuti dei worker NGINX, piuttosto che una compromissione totale del sistema.

Nonostante ciò, la superficie d’attacco resta estremamente ampia. Le analisi di Censys indicano infatti circa 5,7 milioni di server NGINX esposti su Internet che potrebbero essere potenzialmente vulnerabili, a seconda della versione e della configurazione utilizzata. Una base installata considerevole che riflette quanto NGINX sia ormai uno standard de facto per web server e reverse proxy in ambienti enterprise, cloud e infrastrutture ad alta scala.

Il problema, in casi come questo, è in modo particolare la combinazione tra diffusione del software e velocità di sfruttamento. Anche quando il rischio di compromissione completa è limitato, la possibilità di interrompere servizi critici su larga scala rappresenta comunque un vettore di pressione significativo, soprattutto per sistemi esposti senza adeguati layer di protezione o monitoraggio.

Un contesto in cui la dinamica evidenziata da VulnCheck assume un valore più ampio. La finestra tra disclosure e exploitation si sta infatti riducendo in modo costante, trasformando la gestione delle patch in un processo sempre più reattivo e meno pianificabile. Per gli operatori infrastrutturali, la conseguenza diretta è un incremento della complessità nella gestione del rischio, dove la semplice disponibilità di una patch non è più sufficiente a garantire protezione immediata.

(Immagine in apertura: Shutterstock)