NGINX CVE-2026-42945: exploit attivo per bug di 18 anni
Tentativi di exploit attivi per CVE-2026-42945, un heap buffer overflow di circa 18 anni nel modulo rewrite di NGINX. RCE condizionata e patch disponibili.
Contenuto
Il 17 maggio 2026 VulnCheck ha confermato tentativi di exploit attivi contro CVE-2026-42945, un heap buffer overflow rimasto latente per circa 18 anni nel modulo rewrite di NGINX. Il flaw, introdotto nel 2008 e reso pubblico il 14 maggio, consente a un attaccante non autenticato di mandare in crash i worker process con una singola richiesta HTTP appositamente costruita. Con patch già rilasciate da F5 ma la configurazione rewrite diffusissima tra i server web, il rischio concreto sposta il problema dal mero aggiornamento alla gestione del debito tecnico dell’infrastruttura.
- CVE-2026-42945 è uno heap buffer overflow nel modulo rewrite di NGINX con un punteggio di 9.2 sulla scala CVSS v4, presente per circa 18 anni nelle versioni dalla 0.6.27 alla 1.30.0.
- L’attacco non richiede autenticazione: basta una singola richiesta HTTP appositamente costruita se il server usa rewrite directive con unnamed PCRE capture e replacement string contenente il carattere '?'.
- VulnCheck ha confermato tentativi di exploit attivi rilevati sui propri honeypot, anche se non è noto se abbiano causato compromissioni effettive o si tratti di ricognizione.
- L’impatto varia da DoS immediato, causato dal crash ciclico dei worker, a RCE condizionata su sistemi privi di ASLR; F5 ha già rilasciato patch specifiche per NGINX Plus e Open Source.
Il meccanismo dell’overflow: una richiesta crafted e il worker crolla
La vulnerabilità risiede specificamente in ngx_http_rewrite_module. Secondo l’advisory rilasciato da F5, il problema si manifesta quando una rewrite directive è seguita da ulteriori direttive di tipo rewrite, if o set, e utilizza unnamed Perl-Compatible Regular Expression captures (ad esempio $1, $2) con una replacement string che include il carattere '?'. In questa condizione, il parsing del modulo non gestisce correttamente i limiti del buffer heap, consentendo un overflow.
Come riportato dall’analisi di depthfirst, l’attacco è raggiungibile senza alcuna forma di autenticazione. L’attaccante deve solo essere in grado di contattare il server via HTTP. La criticità è amplificata dalla longevità del difetto: il codice vulnerabile è stato introdotto nel 2008, rendendo il bug uno dei più longevi mai scoperti in una componente così centrale dell’infrastruttura web moderna. Le versioni affette coprono quasi due decenni di rilasci, dalla 0.6.27 fino alla 1.30.0.
"An attacker who can reach a vulnerable NGINX server over HTTP can send a single request that overflows the heap in the worker process and achieves remote code execution" — depthfirst
La portata del problema dipende tuttavia dalla presenza effettiva della configurazione vulnerabile. Non tutte le installazioni di NGINX espongono il rewrite module nel modo specifico richiesto, ma dove la condizione è soddisfatta l’exploitabilità è diretta e richiede una sola transazione di rete.
RCE o DoS: il discrimine è l’ASLR
Nonostante la gravità strutturale del buffer overflow, la transizione da semplice crash a esecuzione di codice remoto non è immediata su tutte le piattaforme. L’advisory F5 specifica che la code execution è possibile sui sistemi che non dispongono di Address Space Layout Randomization (ASLR) attiva. Kevin Beaumont ha sintetizzato il vincolo sottolineando che, per raggiungere l’RCE, l’attaccante deve agire su una macchina dove l’ASLR è stata disabilitata.
Questa distinzione è fondamentale per la valutazione del rischio. Gli stessi maintainer di AlmaLinux hanno evidenziato che, sui sistemi dove l’ASLR è abilitata — configurazione predefinita su ogni release supportata della distribuzione — non ci si aspetta che un exploit generico e affidabile sia facile da produrre. Tuttavia, il DoS resta una minaccia concreta e immediata: il crash del worker process può innescare un loop che rende il servizio indisponibile, con impatti rilevanti per hosting provider e applicazioni mission-critical.
La presenza di installazioni legacy, container con hardening ridotto o ambienti embedded dove l’ASLR è disattivata per motivi di compatibilità mantiene aperta la porta all’RCE. Non esistono al momento conferme pubbliche che l’exploit rilevato in the wild abbia già ottenuto esecuzione di codice su sistemi reali, ma la condizione teorica è documentata e verificata.
Honeypot in allerta: i primi exploit attivi nel wild
L’elemento che trasforma CVE-2026-42945 da vulnerabilità teorica a minaccia operativa è la conferma di VulnCheck. La società di threat intelligence ha rilevato tentativi di exploitation attivi attraverso le proprie reti honeypot a partire dal 17 maggio 2026. La tempistica, ravvicinata alla disclosure del 14 maggio, indica che gli attori offensivi hanno reagito con velocità, probabilmente sfruttando l’ampia finestra temporale di esposizione per massimizzare il targeting.
Il passaggio dalla teoria alla pratica offensiva è avvenuto con una rapidità che non sorprende chi opera nel threat intelligence, ma che pone un problema di tempistica per i team di sicurezza. La disclosure del 14 maggio ha lasciato un intervallo di soli tre giorni prima che i primi exploit attivi comparissero nei log di VulnCheck. Questa finestra, sebbene breve, è sufficiente per gli attori che dispongono di infrastrutture di scanning già pronte a testare massivamente le superfici esposte su Internet.
Rimangono però ignoti diversi parametri dell’attività. Non è chiaro se gli exploit rilevati abbiano portato a compromissioni effettive o se si tratti di fasi iniziali di scanning e ricognizione. Non sono disponibili informazioni su settori, geografiche o target specifici presi di mira. Manca inoltre la conferma pubblica di un proof-of-concept per la RCE, anche questo un limite significativo nella lettura della campagna.
Cosa fare adesso
La risposta all’emergenza richiede azioni tecniche prioritarie e specifiche. Ecco le quattro mosse consigliate per gli operatori di infrastruttura.
Aggiornare immediatamente. F5 ha rilasciato fix distinti per il ramo commerciale e quello open source. Per NGINX Plus le versioni corrette sono R32 P6 e R36 P4; per NGINX Open Source le release fixate sono la 1.30.1 e la 1.31.0. L’applicazione della patch è la contromisura definitiva perché riscrive la gestione del buffer nel rewrite module.
Verificare la configurazione, ma senza illudersi. Gli amministratori dovrebbero controllare la presenza di rewrite directive seguite da if, set o altre rewrite, con unnamed PCRE captures ($1, $2) e replacement string contenente '?'. Strumenti di configuration management e audit automatici possono accelerare questo passaggio, ma è fondamentale non considerare il risultato come una mitigazione definitiva: finché il binario non è patchato, il parser vulnerabile resta in memoria.
Mantenere l’ASLR attiva. Sui sistemi Linux, verificare che Address Space Layout Randomization sia abilitata a livello di kernel. Questo non previene il DoS — il crash del worker può avvenire comunque — ma innalza significativamente la barriera per l’esecuzione di codice remoto, specialmente sui server fisici e virtuali standard.
Monitorare i crash dei worker. L’exploit, anche fallito nel tentativo di RCE, produce un crash del processo worker. Analizzare i log di errore di NGINX e i core dump per segnalazioni anomale di segmentation fault subito dopo richieste HTTP esterne è un indicatore prezioso di tentativo di attacco in corso.
Il ritorno di un bug del 2008 dimostra che la superficie di attacco non si misura solo in righe di codice nuove, ma anche in scelte architetturali dimenticate. Per le aziende che gestiscono infrastrutture web su larga scala, CVE-2026-42945 non è solo un’allerta di patching: è il segnale che il debito tecnico della sicurezza accumulato nei server più stabili può trasformarsi in una minaccia attiva da un giorno all’altro. La velocità di rilevamento di VulnCheck, unita alla semplicità condizionata dell’attacco, rende urgente una verifica dell’intero parco macchine, non solo degli asset perimetrali più evidenti.
Domande frequenti
La mia installazione è vulnerabile anche se non uso esplicitamente il rewrite module?
No. Il bug si attiva solo in presenza di una configurazione specifica che coinvolge rewrite directive con unnamed PCRE captures e replacement string contenente '?'. Se il server non espone questa combinazione, il flaw non è triggerabile dall’esterno, anche se il codice vulnerabile è presente nel binario.
L’aggiornamento di NGINX è sufficiente o devo anche modificare la configurazione?
La patch rilasciata da F5 corregge la gestione del buffer nel rewrite module a livello di codice. Installare una versione fixata risolve la vulnerabilità. La revisione delle regole di rewrite resta una buona pratica di hardening, ma non è una mitigazione autonoma sufficiente a proteggere il sistema.
Perché il bug è rimasto nascosto per circa 18 anni?
La condizione di trigger è ristretta a un pattern specifico — unnamed PCRE captures con replacement string contenente '?' in certi contesti di rewrite — che ha reso il difetto latente per quasi due decenni. Solo analisi recenti hanno mappato il percorso esatto che porta all’overflow, portando alla disclosure del 14 maggio 2026.
Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.
Fonti
- https://thehackernews.com/2026/05/new-exim-bdat-vulnerability-exposes.html
- https://thehackernews.com/2026/05/ollama-out-of-bounds-read-vulnerability.html
- https://thehackernews.com/2026/05/18-year-old-nginx-rewrite-module-flaw.html
- https://thehackernews.com/2026/05/nginx-cve-2026-42945-exploited-in-wild.html