Exploit attivo CVE-2026-42945: NGINX Rift in-the-wild

Exploit attivo CVE-2026-42945: NGINX Rift in-the-wild

Attaccanti non autenticati hanno iniziato a sfruttare attivamente la vulnerabilità CVE-2026-42945, soprannominata NGINX Rift, nel modulo ngx_http_rewrite_module a partire dal 16 maggio 2026. La rilevazione, effettuata da VulnCheck tramite sistemi canary, è avvenuta in circa 72 ore dalla pubblicazione del proof-of-concept da parte di Depthfirst, trasformando una falla memory-unsafe dormiente per quasi 18 anni in un’emergenza operativa per il web server più diffuso al mondo. Il bug, una heap buffer overflow deterministica, espone siti web, API e infrastrutture di delivery a interruzioni di servizio o potenziali compromissioni remote, ma solo su configurazioni specifiche che utilizzano direttive rewrite con catture regex senza nome e replacement string contenenti il carattere '?'.

Una falla di quasi 18 anni nel motore di riscrittura

Il bug CVE-2026-42945 risiede nel modulo ngx_http_rewrite_module di NGINX ed è stato introdotto nel codice sorgente nel 2008, a partire dalla versione 0.6.27. Per quasi 18 anni la vulnerabilità è rimasta latente nel motore di riscrittura URI, un componente centrale del web server open source più utilizzato a livello globale per la gestione di siti web, API e contenuti statici.

La scoperta è stata effettuata dal team di Depthfirst, che ha impiegato una piattaforma AI-native per l’analisi automatizzata del codice, e segnalata responsabilmente il 21 aprile 2026. F5, attuale maintainer del progetto, ha successivamente pubblicato un advisory tecnico e rilasciato aggiornamenti per NGINX Open Source e NGINX Plus, mentre le distribuzioni Linux, tra cui AlmaLinux, Ubuntu e Debian, hanno iniziato a distribuire pacchetti patchati ai propri repository.

Il difetto affonda le radici in un errore di calcolo della dimensione del buffer all’interno dello script engine a due passaggi del rewrite module. Durante il primo passaggio il motore stima lo spazio necessario per costruire la URI riscritta, ma nel secondo passaggio le assunzioni cambiano quando sono presenti catture regex senza nome, una replacement string contenente il carattere '?' e direttive successive, generando una discrepanza che consente la scrittura oltre i confini dell’area allocata sull’heap in modo deterministico.

Exploit attivo dal 16 maggio: cronaca di un attacco in circa 72 ore

La transizione dalla disclosure pubblica alla exploitation in-the-wild è stata rapidissima. Depthfirst ha reso pubblici i dettagli tecnici approfonditi e il codice del proof-of-concept dopo il rilascio dell’advisory F5; in circa 72 ore, VulnCheck ha rilevato tentativi di sfruttamento attivo tramite i propri sistemi canary e reti honeypot, con il primo flagging datato 16 maggio 2026.

Gli attacchi osservati utilizzano richieste HTTP crafted progettate per innescare la condizione di overflow su server che espongono configurazioni vulnerabili. Non è nota l’identità degli attori di minaccia né la finalità precisa delle operazioni rilevate, che potrebbero spaziare dalla ricognizione preliminare al crash loop intenzionale finalizzato a degradare la disponibilità del servizio.

Secondo stime derivate da query Censys condotte da VulnCheck, circa 5,7 milioni di server NGINX esposti su Internet eseguono una versione potenzialmente vulnerabile. Tuttavia, come sottolineato dagli stessi ricercatori dell’Initial Access team, il sottoinsieme realmente exploitabile è presumibilmente molto più ristretto, dipendendo strettamente dalla presenza delle direttive rewrite critiche e dalla geometria della richiesta in ingresso.

Heap overflow controllato: il meccanismo nel two-pass engine

Il nucleo tecnico dell’exploit sfrutta una heap buffer overflow deterministica in cui l’attaccante controlla direttamente i byte eccedenti. Depthfirst ha documentato che il calcolo della dimensione del buffer nel primo passaggio dello script engine si basa su assunzioni diverse rispetto alla fase di scrittura effettiva, creando una condizione di undersizing precisa quando la replacement string include il carattere '?' e sono coinvolte catture senza nome come $1 o $2.

In questa condizione, i byte scritti oltre l’allocazione non sono casuali: derivano direttamente dall’URI in ingresso, che l’attaccante può modellare a piacimento. Come spiegato dai ricercatori:

"The bytes written past the allocation are derived from the attacker’s URI, so the corruption is shaped by the attacker rather than random. Repeated requests can also be used to keep workers in a crash loop and degrade availability for every site served by the instance."

