Nginx: bug di 15 anni fa nelle regex permette attacchi DoS e RCE. Rilasciate patch urgenti per milioni di server

🛡️ Executive Summary

• CVE-2026-42533 sfrutta un’incoerenza tra misurazione e scrittura delle capture regex nel motore di scripting di Nginx.
• Richieste HTTP costruite possono provocare crash dei worker, perdita di dati heap e, in condizioni favorevoli, esecuzione di codice remoto.
• La correzione è disponibile in Nginx 1.30.4, 1.31.3 e NGINX Plus 37.0.3.1; l’aggiornamento deve essere prioritario.

Nginx ha corretto la vulnerabilità CVE-2026-42533, un heap buffer overflow nel motore di scripting capace di provocare il crash dei worker process e una conseguente condizione di denial of service. In configurazioni specifiche, soprattutto quando ASLR è disabilitato o può essere aggirato, la falla può aprire anche un percorso verso l’esecuzione di codice remoto. Il problema interessa le versioni comprese tra Nginx 0.9.6 e 1.31.2 ed è stato risolto nelle release 1.30.4 stable e 1.31.3 mainline, pubblicate il 15 luglio 2026 insieme alla versione corretta di NGINX Plus.

CVE-2026-42533 altera il calcolo del buffer nel motore di scripting

La vulnerabilità nasce nel componente che costruisce dinamicamente stringhe a partire dalle direttive presenti nella configurazione di Nginx. Il motore lavora attraverso due passaggi distinti: nel primo calcola la quantità di memoria necessaria, mentre nel secondo scrive il risultato nel buffer appena allocato. I due passaggi dovrebbero operare sullo stesso stato delle capture regex, ma una valutazione intermedia della direttiva map può sovrascrivere tali valori. Il buffer viene quindi dimensionato usando la capture originale, mentre la scrittura successiva utilizza una capture più lunga controllata attraverso la richiesta HTTP. La differenza tra la lunghezza prevista e quella effettiva provoca l’overflow nella memoria heap del worker. La dinamica rientra nella più ampia categoria delle vulnerabilità informatiche legate a errori di memoria, configurazioni ed exploit, ma presenta una particolarità: l’esposizione non dipende soltanto dalla versione installata, bensì dalla combinazione concreta delle direttive utilizzate dal server.

L’exploit richiede una configurazione con map e capture numeriche

Non tutte le installazioni Nginx risultano automaticamente vulnerabili. L’attacco richiede una direttiva map basata su espressione regolare, il cui valore venga inserito in una stringa dopo una capture numerica derivata da un precedente match regex. La capture deve comparire prima della variabile generata dalla map, creando la sequenza che permette di alterare lo stato tra il passaggio di misurazione e quello di scrittura. Un aggressore remoto e non autenticato può quindi inviare una richiesta HTTP costruita per produrre una capture iniziale di determinate dimensioni e sostituirla, durante la valutazione della map, con un contenuto più grande. Il worker scrive così dati oltre i limiti del buffer allocato. Questo requisito aumenta la complessità dell’exploit, ma non deve essere interpretato come una protezione sufficiente: reverse proxy, gateway, bilanciatori e piattaforme applicative possono accumulare negli anni configurazioni articolate, incluse regole regex ereditate o generate automaticamente. Le precedenti vulnerabilità Nginx Rift capaci di trasformare vecchie configurazioni in percorsi RCE hanno già mostrato quanto direttive apparentemente ordinarie possano diventare pericolose quando interagiscono con parti profonde del motore.

Crash dei worker, perdita di memoria e possibile esecuzione di codice

L’effetto più immediato di CVE-2026-42533 è il crash del worker process, seguito normalmente dalla sua ricreazione da parte del master process. Richieste ripetute possono tuttavia abbattere continuamente i worker e compromettere la disponibilità del servizio, trasformando la vulnerabilità in un vettore di DoS remoto. L’impatto può diventare più grave quando la manipolazione del buffer permette di controllare strutture presenti nella memoria heap e orientare il flusso di esecuzione. In presenza di ASLR disabilitato, indebolito o aggirabile, l’attaccante può tentare di stabilizzare gli indirizzi necessari a costruire una catena RCE. È stata inoltre descritta una variante nella quale una capture più corta rispetto a quella originaria induce il server a restituire porzioni di memoria non inizializzata, esponendo indirizzi heap utili a superare la randomizzazione su sistemi come Ubuntu 24.04. La falla ha ricevuto un punteggio CVSS v4 di 9.2 e CVSS v3.1 di 8.1: la complessità elevata riduce la probabilità di compromissioni indiscriminate, ma la combinazione tra crash, possibile leak di memoria e potenziale Remote Code Execution con payload controllati dall’attaccante rende necessario trattare l’aggiornamento come prioritario.

Le patch arrivano con Nginx 1.30.4 e 1.31.3

La correzione è inclusa in Nginx 1.30.4, appartenente al ramo stable, e Nginx 1.31.3, destinato al ramo mainline. Anche NGINX Plus 37.0.3.1 integra la patch, mentre i prodotti costruiti sullo stesso codice devono essere aggiornati alle rispettive versioni corrette. Tra questi rientrano NGINX Ingress Controller, Gateway Fabric, App Protect WAF e Instance Manager, spesso collocati davanti ad applicazioni, cluster Kubernetes e servizi aziendali esposti su Internet. La presenza della vulnerabilità in versioni distribuite a partire dalla 0.9.6 amplia notevolmente il numero teorico dei sistemi coinvolti, anche se l’exploitabilità effettiva resta subordinata alla configurazione. Gli amministratori non dovrebbero però limitarsi a controllare il numero di versione del pacchetto principale: container, immagini personalizzate, appliance e distribuzioni downstream possono mantenere copie differenti di Nginx. Le recenti falle Nginx sfruttabili insieme ad altre vulnerabilità Linux e applicative confermano l’importanza di verificare l’intera catena di deployment, comprese immagini Docker, chart Helm e componenti integrati nei prodotti di terze parti.

Aggiornamento immediato e verifica delle configurazioni regex

L’installazione delle release corrette rappresenta l’unica mitigazione completa. Chi non può aggiornare immediatamente può ridurre il rischio sostituendo le capture numeriche utilizzate nelle direttive map con named captures, evitando il principale percorso che causa la sovrascrittura dello stato condiviso. Questa modifica deve essere considerata temporanea, perché non offre le stesse garanzie della patch e può non coprire tutte le varianti della configurazione. Gli amministratori devono cercare combinazioni di regex, map e stringhe dinamiche, controllare crash anomali dei worker, riavvii ripetuti e risposte HTTP contenenti dati inattesi. È opportuno verificare anche core dump, error log e variazioni improvvise nel numero dei processi Nginx. Al momento indicato non risultano exploit pubblici né l’inserimento della falla nel catalogo CISA KEV dedicato alle vulnerabilità sfruttate attivamente, ma la pubblicazione annunciata di un proof-of-concept dopo il periodo di embargo può ridurre rapidamente il margine operativo. La priorità resta quindi aggiornare prima i server esposti, i reverse proxy Internet-facing e i controller che gestiscono traffico verso applicazioni critiche.