Indice dei contenuti dell'articolo:
Il 9 giugno 2026 Nebula Security ha pubblicato su X un messaggio destinato a far discutere l’intera comunità sistemistica e di sicurezza: secondo quanto dichiarato dal team, sarebbe stata segnalata a F5 una nuova vulnerabilità Remote Code Execution in NGINX, accompagnata anche da una patch proposta, ma dopo circa due settimane non sarebbe ancora arrivata una risposta ufficiale.
Il post, disponibile a questo indirizzo: https://x.com/nebusecurity/status/2064209727538745734, è particolarmente rilevante perché arriva in un periodo già molto delicato per NGINX. Nelle settimane precedenti, infatti, il progetto aveva già dovuto affrontare vulnerabilità importanti nel modulo ngx_http_rewrite_module, tra cui CVE-2026-42945, nota pubblicamente come NGINX Rift, e CVE-2026-9256, soprannominata nginx-poolslip.
https://x.com/nebusecurity/status/2064209727538745734
Questa nuova segnalazione, però, va trattata in modo diverso rispetto alle CVE già note: per ora non risulta una CVE assegnata, non esiste un advisory pubblico di F5/NGINX e non è disponibile una patch ufficiale. Questo significa che non abbiamo ancora elementi sufficienti per parlare di versioni certamente vulnerabili, condizioni precise di sfruttamento, configurazioni coinvolte o workaround validati dal vendor.
In altre parole, siamo in una fase intermedia e scomoda: abbastanza informazione per preoccuparsi, ma non abbastanza per chiudere tecnicamente il caso con un semplice comando di aggiornamento.
Che cosa ha dichiarato Nebula Security
Nel messaggio pubblicato su X, Nebula Security afferma di aver segnalato a F5 un’altra RCE in NGINX circa due settimane prima, insieme a una patch proposta. Il punto critico della comunicazione è l’assenza di risposta da parte del vendor, almeno secondo quanto dichiarato pubblicamente dal team di ricerca.
Nebula aggiunge inoltre che la vulnerabilità non dipenderebbe da una configurazione “inusuale”. Questo dettaglio è importante: spesso, quando una vulnerabilità richiede una combinazione specifica di direttive o parametri, si tende a minimizzare il rischio sostenendo che si tratti di una configurazione rara o poco realistica. Nebula contesta proprio questa impostazione, ricordando che nel mondo reale le configurazioni NGINX sono estremamente varie, spesso stratificate nel tempo e raramente pubbliche.
Di seguito la traduzione in lingua italiana:
Secondo la loro analisi preliminare, un numero significativo di deployment reali sarebbe coinvolto, incluse aziende Fortune Global 500. Anche questa affermazione va letta con cautela: non essendoci ancora un advisory tecnico completo, non possiamo verificarne autonomamente i dettagli. Tuttavia, il solo fatto che un gruppo di ricerca decida di rendere pubblica la pressione sul vendor indica che il tema è considerato serio.
Perché una RCE in NGINX è una notizia critica
NGINX non è un software marginale. È uno dei web server e reverse proxy più usati al mondo, presente su server bare metal, VPS, container, appliance, ingress controller Kubernetes, bilanciatori applicativi, ambienti Plesk, cPanel, stack custom e infrastrutture cloud. In molti casi è il primo componente che riceve traffico HTTP e HTTPS dall’esterno.
Una vulnerabilità RCE in un componente di frontiera come NGINX ha un profilo di rischio molto diverso rispetto a una vulnerabilità locale o a un bug in un servizio interno. Se sfruttabile senza autenticazione e raggiungibile via HTTP, può teoricamente consentire a un attaccante remoto di eseguire codice nel contesto del processo worker di NGINX.
Va chiarito che l’esecuzione di codice come utente NGINX non equivale necessariamente a ottenere root. NGINX, se configurato correttamente, esegue i worker con un utente non privilegiato, ad esempio nginx, www-data o simili. Tuttavia, da quel punto un attaccante potrebbe comunque leggere file accessibili al processo, interagire con backend interni, muoversi lateralmente, tentare escalation locali, abusare di socket, credenziali, configurazioni o secret presenti sul sistema.
In uno scenario hosting o reverse proxy, anche una compromissione limitata può avere conseguenze importanti, soprattutto se il server gestisce più virtual host, inoltra traffico verso backend privati o contiene configurazioni con informazioni sensibili.
Il contesto: NGINX Rift e nginx-poolslip
Per comprendere la sensibilità del momento bisogna considerare il contesto. A maggio 2026 NGINX ha pubblicato aggiornamenti per diverse vulnerabilità, tra cui CVE-2026-42945, un heap buffer overflow nel modulo ngx_http_rewrite_module. La pagina ufficiale degli advisory NGINX indica che le versioni non vulnerabili per CVE-2026-42945 sono 1.31.0+ e 1.30.1+, mentre risultano vulnerabili le versioni da 0.6.27 a 1.30.0.
Subito dopo è arrivata CVE-2026-9256, un altro buffer overflow nel modulo rewrite. In questo caso la pagina ufficiale NGINX indica come non vulnerabili le versioni 1.31.1+ e 1.30.2+, mentre risultano vulnerabili le versioni fino alla 1.31.0. Le note di rilascio di NGINX 1.30.2 parlano esplicitamente di un heap memory buffer overflow nel worker process quando viene usata una configurazione con capture sovrapposte nel rewrite module, con potenziale esecuzione di codice arbitrario.
Questi due casi sono già tracciati, documentati e patchati. La nuova segnalazione di Nebula Security sembra invece essere un ulteriore caso separato: non abbiamo ancora un nome ufficiale, un identificativo CVE o una pagina F5 che consenta di stabilire con precisione se e come sia collegata ai precedenti bug.
Il problema dell’assenza di CVE e advisory
Quando una vulnerabilità non ha ancora una CVE assegnata e non esiste un advisory ufficiale, gli amministratori si trovano in una situazione difficile. Da un lato non possono ignorare la segnalazione, soprattutto se proviene da un ricercatore o da un team con esperienza sul prodotto. Dall’altro non possono applicare una patch che non esiste, né possono confermare l’esposizione con uno scanner affidabile.
È importante non confondere tre piani diversi:
- le CVE già note e patchate, come CVE-2026-42945 e CVE-2026-9256;
- la nuova segnalazione pubblica di Nebula Security, che per ora non ha CVE o advisory ufficiale;
- le ipotesi operative che un amministratore può adottare per ridurre il rischio in attesa di dettagli.
Un errore comune sarebbe dire: “Ho aggiornato a NGINX 1.30.2 o 1.31.1, quindi sono sicuramente protetto anche da questa nuova RCE”. Non possiamo affermarlo. Quelle versioni correggono le vulnerabilità note e pubblicate, ma non è detto che correggano anche la nuova vulnerabilità segnalata da Nebula, salvo conferma futura da parte di F5/NGINX.
Cosa fare intanto subito: inventario delle versioni NGINX
Il primo passo è sapere esattamente quali istanze NGINX sono presenti nella propria infrastruttura. In molti ambienti il problema non è solo il server principale, ma anche immagini container, ingress controller, reverse proxy interni, appliance, sistemi legacy e installazioni compilate a mano.
nginx -v 2>&1
nginx -V 2>&1
Su sistemi RPM-based come AlmaLinux, Rocky Linux, RHEL e CentOS:
rpm -qa | grep -E '^nginx|nginx-' | sort
dnf list installed | grep nginx
Su Debian e Ubuntu:
dpkg -l | grep nginx
apt-cache policy nginx
In ambienti containerizzati:
docker ps --format 'table {{.Names}}t{{.Image}}t{{.Ports}}' | grep -i nginx
podman ps --format 'table {{.Names}}t{{.Image}}t{{.Ports}}' | grep -i nginx
kubectl get pods -A | grep -i nginx
kubectl get ingressclass -A
Questo inventario è fondamentale perché molte organizzazioni aggiornano il pacchetto NGINX del sistema operativo ma dimenticano immagini Docker, chart Helm, ingress controller o build custom.
Aggiornare comunque le vulnerabilità già note
Anche se la nuova RCE segnalata da Nebula non ha ancora una patch pubblica, questo non è un motivo per rimanere indietro. Al contrario, bisogna assicurarsi di aver già corretto le vulnerabilità note.
Per NGINX Open Source compilato o installato da repository ufficiali NGINX, l’obiettivo minimo per le CVE note di maggio 2026 è arrivare almeno a una versione che includa le correzioni per CVE-2026-42945 e CVE-2026-9256, quindi 1.30.2 sul ramo stable o 1.31.1 sul ramo mainline, salvo indicazioni diverse del proprio vendor.
Su AlmaLinux, Rocky Linux, RHEL e derivate, però, bisogna fare attenzione al backporting: il numero di versione del pacchetto può sembrare vecchio, ma contenere patch di sicurezza backportate dal maintainer. Per questo motivo, in ambito Enterprise Linux, è preferibile affidarsi agli advisory e ai pacchetti della distribuzione invece di confrontare ingenuamente solo la versione upstream.
dnf clean all
dnf update -y nginx*
systemctl restart nginx
nginx -v
Su Debian e Ubuntu:
apt update
apt full-upgrade -y
systemctl restart nginx
nginx -v
Questi comandi non vanno interpretati come patch per la nuova vulnerabilità non ancora pubblicata, ma come misura necessaria per chiudere almeno le falle già note.
Verificare moduli e build custom
Un’altra area spesso trascurata è la presenza di moduli dinamici o build personalizzate. NGINX viene frequentemente compilato con moduli di terze parti, moduli WAF, moduli Brotli, headers-more, Lua, NJS, stream, QUIC, HTTP/3 o componenti forniti da vendor esterni. Una vulnerabilità nel core può essere aggravata da configurazioni complesse, ma anche una build non standard può rendere più difficile il patching.
nginx -V 2>&1 | tr ' ' 'n' | grep -E 'configure|with-|add-module|modules-path|conf-path'
Se NGINX è stato compilato a mano, bisogna individuare il percorso del binario realmente in esecuzione:
which nginx
readlink -f $(which nginx)
ps -eo pid,user,comm,args | grep '[n]ginx'
In molti incidenti reali si scopre che il pacchetto del sistema operativo è aggiornato, ma il servizio systemd punta a un binario compilato manualmente in /usr/local/nginx, /opt/nginx o directory simili.
Ridurre la superficie esposta
In attesa di informazioni ufficiali, conviene ridurre tutto ciò che non è necessario. Se esistono virtual host temporanei, ambienti staging pubblici, server name inutilizzati o location legacy non più utilizzate, questo è il momento di disabilitarli.
È utile anche cercare configurazioni complesse e datate, soprattutto se legate a rewrite, regex e redirect:
grep -RInE 'rewrite|if (|set $|return 30|proxy_pass|try_files' /etc/nginx /usr/local/nginx/conf 2>/dev/null
Attenzione: questo controllo non identifica la nuova vulnerabilità di Nebula, perché non conosciamo il trigger. Serve però a mappare le aree di configurazione più delicate e a ridurre logiche inutilmente complesse. Le vulnerabilità recenti in NGINX hanno mostrato come direttive apparentemente ordinarie possano diventare pericolose in combinazioni specifiche.
Quando possibile, è opportuno spostare regole complesse a livello applicativo o semplificarle. Un reverse proxy deve fare il minimo indispensabile: terminazione TLS, proxying, caching, compressione, rate limiting, header di sicurezza e poche regole chiare. Ogni regex mantenuta per anni senza revisione aumenta il debito tecnico.
Monitorare crash, segfault e anomalie dei worker
Una RCE basata su corruzione di memoria spesso passa attraverso crash, riavvii dei worker, segfault o anomalie nei log. Non sempre questi segnali indicano sfruttamento, ma in una fase di incertezza diventano importanti.
journalctl -u nginx --since "24 hours ago" | grep -Ei 'segfault|signal|core|worker|exited'
dmesg -T | grep -Ei 'nginx|segfault|general protection|core dumped'
grep -R "signal 11|segmentation fault|core dumped" /var/log/nginx /var/log/messages /var/log/syslog 2>/dev/null
È consigliabile inviare questi eventi al proprio sistema di monitoraggio centralizzato, SIEM o log management. Un singolo worker crash può essere rumore; crash ripetuti in corrispondenza di richieste HTTP anomale meritano indagine.
Plesk, cPanel, hosting e ambienti managed
Negli ambienti hosting il tema è ancora più delicato. Plesk, cPanel, EasyApache, repository vendor, pacchetti NGINX custom e reverse proxy integrati possono avere cicli di aggiornamento diversi rispetto al pacchetto NGINX della distribuzione. Non basta verificare dnf update o apt upgrade: bisogna capire da dove arriva realmente il binario NGINX in esecuzione.
Su server con pannelli di controllo è consigliabile:
- verificare gli advisory del vendor del pannello;
- aggiornare il pannello e i componenti web stack;
- controllare eventuali repository aggiuntivi;
- riavviare NGINX dopo l’aggiornamento;
- verificare che non esistano binari custom fuori dal controllo del package manager.
Per un provider hosting, l’approccio corretto è trattare NGINX come componente critico di frontiera, al pari del kernel, di OpenSSL, di PHP-FPM e del database. La sua esposizione pubblica rende ogni RCE potenziale una priorità operativa.
Conclusione
La nuova segnalazione di Nebula Security non è ancora una CVE e non è ancora un advisory ufficiale. Questo va detto chiaramente per evitare allarmismi tecnicamente scorretti. Allo stesso tempo, ignorare il problema sarebbe imprudente: NGINX è un componente centrale dell’infrastruttura web moderna e le recenti vulnerabilità nel modulo rewrite hanno già dimostrato che bug storici possono rimanere nascosti per anni.
In assenza di patch pubblica, la risposta migliore è pragmatica: inventariare tutte le istanze NGINX, aggiornare subito le vulnerabilità già note, verificare build e moduli, ridurre la superficie esposta, controllare che i worker girino con privilegi minimi, mantenere ASLR attivo e monitorare crash o anomalie. Quando F5 o NGINX pubblicheranno un advisory ufficiale, sarà poi necessario applicare tempestivamente la patch e riavviare i servizi coinvolti.
Per ora la frase più corretta è questa: non esiste ancora una patch pubblica né una CVE assegnata per la nuova RCE citata da Nebula Security, ma gli amministratori dovrebbero prepararsi come se l’advisory potesse arrivare da un momento all’altro.
