Una fetta enorme del traffico Web mondiale transita ogni giorno attraverso NGINX. Server web, CDN, reverse proxy, piattaforme SaaS, API gateway, cluster Kubernetes: il software creato nel 2004 da Igor Sysoev occupa una posizione assolutamente centrale nell’infrastruttura Internet globale. Ed è proprio per questo che la pubblicazione della vulnerabilità CVE-2026-42945, ribattezzata NGINX Rift, ha immediatamente catalizzato l’attenzione di tutta la comunità di sicurezza informatica. Il problema è un heap buffer overflow presente nel modulo ngxhttprewritemodule, introdotto nel codice di NGINX addirittura nel 2008. Praticamente rimasto invisibile per quasi 18 anni.
La vulnerabilità non si limita a far crashare il worker di NGINX: in configurazioni specifiche può portare all’esecuzione di codice da remoto senza alcuna autenticazione. La gravità tecnica della faccenda è amplificata dal fatto che NGINX Rift interessa componenti delle configurazioni utilizzati da anni in modo estremamente diffuso, come le direttive rewrite, le variabili di cattura PCRE per le espressioni regolari e la gestione dei parametri presenti negli URI.
Secondo F5, risultano vulnerabili le versioni open source dalla 0.6.27 alla 1.30.0, mentre le release corrette sono la 1.30.1 e la nuova 1.31.0. Anche NGINX Plus riceve patch dedicate per le release R32 fino alla R36.
Perché il modulo rewrite di NGINX è così delicato
Chi amministra NGINX conosce bene la potenza del motore rewrite. Le direttive rewrite, set e if permettono manipolazioni avanzate dell’URI, riscrittura di parametri query, redirect interni e logica condizionale piuttosto articolata. A governare il funzionamento c’è un interprete interno sofisticato, costruito negli anni per privilegiare velocità ed efficienza sopra ogni altra cosa.
La vulnerabilità si annida nel motore di scripting interno usato durante l’elaborazione delle regole di rewrite. NGINX adotta un meccanismo a due passaggi: nella prima fase calcola la dimensione del buffer necessario, nella seconda copia materialmente i dati nel buffer heap allocato.
I ricercatori di DepthFirst AI spiegano che con una particolare modalità di gestione delle espressioni regolari, abbinata a una stringa di sostituzione contenente il carattere ?, usato per indicare l’inizio dei parametri in un URL, può verificarsi una situazione anomala. Alcuni caratteri speciali possono occupare fino a tre byte invece di uno: di conseguenza la memoria allocata risulta insufficiente rispetto alla quantità reale di dati copiati. Questo comportamento può causare un heap overflow, cioè una scrittura di dati oltre i limiti della memoria allocata dinamicamente, sfruttabile tramite URI appositamente costruiti per attivare la falla.
Dall’overflow all’esecuzione del codice dannoso
Molti heap overflow finiscono con un crash e poco altro, soprattutto in ambienti Linux recenti. NGINX Rift però mostra caratteristiche che rendono lo sfruttamento della vulnerabilità decisamente più critico del solito.
Il proof of concept pubblicato dai ricercatori utilizza una tecnica che modella progressivamente la disposizione degli oggetti heap attraverso richieste HTTP multiple, fino a posizionare strutture critiche accanto al buffer vulnerabile. La struttura presa di mira è ngxpool_t, il nucleo dell’allocator memory pool di NGINX.
Va detto che la sfruttabilità reale dipende molto dalla specifica configurazione del sistema. Con ASLR attivo, realizzare una condizione RCE (remote code execution) affidabile diventa più complesso. Alcuni vendor, tra cui AlmaLinux, sottolineano infatti che il crash del worker è facilmente riproducibile, mentre l’esecuzione arbitraria di codice da remoto richiede condizioni aggiuntive.
Un punto particolarmente delicato riguarda i container: molte immagini Docker continuano a distribuire release NGINX non aggiornate, spesso integrate in appliance software o stack applicativi che gli amministratori non toccano per mesi. Negli ambienti Kubernetes la situazione può complicarsi ulteriormente, perché ingress controller personalizzati e configurazioni generate automaticamente possono nascondere direttive rewrite vulnerabili senza che il team operativo se ne accorga subito.
Patch, mitigazioni e verifiche operative
La correzione ufficiale arriva nelle versioni NGINX 1.31.0 e 1.30.1. Per NGINX Plus, F5 distribuisce fix nelle release R36 P4, R35 P2 e R32 P6.
Chi gestisce infrastrutture esposte pubblicamente dovrebbe verificare immediatamente la versione in uso tramite il comando nginx con il parametro v. Conviene poi analizzare le configurazioni alla ricerca di direttive rewrite che utilizzano capture anonime come EUR 1, EUR 2 e replacement string con query arguments.
Chi usa distribuzioni enterprise deve inoltre verificare eventuali backport dei vendor: AlmaLinux, per esempio, ha rilasciato rapidamente pacchetti aggiornati adattando le patch upstream anche a versioni NGINX precedenti rispetto alla 1.31.0. Vale la pena controllare anche appliance di terze parti, WAF integrati e ingress controller basati su NGINX: in diversi casi il componente vulnerabile non appare immediatamente visibile perché incluso come dipendenza interna.
Un bug nato nel 2008 che racconta molto sul software infrastrutturale
Le vulnerabilità “longeve” non rappresentano una novità assoluta. Heartbleed, Shellshock e vari bug nel kernel Linux hanno mostrato in passato quanto codice apparentemente consolidato possa restare vulnerabile per anni senza che nessuno se ne accorga.
NGINX Rift però colpisce per almeno due motivi. Il primo: interessa uno dei server Web più diffusi al mondo. Il secondo: il bug nasce da una discrepanza logica molto sottile tra due passaggi interni del motore rewrite. Vulnerabilità di questo tipo sfuggono facilmente sia alla review manuale sia ai normali test funzionali. Servono analisi profonde dei percorsi di memoria e delle condizioni di stato interne, e non è roba banale.
Il team di DepthFirst dichiara di aver individuato automaticamente quattro vulnerabilità di corruzione della memoria in NGINX (oltre a CVE-2026-42945 ci sono CVE-2026-42946, CVE-2026-40701 e CVE-2026-42934) dopo aver caricato una sola volta il codice sorgente all’interno del proprio sistema di analisi basato su intelligenza artificiale. Non si tratta più di fuzzing tradizionale o analisi statica classica: qui entra in gioco un approccio automatizzato capace di seguire flussi di memoria complessi e condizioni multi step difficili da intercettare con strumenti convenzionali.
Se da un lato i sistemi basati su AI producono molto rumore e segnalazioni che alla fine non si rivelano reali problemi di sicurezza, è altrettanto vero che fanno emergere anche falle critiche, spesso rimaste nascoste per anni nonostante le verifiche di occhi esperti.
