F5 NGINX: tre falle critiche, possibile RCE senza autenticazione

A metà ottobre 2026 F5 ha pubblicato correzioni per diverse vulnerabilità di NGINX, tre delle quali critiche: CVE-2026-15176, CVE-2026-93479 e CVE-2026-97205, tutte con punteggio CVSS 9.2 (CVSS v4.0, secondo CSO Online). BleepingComputer e CSO Online parlano di patch fuori ciclo (out-of-band). Un attaccante remoto e senza autenticazione può sfruttarle con richieste HTTP costruite ad arte, ma solo con configurazioni particolari, diverse da quelle predefinite. L’effetto certo è il crash o il riavvio del processo worker (denial of service); l’esecuzione di codice è possibile se ASLR è disattivato o aggirabile.

Secondo BleepingComputer e CSO Online, F5 non ha evidenze di sfruttamento attivo. Il Centre for Cybersecurity Belgium (CCB) ha pubblicato un avviso che invita ad aggiornare immediatamente. Secondo Security Affairs i problemi corretti in tutto sono undici: il dato è riportato solo da questa testata.

Prodotti colpiti

Secondo BleepingComputer e CSO Online: NGINX Plus, NGINX Open Source, NGINX Ingress Controller, NGINX Gateway Fabric e NGINX Instance Manager. Le fonti non riportano le versioni vulnerabili né quelle corrette: vanno lette nei bollettini di F5 per ciascun prodotto e, per NGINX Open Source installato dai pacchetti di una distribuzione Linux, negli avvisi della distribuzione.

Le tre vulnerabilità

• CVE-2026-15176: heap buffer overflow nel processo worker. Si presenta con configurazioni che usano la direttiva alias in un blocco location e la variabile $request_filename.
• CVE-2026-93479: heap buffer overflow legato alla direttiva map. Secondo Security Affairs riguarda le configurazioni in cui le variabili di cattura dell’espressione regolare di una map sono usate prima della variabile di output della map, oppure in cui una variabile non memorizzabile in cache (non-cacheable) è usata in un’espressione di stringa, in certe condizioni.
• CVE-2026-97205: use-after-free secondo Security Affairs, con I/O asincrono su file (AIO) attivo, quando NGINX elabora pagine Server Side Includes (SSI) con comandi include virtual. Può corrompere la memoria o terminare il worker.

Le fonti non concordano sul modulo: per Security Affairs la CVE-2026-97205 è in ngx_http_core_module, CSO Online colloca lì sia questa sia la CVE-2026-15176, mentre BleepingComputer le attribuisce entrambe a ngx_http_v3_module (HTTP/3). Le condizioni di configurazione e le mitigazioni di F5 sono invece le stesse in tutte le fonti, ed è da queste che si capisce se un server è esposto.

In termini MITRE ATT&CK lo sfruttamento rientra in T1190 (Exploit Public-Facing Application) e, per i crash ripetuti, in T1499.004 (Endpoint Denial of Service: Application or System Exploitation). Le fonti non riportano indicatori di compromissione né exploit pubblici per queste tre falle.

Impatto per le aziende europee e italiane

NGINX fa da reverse proxy, bilanciatore e ingress Kubernetes davanti a moltissimi servizi web, e spesso è lì che termina il TLS. Un analista citato da CSO Online sottolinea che l’esecuzione di codice in quel punto darebbe accesso in chiaro a password, cookie di sessione, token delle API e chiavi private. Anche senza esecuzione di codice, un worker che si riavvia di continuo significa servizi irraggiungibili.

NGINX è spesso incorporato in appliance, immagini di container e controller di ingress, e molti lo installano dalla propria distribuzione Linux: secondo lo stesso analista, Amazon Linux indicava ancora come in attesa la correzione relativa all’AIO. L’aggiornamento pubblicato da F5 non arriva quindi da solo su tutti i server. Sempre secondo CSO Online, sono le ultime di una serie: a maggio la CVE-2026-42945 («NGINX Rift», nel modulo rewrite) era uscita con un proof of concept pubblico di esecuzione di codice, a giugno era arrivata la CVE-2026-42530 in ngx_http_v3_module.

Per i soggetti NIS2, in particolare fornitori di servizi digitali, hosting e servizi gestiti, il caso rientra nella gestione delle vulnerabilità con priorità e tempi documentati; un’interruzione significativa dovuta a un attacco va valutata ai fini della notifica al CSIRT Italia dell’ACN. Nella sanità NGINX pubblica spesso portali per i pazienti e API delle applicazioni cliniche: conviene controllare anche lì.

Cosa fare subito

1. Fai l’inventario di dove gira NGINX: server, container, controller di ingress e appliance. nginx -V mostra versione e moduli compilati.
2. Controlla la configurazione effettiva con nginx -T: cerca alias insieme a $request_filename, aio attivo insieme a ssi on, e blocchi map con catture senza nome ($1, $2…).
3. Aggiorna alle versioni corrette indicate da F5 per ciascun prodotto o, per i pacchetti della distribuzione, appena la distribuzione le rende disponibili. Priorità ai server esposti su Internet con le configurazioni del punto 2.
4. Se non puoi aggiornare subito, applica le mitigazioni di F5 riportate da BleepingComputer e CSO Online:
   • CVE-2026-15176: evita la direttiva alias in un blocco location o la variabile $request_filename;
   • CVE-2026-97205: disattiva l’AIO oppure le SSI;
   • CVE-2026-93479: usa catture con nome al posto di quelle senza nome e limitane l’uso al blocco con l’espressione regolare.
5. Verifica che ASLR sia attivo: su Linux cat /proc/sys/kernel/randomize_va_space deve restituire 2. Secondo F5, come riporta CSO Online, senza ASLR il rischio di esecuzione di codice cresce molto.
6. Sorveglia i riavvii dei worker: righe ripetute come «worker process … exited on signal» nell’error log di NGINX possono indicare tentativi di sfruttamento. Esegui i worker con un utente senza privilegi e separa la rete del reverse proxy dai sistemi interni più critici.

Come aiuta ARXDOME

L’inventario di ARX Sentry elenca software, processi e porte di ogni server con l’agent, così trovi dove gira NGINX. ARX Shield mostra le vulnerabilità aperte per macchina e per pacchetto, ARX Expose quali servizi pubblici della tua azienda hanno vulnerabilità note: insieme aiutano a decidere da quali server partire.

Ultimo aggiornamento: 20 ottobre 2026