NGINX corregge cinque falle: la configurazione decide il rischio reale

Il 14 ottobre 2026 NGINX ha pubblicato le release 1.30.6 e 1.31.7 per correggere cinque vulnerabilità. La prima riguarda il ramo stabile, la seconda il ramo mainline. Per capire se un’installazione precedente è esposta, il numero di versione va incrociato con le funzioni e le direttive effettivamente attive.

Il 19 ottobre NHS England ha richiamato l’attenzione su tre delle cinque falle: richieste inviate da remoto possono provocare il riavvio di un processo worker e, in determinate condizioni, consentire l’esecuzione di codice. Per ciascuna delle tre indica un punteggio CVSS v4 di 9,2. Le altre due vulnerabilità riguardano invece il corpo delle richieste HTTP/3 inoltrate a un backend e i ticket usati per riprendere una sessione TLS.

Le cinque CVE, dalla configurazione all’effetto

Gli avvisi di sicurezza NGINX classificano tutte e cinque le falle come di gravità media, distinguono gli intervalli di versioni vulnerabili e indicano 1.30.6 e 1.31.7 come release corrette. Gli intervalli individuano il software da esaminare: ogni CVE richiede poi una combinazione specifica di funzioni o direttive per diventare raggiungibile.

• CVE-2026-15176 — alias e rewrite. La condizione descritta è una location che combina alias e rewrite con la lettura di $request_filename tramite set, return o il formato del registro degli accessi. Una richiesta preparata per quel percorso può causare un buffer overflow nel worker, con riavvio del processo e possibile esecuzione di codice in ulteriori condizioni. L’intervallo vulnerabile indicato parte da 0.1.29 e arriva a 1.31.6; nei rami stabile e mainline le correzioni sono rispettivamente 1.30.6 e 1.31.7. La sola presenza di alias, senza gli altri elementi della combinazione, non descrive il caso esposto.
• CVE-2026-93479 — espressioni con variabili. Una configurazione coinvolta usa map con una regex e fa leggere a root o al formato del registro le variabili di cattura prima del risultato della mappa. L’avviso contempla anche alcune espressioni stringa con variabili non memorizzabili nella cache. Il difetto è un buffer overflow che può riavviare il worker e, in condizioni ulteriori, consentire l’esecuzione di codice. Gli intervalli interessati sono 1.30.0–1.30.5 e 1.31.2–1.31.6; le versioni corrette sono 1.30.6 e 1.31.7.
• CVE-2026-95101 — inoltro HTTP/3. Il percorso esposto combina richieste HTTP/3 e inoltro a un backend con proxy_request_buffering attivo. Byte aggiuntivi possono entrare nel corpo della richiesta inoltrata oppure superare il limite imposto da client_max_body_size. Qui l’effetto descritto è un’alterazione della richiesta, non il buffer overflow delle prime due CVE. L’intervallo vulnerabile parte da 1.25.0 e termina a 1.31.6; correggono 1.30.6 e 1.31.7.
• CVE-2026-97629 — ticket di sessione TLS. La condizione riguarda una cache di sessione condivisa configurata senza una chiave esplicita tramite ssl_session_ticket_key: NGINX ruota automaticamente le chiavi dei ticket. In questo caso un attaccante potrebbe falsificare una sessione e potenzialmente aggirare la verifica del certificato client; l’esito della falsificazione è descritto come non deterministico e fuori dal suo controllo. L’intervallo vulnerabile parte da 1.23.2 e arriva a 1.31.6. Le release corrette sono 1.30.6 e 1.31.7.
• CVE-2026-97205 — AIO e SSI. In alcune configurazioni con I/O asincrono abilitato, l’elaborazione di una pagina SSI contenente include virtual può innescare un use-after-free nel worker. Le conseguenze possibili comprendono arresto del processo, corruzione della memoria e, con ulteriori condizioni, esecuzione di codice. L’intervallo vulnerabile indicato parte da 0.8.11 e arriva a 1.31.6; le correzioni per i rami stabile e mainline sono 1.30.6 e 1.31.7.

Che cosa cambia tra un crash e l’esecuzione di codice

Le tre CVE che coinvolgono la memoria non hanno tutte lo stesso comportamento interno. Le prime due possono scrivere oltre il buffer previsto; la falla legata ad AIO può invece usare memoria già liberata. In entrambi i casi il riavvio di un worker è una conseguenza possibile e può causare una negazione del servizio. L’esecuzione di codice rappresenta un esito ulteriore, non l’effetto automatico di ogni richiesta che raggiunge la configurazione vulnerabile.

Per quell’esito ulteriore conta anche ASLR, la protezione che rende meno prevedibile la disposizione della memoria: gli avvisi indicano la disattivazione o l’aggiramento di ASLR tra le condizioni rilevanti. La valutazione del rischio deve quindi tenere insieme la gravità del difetto, il percorso con cui una richiesta può raggiungerlo e le protezioni del sistema. Il punteggio assegnato alle falle di memoria misura la severità potenziale; da solo non dice se una particolare installazione usa la combinazione vulnerabile.

HTTP/3 e TLS richiedono priorità diverse

Per la falla HTTP/3, il confine importante è quello fra la richiesta ricevuta da NGINX e il corpo che viene passato all’applicazione a valle. Se il servizio accetta HTTP/3 e inoltra la richiesta con il buffering interessato, byte che non dovrebbero far parte del corpo possono arrivare al backend. Questo distingue il problema da un semplice arresto del server: l’applicazione può ricevere una richiesta diversa da quella su cui l’amministratore si aspetta che operi il limite di dimensione.

La falla TLS interessa invece la ripresa delle sessioni tramite ticket, quando la cache condivisa lascia a NGINX la rotazione automatica delle chiavi. Il possibile aggiramento della verifica del certificato client pesa soprattutto nei servizi che usano quel certificato per decidere l’accesso. La condizione di configurazione resta rilevante anche se il servizio usa TLS: cifrare le connessioni, da solo, non equivale a usare la specifica combinazione di cache e ticket descritta dalla CVE.

Quale release chiude le falle

Per NGINX Open Source, le release corrette della serie sono 1.30.6 nel ramo stabile e 1.31.7 nel ramo mainline. La priorità di aggiornamento cresce quando una versione vulnerabile coincide con una delle configurazioni della matrice, in particolare se una richiesta esterna può raggiungere il percorso coinvolto. Anche un’installazione che oggi non usa quelle direttive può cambiare esposizione quando cambia la configurazione: versione e impostazioni vanno quindi considerate insieme.

NGINX Plus e gli altri prodotti F5 citati negli avvisi seguono indicazioni di aggiornamento proprie: i numeri delle release Open Source non identificano automaticamente una build corretta per quei prodotti. Per i pacchetti forniti da una distribuzione conta inoltre la correzione effettivamente inclusa dal manutentore, che può non coincidere con il numero della release pubblicata direttamente da NGINX. È la combinazione fra prodotto, build e configurazione attiva a stabilire quale delle cinque vulnerabilità resta raggiungibile nel servizio.

Leggi anche:

• L’IA trova falle a 3,61 dollari, ma Microsoft avverte: serve ancora revisione umana
• Agenti IA con approvazione umana: troppe conferme diventano un rischio
• Computis raccoglie 2 milioni: il bilancio in tempo reale sfida i ritardi