Due falle critiche in NGINX: il web server più diffuso al mondo va aggiornato subito

Il 17 giugno la società F5 — che sviluppa NGINX — ha rilasciato in via straordinaria le correzioni per due vulnerabilità critiche in NGINX Open Source, il software che fa funzionare una quota enorme dei siti e dei servizi online del mondo. Entrambe permettono, in determinate condizioni, di eseguire codice da remoto senza alcuna autenticazione: cioè il tipo di falla più seria che esista. La buona notizia è che la patch c’è già.

Cos’è NGINX (e perché probabilmente lo usi senza saperlo)

NGINX è un web server e reverse proxy: in pratica è il programma che, dietro le quinte, riceve le richieste di chi visita un sito e gli serve le pagine, oppure smista il traffico verso le applicazioni giuste. È diffusissimo: regge siti vetrina, e-commerce, gestionali self-hosted, pannelli e applicazioni aziendali installate su server o VPS.

Il punto è proprio questo: quasi nessun titolare d’impresa sa di “usare NGINX”. Eppure c’è ottime probabilità che stia sotto il sito dell’azienda, sotto il software gestionale raggiungibile via browser o sotto il servizio online di un fornitore.

2

Le falle critiche corrette da F5 in NGINX

CVE-2026-42530 (modulo HTTP/3, QUIC) e CVE-2026-42055 (moduli proxy/gRPC su HTTP/2): entrambe sfruttabili da remoto e senza autenticazione, con possibile esecuzione di codice. Corrette in NGINX Open Source 1.31.2 e NGINX Plus 2.6.4.

Fonte: F5, The Hacker News, SecurityWeek, Security Affairs — giugno 2026

Chi è davvero esposto

Una precisazione che evita allarmismi inutili: non ogni installazione di NGINX è vulnerabile allo stesso modo. Le due falle riguardano funzioni specifiche — il modulo HTTP/3 (la tecnologia QUIC) per una, i moduli proxy e gRPC su HTTP/2 per l’altra. Chi non usa quelle funzioni è meno esposto. Ma stabilirlo richiede di guardare la configurazione del server, e qui la platea si divide nettamente in due.

Due destinatari opposti per la stessa notizia

Se amministri tu il server (o ce l'hai su un VPS che gestisci), la patch la applichi tu: aggiornare è un'azione tecnica diretta. Se invece sito e applicazioni girano su un hosting o su un servizio di un fornitore, l'aggiornamento non spetta a te: la mossa è una domanda al provider. Stessa falla, due risposte.

Cosa fare, in concreto

• Se gestisci tu il server (o un VPS): verifica la versione di NGINX e aggiorna alle release corrette — NGINX Open Source 1.31.2 o NGINX Plus 2.6.4 — dando priorità ai server esposti a internet, soprattutto se usano HTTP/3 o fanno da proxy verso altre applicazioni.
• Se hai un fornitore o un hosting: non devi fare nulla a mano, ma puoi chiedere. Una mail di due righe — “il server su cui sono ospitato usa NGINX? è stato aggiornato per le falle CVE-2026-42530 e CVE-2026-42055?” — è legittima e ti dà una risposta certa.
• Se hai un software gestionale o applicativo raggiungibile via browser: chiedi al fornitore del software come tratta gli aggiornamenti del server sottostante. Spesso è proprio lì che NGINX lavora silenziosamente.

In breve

F5 ha corretto il 17 giugno due falle critiche in NGINX (CVE-2026-42530 e CVE-2026-42055) che consentono l’esecuzione di codice da remoto senza autenticazione, con patch già disponibili (1.31.2 per NGINX Open Source, 2.6.4 per NGINX Plus). NGINX è quasi sempre invisibile al titolare d’impresa ma regge moltissimi siti e applicativi. Chi amministra il server aggiorna; chi si appoggia a un fornitore chiede conferma. In entrambi i casi, l’esposizione reale dipende dalla configurazione: non è un motivo per ignorare il problema, ma per affrontarlo con la domanda giusta.