Per trasformare l’overflow in esecuzione remota di codice, il proof-of-concept impiega una tecnica sofisticata di cross-request heap feng shui: l’attaccante corrompe il puntatore cleanup di una struttura ngx_pool_t adiacente, reindirizzandolo verso una ngx_pool_cleanup_s fasulla che invoca system() durante la distruzione del pool, sfruttando POST body per il spraying dato che i byte dell’URI non possono contenere null bytes.

DoS immediato, RCE condizionato: il vero perimetro del rischio

L’impatto della vulnerabilità non è uniforme su tutte le installazioni. Il denial of service è affidabile e immediato: un worker NGINX che processa una richiesta malformata nella configurazione vulnerabile va in crash, e richieste ripetute possono mantenere l’istanza in un loop di fallimenti degradando la disponibilità di ogni sito e API serviti dall’istanza.

L’esecuzione remota di codice, invece, è fortemente condizionata dall’ambiente target. F5, VulnCheck e il ricercatore Kevin Beaumont concordano nel ritenere che convertire l’heap overflow in code execution non sia banale su sistemi con ASLR abilitato, configurazione predefinita su ogni release AlmaLinux supportata.

I maintainer di AlmaLinux hanno precisato: "Turning the heap overflow into reliable code execution is not trivial in the default configuration, and on systems with ASLR enabled (which is the default on every supported AlmaLinux release), we do not expect a generic, reliable exploit to be easy to produce. That said, 'not easy' is not 'impossible,' and the worker-crash DoS is exploitable enough on its own that we recommend treating this as urgent".

La distinzione è cruciale per le priorità di remediation: mentre la compromissione remota richiede una configurazione non standard con protezioni disattivate, il mero DoS è già sufficiente a giustificare un intervento immediato su ogni istanza esposta.

Cosa fare adesso

• Verificare immediatamente nelle configurazioni NGINX la presenza di direttive rewrite che impiegano catture regex senza nome, come $1 o $2, con replacement string contenente il carattere '?' e ulteriori direttive successive.
• Applicare gli aggiornamenti rilasciati da F5 per NGINX Open Source (versioni 1.30.1 e 1.31.0) e NGINX Plus (R32 P6, R36 P4, 37.0.0), o i pacchetti patchati forniti dalle distribuzioni Linux quali AlmaLinux, Ubuntu e Debian.
• Confermare che Address Space Layout Randomization (ASLR) sia attivato a livello di sistema operativo, poiché la sua presenza rende notevolmente più complessa la realizzazione di un exploit generico per esecuzione remota di codice.
• Monitorare i log delle istanze esposte per richieste HTTP anomale indirizzate a endpoint con rewrite rule sospette e valutare regole di rate limiting o WAF per mitigare il rischio di crash loop dei worker.

La rapidità con cui il proof-of-concept di NGINX Rift si è tradotto in exploitation attiva conferma che la latenza storica non offre più alcuna tregua.

Una vulnerabilità memory-unsafe dormiente per quasi due decadi può diventare un’emergenza operativa in meno di una settimana dalla disclosure, ridefinendo il tempo di reazione per chi gestisce infrastrutture di delivery.

La lezione non è solo tecnica: la configurazione di un web server rimane un attacco surface spesso trascurato, dove anche direttive comuni possono nascondere bug critici.

Domande frequenti

Tutte le installazioni NGINX sono a rischio?

No. La vulnerabilità si manifesta solo in presenza di una configurazione rewrite specifica con catture senza nome e replacement contenente il carattere '?'. I server che non utilizzano questa combinazione di direttive non sono interessati dal bug.

L’RCE è praticabile sui sistemi moderni?

Le fonti tecniche convergono nel ritenere che l’esecuzione remota di codice non sia banale su sistemi con ASLR attivato, che rappresenta il default delle principali distribuzioni Linux. Il rischio concreto e immediato resta il denial of service tramite crash dei worker.

Quali versioni risolvono la falla?

F5 ha rilasciato patch per NGINX Open Source 1.30.1 e 1.31.0, oltre a NGINX Plus R32 P6, R36 P4 e 37.0.0. Anche i vendor Linux stanno distribuendo pacchetti aggiornati.

Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.

Fonti

• https://www.helpnetsecurity.com/2026/05/18/ngnix-vulnerability-exploited-cve-2026-42945/
• 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
• https://thehackernews.com/2026/05/ollama-out-of-bounds-read-vulnerability.html
• https://www.securityweek.com/poc-code-published-for-critical-nginx-vulnerability/
• https://www.schneier.com/blog/archives/2026/05/how-dangerous-is-anthropics-mythos-ai.html