Il 13 maggio 2026 il team di ricerca di Depthfirst ha reso pubblici i dettagli tecnici di CVE-2026-42945, una vulnerabilità critica nel modulo ngx_http_rewrite_module di NGINX, immediatamente ribattezzata NGINX Rift. Appena tre giorni dopo la divulgazione, i sistemi canary di VulnCheck hanno rilevato tentativi di sfruttamento attivo in the wild. Con oltre 5,7 milioni di istanze NGINX esposte su Internet che eseguono versioni potenzialmente vulnerabili, questo CVE richiede attenzione immediata da parte di tutti gli amministratori di sistema.
Cos’è e come funziona la vulnerabilità
CVE-2026-42945 è una vulnerabilità di memory corruption (heap-based buffer overflow) che risiede nel modulo di riscrittura URL di NGINX. Il problema nasce da un errore nel calcolo del buffer di destinazione quando vengono usate capture non nominati (i riferimenti $1, $2, ecc.) nelle direttive rewrite.
Il bug si manifesta quando sono presenti tutte e tre queste condizioni nella configurazione di NGINX:
- Una direttiva
rewritecon capture non nominati (es.$1,$2) - Una stringa di sostituzione che contiene un punto interrogativo (parametri GET)
- Un’ulteriore direttiva
rewrite,if, osetsuccessiva
In questa configurazione, NGINX calcola la dimensione del buffer usando un insieme di assunzioni sull’escape dei caratteri, ma poi scrive nel buffer con assunzioni diverse. Il risultato è una scrittura oltre i limiti del buffer allocato — un classico heap overflow. La cosa particolarmente insidiosa è che i byte scritti oltre il buffer sono determinati dall’URI dell’attaccante, rendendo la corruzione controllabile e quindi molto più pericolosa di un semplice crash casuale.
Esempio di configurazione vulnerabile
Ecco un pattern di configurazione che espone l’istanza NGINX all’exploit:
server {
listen 80;
server_name example.com;
location / {
# Configurazione VULNERABILE: capture non nominato ($1) + "?" nella sostituzione
rewrite ^/vecchio/(.*)$ /nuovo/?id=$1 last;
# La presenza di questa seconda direttiva aggrava il problema
rewrite ^/nuovo/(.*)$ /index.php?path=$1 last;
}
}La versione sicura usa capture nominati:
server {
listen 80;
server_name example.com;
location / {
# Configurazione SICURA: uso di capture nominati
rewrite ^/vecchio/(?P<slug>.*)$ /nuovo/?id=${slug} last;
rewrite ^/nuovo/(?P<path>.*)$ /index.php?path=${path} last;
}
}Impatto: DoS garantito, RCE possibile
L’impatto della vulnerabilità dipende dalla configurazione del sistema operativo:
- Denial of Service (DoS): ottenibile su qualsiasi configurazione NGINX vulnerabile. Richieste HTTP ripetute mantengono i worker process in un crash loop, degradando la disponibilità di tutti i virtual host serviti dall’istanza.
- Remote Code Execution (RCE): teoricamente possibile, ma richiede che l’Address Space Layout Randomization (ASLR) sia disabilitata sul server target. Su sistemi Linux moderni con ASLR abilitata (la configurazione predefinita), il RCE è significativamente più difficile da ottenere.
Il proof-of-concept pubblico rilasciato da Depthfirst dimostra il DoS in modo affidabile e ripetibile.
Versioni affette
La vulnerabilità colpisce:
- NGINX Open Source: versioni dalla 0.6.27 alla 1.30.0 inclusa
- NGINX Plus: versioni dalla R32 alla R36
- Prodotti F5 che incorporano NGINX: NGINX Ingress Controller, F5 WAF for NGINX, F5 DoS for NGINX e altri
Come verificare la propria esposizione
Prima di aggiornare, è utile capire se la propria configurazione è effettivamente sfruttabile. Non basta avere una versione vulnerabile: è necessario che sia presente il pattern di configurazione critico.
Cerca nelle tue configurazioni il pattern problematico:
# Cerca direttive rewrite con $1, $2, ecc. seguite da "?"
grep -rn 'rewrite.*\$[0-9].*?' /etc/nginx/
# Verifica la versione installata
nginx -vSu sistemi Debian/Ubuntu puoi controllare se il pacchetto è già stato aggiornato:
apt-cache policy nginx
apt-cache policy nginx-fullPatch e mitigazioni disponibili
F5 ha già rilasciato le versioni corrette:
- NGINX Open Source 1.31.0 (versione mainline) e 1.30.1 (versione stable)
- NGINX Plus R36 P4 e R32 P6
- F5 WAF for NGINX v5.13.0
- F5 DoS for NGINX v4.9.0
Le principali distribuzioni Linux stanno rilasciando pacchetti aggiornati:
# Debian/Ubuntu
sudo apt update && sudo apt upgrade nginx
# AlmaLinux/RHEL/CentOS
sudo dnf update nginx
# Verifica la versione dopo l'aggiornamento
nginx -v && nginx -tSe non è possibile aggiornare immediatamente, la mitigazione ufficiale di F5 consiste nel convertire tutti i capture non nominati in capture nominati nelle direttive rewrite, come mostrato nell’esempio di configurazione sicura sopra.
Considerazioni operative
Alcuni aspetti pratici da tenere a mente durante la risposta a questo incidente:
L’aggiornamento di NGINX su sistemi in produzione richiede tipicamente un graceful reload (nginx -s reload) che non interrompe le connessioni esistenti. Tuttavia, se si installa una nuova versione del pacchetto, potrebbe essere necessario un riavvio del processo:
# Reload della configurazione (zero-downtime)
nginx -s reload
# Oppure tramite systemd
systemctl reload nginx
# Riavvio completo (se necessario dopo aggiornamento del binario)
systemctl restart nginxPer ambienti containerizzati con NGINX come base image, è necessario ricostruire e ridistribuire i container aggiornando la versione base dell’immagine. Se si usa NGINX Ingress Controller su Kubernetes, aggiornare il deployment del controller.
Conclusione
CVE-2026-42945 è una vulnerabilità seria che merita risposta rapida. Sebbene non tutte le istanze NGINX siano sfruttabili (dipende dalla configurazione delle direttive rewrite), il DoS è ottenibile su qualsiasi sistema vulnerabile con il pattern critico e lo sfruttamento attivo è già confermato. La patch è disponibile, la migrazione alla versione 1.30.1 o 1.31.0 è il percorso consigliato. In alternativa, la conversione ai capture nominati nelle configurazioni rewrite offre una mitigazione efficace nell’immediato.
Fonti: Help Net Security, Depthfirst Security Research, F5 Security Advisory K000161019, VulnCheck