nginx, cinque falle corrette a ottobre: verificare e aggiornare il server web
Il 14 ottobre nginx 1.30.6 ha corretto cinque falle (CVE-2026-15176 e altre), distribuite da Ubuntu il 26 ottobre e da Debian 13. Nessuno sfruttamento noto, ma l’aggiornamento va pianificato. Perché il numero di versione inganna, cosa verificare sul server e quando segnalare all’IFPDT.
Il 14 ottobre 2026 il progetto nginx ha pubblicato le versioni 1.30.6 (stabile) e 1.31.7 (mainline), che correggono cinque vulnerabilità di sicurezza. Il 26 ottobre Ubuntu ha distribuito i pacchetti corretti con l’avviso USN-8955-1; Debian ha fatto lo stesso per Debian 13 con DSA-6575-1.
nginx è il server web, o il proxy, che risponde alle richieste di moltissimi siti, gestionali e applicazioni ospitati su server Linux. Per una PMI ticinese con un VPS o un server dedicato la domanda pratica è semplice: la versione installata è quella corretta? La risposta richiede un piccolo accorgimento, perché il numero di versione mostrato dalle distribuzioni Linux trae facilmente in inganno.
Cosa è stato corretto
Secondo gli avvisi di sicurezza di nginx, le cinque falle riguardano funzioni o combinazioni di configurazione specifiche, non ogni installazione:
| CVE | Ambito | Versioni interessate (nginx.org) | CVSS 3.1 (F5) |
|---|---|---|---|
| CVE-2026-15176 | direttiva alias combinata con rewrite | 0.1.29–1.31.6 | 8.1 |
| CVE-2026-93479 | valutazione di espressioni con variabili (per esempio map con espressioni regolari) | 1.30.0–1.30.5, 1.31.2–1.31.6 | 8.1 |
| CVE-2026-95101 | HTTP/3 con bufferizzazione della richiesta verso il proxy | 1.25.0–1.31.6 | 5.3 |
| CVE-2026-97629 | ticket di sessione TLS con cache di sessione condivisa | 1.23.2–1.31.6 | 6.5 |
| CVE-2026-97205 | I/O asincrono (AIO) con pagine SSI | 0.8.11–1.31.6 | 8.1 |
Le valutazioni divergono, e conviene capire perché:
- nginx classifica tutte e cinque le falle come di gravità media, perché servono configurazioni particolari.
- F5, l’azienda che sviluppa nginx e ha assegnato i CVE, attribuisce a tre di esse un punteggio CVSS 3.1 di 8.1 (alto), come riportato dal database NVD: nei casi peggiori un attaccante senza credenziali può far bloccare i processi di nginx e, se le protezioni della memoria del sistema (ASLR) sono disattivate o aggirate, arrivare a eseguire codice.
- La falla sui ticket TLS (CVE-2026-97629) può permettere di aggirare la verifica dei certificati client, un meccanismo usato soprattutto per accessi riservati e interfacce tra sistemi.
Secondo i dati del NVD, la valutazione della CISA del 15 ottobre non indicava sfruttamenti noti, e al 9 novembre nessuna delle cinque falle figura nel catalogo delle vulnerabilità sfruttate. Non c’è quindi motivo di allarme, ma nemmeno di rimandare: è un aggiornamento da pianificare a breve.
Un dato aiuta a inquadrare il tema: nel 2026 nginx ha già pubblicato 26 avvisi di sicurezza. Aggiornare il server web è un’attività ricorrente, non un intervento straordinario.
Il dettaglio da conoscere: il numero di versione
Le distribuzioni Linux non installano l’ultima versione di nginx, ma correggono la versione che hanno scelto all’inizio del ciclo di vita del sistema. Su Ubuntu 24.04, per esempio, il comando nginx -v mostra 1.24.0 anche dopo l’aggiornamento: la correzione è nel numero completo del pacchetto. Per sapere se il server è corretto bisogna quindi confrontare la versione del pacchetto con quella indicata dall’avviso della propria distribuzione.
Versioni del pacchetto nginx indicate come corrette (estratto):
| Sistema | Pacchetto corretto |
|---|---|
| Ubuntu 26.04 LTS | 1.28.3-2ubuntu1.12 |
| Ubuntu 24.04 LTS | 1.24.0-2ubuntu7.19 |
| Ubuntu 22.04 LTS | 1.18.0-6ubuntu14.22 |
| Debian 13 (trixie) | 1.26.3-3+deb13u10 |
| Debian 12 (bookworm) | al 9 novembre il tracker di sicurezza Debian indica il pacchetto come ancora vulnerabile |
| nginx.org (stable / mainline) | 1.30.6 / 1.31.7 |
Pannelli di hosting e immagini container (Docker) spesso includono una propria copia di nginx: in quel caso conta la versione del pannello o dell’immagine, non quella del sistema operativo.
Cosa fare con il proprio server
- Sapere dove gira nginx. Non solo sul server del sito: nginx è spesso usato come proxy davanti a gestionali, applicazioni web o container. Fate un elenco dei sistemi coinvolti.
- Verificare la versione del pacchetto. Su Ubuntu e Debian con
apt policy nginxo chiedendo al fornitore, e confrontarla con la tabella qui sopra o con l’avviso della distribuzione. - Aggiornare e riavviare il servizio. Installare l’aggiornamento di sicurezza della distribuzione, oppure la 1.30.6 o successiva se nginx proviene dai pacchetti ufficiali di nginx.org, e verificare che il servizio sia stato effettivamente riavviato. Per le immagini container: aggiornare l’immagine e ricreare il container.
- Se l’aggiornamento non è ancora disponibile (per esempio su Debian 12 al momento della pubblicazione): far verificare la configurazione da chi gestisce il server. Le falle dipendono da funzioni precise (HTTP/3, SSI con I/O asincrono, certificati client, alcune combinazioni di
aliaserewrite): disattivare ciò che non serve riduce l’esposizione in attesa della correzione. - Controllare i log. Nel log degli errori di nginx, riavvii inattesi dei processi worker possono essere il segnale di tentativi andati a vuoto o di un problema da approfondire.
Non pubblichiamo dettagli su come sfruttare queste falle: l’obiettivo è aggiornare e verificare i sistemi. Sugli aggiornamenti dei server Ubuntu e Debian abbiamo scritto anche a proposito della falla in APT.
Se il server è stato compromesso: segnalazioni
- Protezione dei dati (nLPD). Se sul server ci sono dati personali (clienti, moduli, account) e la violazione comporta verosimilmente un rischio elevato per le persone interessate, l’articolo 24 della legge sulla protezione dei dati prevede la notifica all’IFPDT il prima possibile. Le linee guida dell’IFPDT spiegano come valutare il caso.
- UFCS. Per la maggior parte delle PMI la segnalazione di un ciberincidente all’UFCS è volontaria, ma utile. Dal 1° aprile 2025 i gestori di infrastrutture critiche hanno invece l’obbligo di segnalare i ciberattacchi entro 24 ore dalla scoperta.
- Danni finanziari. In caso di danno, sporgere denuncia alla polizia cantonale.
Domande frequenti
Il nostro sito è su un hosting condiviso: dobbiamo fare qualcosa?
Il server è gestito dal fornitore, che deve applicare gli aggiornamenti. Conviene comunque chiedere per iscritto se il server web usa nginx e se gli aggiornamenti di ottobre sono stati installati.
Il nostro server usa Apache: siamo interessati?
Queste falle riguardano solo nginx. Molte installazioni però usano nginx come proxy davanti ad Apache o ad altre applicazioni: vale la pena verificarlo.
nginx -v mostra una versione vecchia: il server è vulnerabile?
Non necessariamente. Sulle distribuzioni Linux conta il numero completo del pacchetto, che include le correzioni riportate dalla distribuzione. Se corrisponde a quello dell’avviso, il server è corretto.
Non usiamo HTTP/3 né SSI: possiamo ignorare l’aggiornamento?
No. Le falle coinvolgono funzioni diverse ed è facile sottovalutare cosa contiene una configurazione cresciuta negli anni. L’aggiornamento è il modo più semplice per chiudere tutte e cinque le falle insieme.
Il nostro approccio
ElaraTeq Sagl supporta PMI e studi in Ticino nella gestione e nell’aggiornamento di server Linux e server web, nell’hosting in Svizzera e nella configurazione TLS (hosting, consulenza; sul tema TLS vedi anche i certificati a 100 giorni). Per un controllo del vostro server potete contattarci.
Fonti
- nginx, nginx security advisories
- nginx, Changes with nginx 1.30.6, 14 ottobre 2026
- NIST NVD, CVE-2026-15176, CVE-2026-93479, CVE-2026-95101, CVE-2026-97629, CVE-2026-97205
- Ubuntu, USN-8955-1: nginx vulnerabilities, 26 ottobre 2026
- Debian, DSA-6575-1 nginx – security update e tracker CVE-2026-15176
- UFCS, Obbligo di segnalare ciberattacchi contro le infrastrutture critiche
- IFPDT, Linee guida sulla notifica di violazioni della sicurezza dei dati
