NGINX, falla critica rimasta nascosta 15 anni: rischio crash e codice remoto

Una richiesta HTTP costruita ad arte può mandare in crash un worker NGINX e, in determinate condizioni, aprire la strada all’esecuzione di codice remoto. La vulnerabilità, identificata come CVE-2026-42533, interessa un intervallo di versioni insolitamente ampio: da NGINX 0.9.6, pubblicato nel 2011, fino alle release 1.30.3 stable e 1.31.2 mainline. F5 ha già distribuito le correzioni a metà luglio con NGINX 1.30.4, NGINX 1.31.3 e NGINX Plus 37.0.3.1.

Il problema non rende vulnerabile ogni installazione in modo automatico: serve una particolare combinazione di direttive, espressioni regolari e variabili; resta però una falla rilevante perché colpisce il percorso del server web che elabora le richieste, non richiede autenticazione e può ricevere dati controllati direttamente dal client. F5 le assegna un punteggio di 9,2 secondo CVSS 4.0 e di 8,1 secondo CVSS 3.1, pur classificando come alta la complessità dell’attacco.

La storia tecnica della falla parte dalla direttiva map, che NGINX usa per calcolare il valore di una variabile in base a un’altra variabile. Dal marzo 2011 map supporta anche le espressioni regolari; proprio tale capacità, combinata con il motore interno che compone stringhe e parametri, ha introdotto una condizione rimasta nascosta per circa 15 anni.

NGINX: il difetto nel calcolo a due passaggi

NGINX costruisce molte espressioni dinamiche attraverso due fasi. Durante il primo passaggio, chiamato informalmente LEN, il motore calcola quanti byte serviranno e alloca un buffer della dimensione prevista. Nel secondo, VALUE, copia nel buffer le stringhe, le variabili e i gruppi catturati dalle espressioni regolari o regex.

Il principio funziona finché i dati letti nei due passaggi restano identici. Ma alcuni risultati delle espressioni regolari vivono in uno stato condiviso associato alla richiesta: una nuova regex può quindi sovrascrivere le catture ottenute in precedenza. Così, la fase LEN misura un valore, mentre VALUE ne copia un altro.

Il difetto nasce dal modo in cui NGINX prepara le stringhe dinamiche. Prima calcola quanti byte serviranno e riserva uno spazio in memoria; poi compone il valore finale inserendo, uno dopo l’altro, i dati ricavati dalla richiesta e dalle regole di configurazione.

La criticità emerge quando uno di quei dati cambia tra il calcolo iniziale e la copia vera e propria. Può accadere con le catture delle espressioni regolari, indicate da variabili come $1 o $2. Una prima regex, per esempio quella usata in una location, può salvare una porzione breve dell’URL. Poco dopo, una direttiva map basata su un’altra regex può aggiornare la stessa cattura con un contenuto diverso, magari ricavato da un header o da un parametro controllato dal client.

A quel punto NGINX usa una misura ormai superata. Ha riservato memoria per una stringa corta, ma prova a copiarne una molto più lunga. Se il buffer contiene spazio per tre caratteri e il nuovo valore ne contiene 200, i byte in eccesso finiscono oltre il limite previsto e possono corrompere le aree di memoria vicine. È questo il meccanismo dell’heap buffer overflow: nella forma più semplice provoca il crash del worker; in condizioni particolari può anche diventare un passaggio utile per costruire un attacco più grave.

Perché un crash può trasformarsi nell’esecuzione di codice arbitrario

L’effetto più immediato consiste nella corruzione della memoria del worker. Il processo può terminare con un segmentation fault e il master NGINX, come previsto dalla sua architettura, può avviare un nuovo worker. Una singola richiesta produce quindi un’interruzione limitata; una sequenza continua di richieste può trasformare il comportamento in un denial of service persistente, con riavvii ripetuti e capacità ridotta di servire traffico.

F5 indica anche la possibilità di eseguire codice qualora ASLR (Address Space Layout Randomization) risulti disabilitato o aggirabile. ASLR rende meno prevedibili gli indirizzi di memoria di eseguibili, librerie e heap; un overflow controllato, da solo, non garantisce quindi una catena di exploit affidabile su un sistema moderno.

Il ricercatore Stan Shaw sostiene però che la stessa vulnerabilità possa fornire il dato necessario a superare ASLR. Quando la cattura sovrascritta risulta più corta di quella misurata, NGINX alloca un buffer troppo grande e ne inizializza soltanto una parte.

Secondo i test pubblicati dal ricercatore su Ubuntu 24.04 con glibc 2.39, il comportamento emerso può descrivere puntatori verso libc e heap. Una richiesta GET non autenticata consentirebbe quindi di ricavare gli indirizzi necessari per rendere più stabile una successiva scrittura fuori limite. Va detto però che i dettagli completi dell’exploit e il proof of concept per l’esecuzione di codice non risultavano pubblici al momento della divulgazione; la tesi resta più ampia rispetto a quanto dichiarato ufficialmente da F5 e richiede una verifica indipendente completa.

Quali configurazioni devono preoccupare

La sola presenza di una versione vulnerabile non basta. La condizione principale combina una sorgente di catture regex, una map basata su regex e una direttiva che compone valori dinamici in due passaggi. L’ordine conta: la cattura deve comparire prima della variabile map.

La correzione introduce un controllo sulla lunghezza durante il passaggio di scrittura e calcola la dimensione finale in base ai byte realmente prodotti. In questo modo NGINX impedisce alla fase VALUE di superare il buffer allocato e, allo stesso tempo, evita di restituire una porzione non inizializzata calcolata soltanto durante LEN.

L’intervento più solido consiste nell’aggiornare subito e validare la configurazione con nginx -t prima del reload. Il reload graduale preserva le connessioni gestite dai worker precedenti, ma bisogna verificare che nessun processo vulnerabile resti attivo più a lungo del previsto a causa di sessioni persistenti. Nei cluster Kubernetes, la sostituzione dei pod deve raggiungere tutte le repliche e tutti i nodi; un’immagine aggiornata nel registro non corregge i pod già in esecuzione.

Al momento della prima pubblicazione non risultavano exploit pubblici né un inserimento della CVE nel catalogo Known Exploited Vulnerabilities di CISA. È una fotografia temporanea, non una garanzia. Il codice vulnerabile è ormai noto, la superficie esposta può essere raggiunta senza credenziali e i dettagli tecnici disponibili descrivono con precisione il meccanismo di corruzione: rimandare la patch in attesa di un’attività ostile confermata sarebbe una scelta difficile da giustificare.