Un sysadmin non dorme mai del tutto. PHP è appena stato aggiornato e F5 segnala tre falle critiche in NGINX Open Source e NGINX Plus, ciascuna con CVSS 9.2. Possono far cadere singoli worker (DoS) e, in certe condizioni, portare all'esecuzione di codice. La buona notizia: a differenza di PHP2Shell, non ogni installazione è automaticamente attaccabile. Dipende da direttive precise. La cattiva: non esiste una soluzione tampone ufficiale, solo l'aggiornamento.
Le tre falle in una frase
- CVE-2026-15176: overflow nell'heap quando
aliassi combina conrewritee unsetoreturnche usa$request_filename. Basta anche$request_filenamenel formato dell'access log. - CVE-2026-97205: use-after-free quando l'I/O asincrono su file (
aio) è attivo e si elaborano pagine SSI con include virtuali. - CVE-2026-93479: overflow nell'heap con espressioni regolari in
map, quandorooto un formato di log usa variabili catturate prima dell'output della map.
Tutte e tre riguardano solo il piano dati. Per eseguire codice bisogna inoltre aggirare l'ASLR. Al momento non si conoscono attacchi attivi.
Quali versioni?
NGINX Open Source è corretto in 1.31.7 e 1.30.6. NGINX Plus in 37.1.0.1 e 37.0.5.1; per R33–R36 non c'è correzione nello stesso ramo, serve migrare. Anche versioni più vecchie sono in parte colpite, fino a release molto datate.
Verifica in cinque minuti
nginx -v
nginx -T 2>/dev/null | grep -nE 'request_filename|^\s*aio\s|^\s*ssi\s+on'
nginx -T 2>/dev/null | grep -nE '^\s*map\s'
for c in $(docker ps --format '{{.Names}}'); do docker exec $c nginx -v 2>/dev/null && echo " ^ $c"; doneLa prima riga mostra la versione. La seconda cerca le direttive delle prime due falle nella configurazione completa e risolta (anche nei file inclusi). La terza elenca tutti i blocchi map: guarda bene se usano espressioni regolari con gruppi catturati e se quei gruppi compaiono in root o in un log_format. L'ultima riga trova NGINX dentro i container, che si dimenticano facilmente.
Aggiornare, a seconda di dove arriva NGINX
- Distribuzione:
apt update && apt upgradee cerca i numeri CVE nel changelog del pacchetto. Spesso la correzione arriva con un numero di versione vecchio. - Pannello (Plesk, cPanel): il pannello porta il proprio NGINX. Non sostituirlo a mano: aspetta l'aggiornamento del produttore e tieni attivi gli aggiornamenti automatici. Nel frattempo controlla la configurazione.
- Container: porta l'immagine a
nginx:1.30.6-alpineo successiva. Se non vuoi ricompilare l'app, cambia solo lo strato di runtime: nuova immagine NGINX come base, copia file compilati e template dalla vecchia, ricrea il container.
Poi nginx -t e un reload. Per i container ricreali, il semplice riavvio non basta.
Com'era sul mio server
L'NGINX davanti ai miei siti arriva dal pannello ed era alla 1.30.5. Lì un pacchetto corretto non c'era ancora. Il controllo della configurazione completa ha mostrato: nessun $request_filename, nessun aio, niente SSI, e i blocchi map non usano gruppi catturati. Quindi non attaccabile, e l'aggiornamento arriverà da solo appena il produttore lo rilascia. Un container con il suo NGINX era ancora alla 1.29.8: l'ho portato subito alla 1.30.6, senza ricompilare l'app.
Qualche consiglio
- Nessun motivo di panico, ma nemmeno di rimandare. La configurazione può cambiare con il prossimo deploy. Ciò che oggi non è attaccabile domani potrebbe esserlo.
- Controlla la configurazione risolta (
nginx -T), non solo il tuo file. Molte direttive arrivano dagli include del pannello o dei pacchetti. - Non dimenticare i container: frontend, interfacce di amministrazione e servizi office spesso hanno il loro NGINX.
- Evita i tag mobili:
FROM nginx:alpineè comodo, ma non sai mai quale versione gira. Meglio fissare una versione precisa e alzarla consapevolmente. - Tieni un piccolo inventario: dove gira NGINX, dove PHP, quale immagine dove. Dopo PHP2Shell di due giorni fa mi è già servito due volte.
Fonti: NGINX security advisories e la Cyber Security Agency of Singapore. Per confronto: il mio articolo sulla patch urgente di PHP.