Il 15 luglio è arrivata una correzione per codice del 2011

Il 15 luglio 2026 il progetto nginx ha rilasciato le versioni 1.30.4 e 1.31.3, e quel rilascio ha chiuso un overflow di heap raggiungibile in ogni versione fino alla 0.9.6. Quella versione risale al 2011. La vulnerabilità è registrata come CVE-2026-42533 e vale 9,2 sulla scala CVSS versione 4.0. F5 ha pubblicato l'avviso K000162097 per i clienti NGINX Plus, corretto in 37.0.3.1.

L'elenco di chi ha segnalato è insolito. Più di una dozzina di ricercatori hanno riportato lo stesso problema in modo indipendente, fra loro Mufeed VH di Winfunc Research, e il manutentore storico Maxim Dounin ha curato la correzione. Quando una falla viene trovata da così tante persone insieme, è ragionevole supporre che non fosse difficile da trovare e che altri l'abbiano trovata senza presentare alcuna segnalazione.

Che cosa deve esserci nella configurazione perché conti

L'errore risiede nel motore di script, che valuta le espressioni di stringa costruite da nginx al momento della richiesta. Quella valutazione avviene in due passaggi. Il primo misura quanto deve essere grande un buffer, usando lo stato delle catture in quell'istante. Il secondo scrive in quel buffer con dati di cattura che la richiesta può influenzare. Dove i due passaggi divergono, la scrittura è più grande dello spazio riservato.

L'innesco è più stretto di quanto suggerisca l'intervallo di versioni. Serve una direttiva map basata su espressioni regolari la cui variabile di uscita sia richiamata in un'espressione di stringa dopo una cattura da una corrispondenza precedente, le catture numerate scritte come dollaro-uno e dollaro-due. Se la vostra configurazione non contiene una mappa regex di quella forma, il numero di versione da solo non vi mette nell'insieme dei colpiti. È il dato più utile di tutta la divulgazione.

Senza autenticazione, ma non ancora armato

Dove lo schema è presente, la richiesta che lo attiva non ha bisogno di credenziali. Basta una richiesta HTTP costruita ad arte da qualunque punto di internet. L'esito affidabile è il crash e il riavvio di un processo worker, cioè un blocco del servizio davanti alla porta d'ingresso di ciò che il server pubblica. L'esecuzione di codice da remoto è il caso più difficile, possibile dove la randomizzazione dello spazio di indirizzamento è disattivata o aggirabile, e il ricercatore Stan Shaw sostiene che la falla fornisca da sé la strada attorno a quella protezione.

Al 20 luglio non esiste codice di attacco pubblico e la CVE non compare nel catalogo statunitense delle vulnerabilità sfruttate note. Questo è lo stato attuale, non una previsione. Shaw ha annunciato che pubblicherà una prova di concetto 21 giorni dopo l'uscita della patch, il che la colloca nella prima settimana di agosto. Una vulnerabilità critica non sfruttata ma con una data pubblicata è un problema di pianificazione diverso da una senza data.

Tre overflow in un sottosistema in due mesi

CVE-2026-42533 non è un ritrovamento isolato. È il terzo overflow di heap divulgato nel codice di valutazione delle espressioni di nginx in circa due mesi, dopo CVE-2026-42945 di maggio e CVE-2026-9256 poco dopo. Tre ritrovamenti in un sottosistema in un trimestre sono uno schema e non una coincidenza, e lo schema dice che il disegno a due passaggi è sotto esame da parte di persone che ormai sanno dove guardare.

La conseguenza per la pianificazione è netta. Chi tratta questo come un semplice cambio di versione e passa oltre ha una probabilità sensibilmente diversa da zero di ritrovarsi qui entro il trimestre. Nella lista di sorveglianza va il sottosistema, non il numero di CVE, e ciò che si può ridurre in modo permanente sono le forme di configurazione che lo raggiungono.

Il controllo da fare prima di chiamare il fornitore

Quasi tutte le divulgazioni critiche sui server web lasciano un imprenditore dipendente da altri. Questa no, perché l'innesco è leggibile in un file che potete aprire. Chiedete la vostra versione di nginx, poi chiedete se qualche blocco map nella configurazione usa un'espressione regolare e alimenta una variabile che più avanti viene combinata in una stringa insieme a catture numerate. Due domande, una risposta, e sapete se l'inizio di agosto è una scadenza o una nota.

Per le imprese che rientrano nella Direttiva sulla sicurezza delle reti e dei sistemi informativi nell'Unione Europea, e per chi segue le linee guida equivalenti del Regno Unito, la documentazione conta quanto la patch. Annotate su quale versione eravate, la data in cui avete controllato la configurazione e la mitigazione applicata. Un'autorità che chiederà di una vulnerabilità critica pubblicata a luglio vorrà la data in cui l'avete valutata, non solo la data dell'aggiornamento successivo.

Da leggere ora: Quattro agenti di codice usciti senza forzare  |  ServiceNow ha corretto prima il proprio cloud, voi 103 giorni più tardi