CVE-2026-42945: exploitation attiva su server NGINX in corso

CVE-2026-42945: exploitation attiva su server NGINX in corso

Il 16 maggio 2026 i sensori canary di VulnCheck hanno iniziato a registrare tentativi di exploitation attiva contro CVE-2026-42945, la vulnerabilità critica nel modulo rewrite di NGINX nota come NGINX Rift. L'attacco è iniziato appena tre giorni dopo la pubblicazione del proof-of-concept da parte dei ricercatori Depthfirst, azzerando il tradizionale intervallo di patch per le infrastrutture che usano NGINX come web server, reverse proxy o load balancer. La minaccia concreta è un denial of service immediato e, su server con specifiche condizioni, l'esecuzione remota di codice tramite richieste HTTP appositamente create.

Come funziona l'heap overflow nel modulo rewrite

Il bug si annida nel calcolo del buffer del modulo ngx_http_rewrite_module, il componente che gestisce la riscrittura degli URI in NGINX. Quando una configurazione contiene una direttiva rewrite con unnamed regex capture — le variabili $1, $2 — e la replacement string include un punto interrogativo, il codice commette un errore di stima nella fase di escaping. Il buffer allocato sulla base di quella stima risulta più piccolo della stringa effettivamente scritta, causando una corruzione heap nel worker process che gestisce la richiesta. Il mismatch tra le assunzioni di escaping nel calcolo della dimensione e nella scrittura effettiva è il cuore del problema.

"A bug in the ngx_http_rewrite_module lets a remote, unauthenticated attacker corrupt the heap of an NGINX worker process by sending crafted URI. The trigger is a common configuration pattern: a rewrite directive with an unnamed regex capture ($1, $2) and a replacement string that contains a question mark, followed by another rewrite, if, or set directive"

La natura remota e non autenticata della vulnerabilità rende l'attacco particolarmente insidioso: chiunque possa raggiungere il server via HTTP può inviare un URI appositamente costruito per innescare la corruzione. La presenza successiva di un'altra direttiva rewrite, di un blocco if o di un set completa la catena esecutiva che porta alla scrittura oltre i limiti del buffer. Non è necessario che l'attaccante possa interagire con il sistema operativo sottostante: la richiesta malevola basta a compromettere la memoria del processo NGINX.

Da PoC a exploitation in-the-wild: la cronologia di tre giorni

La vulnerabilità è stata resa pubblica con identificativo CVE-2026-42945 e il PoC dei ricercatori Depthfirst ha dimostrato la fattibilità pratica dell'attacco in laboratorio. Secondo quanto rivelato da VulnCheck, i primi tentativi di exploitation in-the-wild sono stati rilevati il 16 maggio 2026 attraverso i canary systems, un lasso di tempo di circa tre giorni dalla divulgazione tecnica iniziale.

Questa compressione temporale annulla la finestra tradizionale che i team di sicurezza utilizzano per testare e distribuire le patch in ambienti di produzione. Per molte organizzazioni che basano la propria presenza web, i propri reverse proxy e i load balancer su NGINX, il ritardo tra la disponibilità pubblica del codice di exploit e l'osservazione di traffico malevolo contro i propri asset è sceso a livelli per cui la risposta deve essere automatica, non pianificata. La divulgazione simultanea del meccanismo tecnico e dell'attività in-the-wild non lascia spazio alla valutazione del rischio su tempi lunghi.

DoS garantito e RCE condizionale: chi è a rischio

Su una configurazione NGINX che adotta il pattern rewrite vulnerabile, l'exploit consente almeno il denial of service: il crash del worker process interrompe il servizio per la richiesta in corso e può degradare le prestazioni dell'intero nodo, specialmente se la richiesta viene ripetuta in volume. Questo scenario è considerato raggiungibile su installazioni che includono la combinazione rewrite con unnamed capture e punto interrogativo, una sintassi presente in molte configurazioni legacy e in alcuni template moderni.

L'esecuzione remota di codice è invece una possibilità più ristretta e condizionata. Secondo quanto riportato, per ottenere il controllo completo del server è necessario che l'ASLR sia disabilitato sul sistema target, una condizione che riduce drasticamente la superficie di attacco ma che non esclude la criticità del difetto. Kevin Beaumont e VulnCheck hanno evidenziato che gli attaccanti possono raggiungere l'RCE se riescono a disattivare l'ASLR, un'evenienza che sposta il focus dalla semplice esposizione del servizio alla sicurezza del sistema operativo sottostante.

La popolazione di server potenzialmente esposti è significativa ma non omogenea. Una query Censys indica circa 5,7 milioni di server NGINX esposti su internet che eseguono versioni comprese nell'intervallo affetto. Tuttavia, come ha precisato l'Initial Access team di VulnCheck, la porzione effettivamente exploitabile è molto più piccola e dipende strettamente dalla presenza della configurazione rewrite specifica che innesca il mismatch di escaping.

Cosa fare adesso

Le contromisure disponibili sono immediate e, nel caso della mitigazione per configurazione, non richiedono necessariamente l'attesa di un reboot del kernel o di un ciclo di manutenzione esteso. Ecco le azioni prioritarie per i team di sicurezza e infrastruttura.

• Aggiornare alla versione patchata: F5 ha rilasciato le correzioni nelle versioni 1.31.0 e 1.30.1 di NGINX Open Source e nelle versioni corrispondenti di NGINX Plus. L'installazione deve essere considerata urgente per qualsiasi nodo esposto a traffico internet non fidato.
• Adottare named captures nelle rewrite: Sostituire gli unnamed regex capture ($1, $2) con named captures altera il flusso di elaborazione del modulo rewrite e rimuove il trigger del mismatch di escaping. Questa mitigazione può essere applicata a livello di configurazione senza attendere i tempi dell'upgrade software e senza modificare la logica di routing.
• Ispezionare i log e monitorare i crash: Verificare la presenza di richieste HTTP anomale dirette a URI craftati e riavvii improvvisi dei worker process. Un aumento di segnalazioni di errore nel modulo rewrite o un incremento dei messaggi di out-of-memory possono indicare tentativi di exploitation in corso.
• Non sottovalutare il rischio DoS: Anche se l'RCE richiede condizioni particolari, il denial of service è raggiungibile su configurazioni comuni e può causare interruzioni di servizio immediate. Le organizzazioni devono agire assumendo che il proprio server possa essere portato offline da richieste HTTP remote non autenticate.

La velocità con cui il PoC di NGINX Rift si è tradotto in exploitation attiva conferma che il tempo di reazione per gli amministratori di sistema si è ridotto a poche ore. La configurazione rewrite che attiva il bug è comune nel web serving, rendendo imperativa una verifica immediata delle direttive in produzione. Per le organizzazioni che gestiscono milioni di sessioni attraverso NGINX, la priorità non è più pianificare un aggiornamento nel prossimo ciclo di manutenzione, ma eseguirlo ora per chiudere una finestra di attacco già aperta.

Domande frequenti

Quali versioni di NGINX sono esattamente coinvolte dalla CVE-2026-42945?

Le versioni affette di NGINX Open Source vanno dalla 0.6.27 alla 1.30.0, mentre NGINX Plus è vulnerabile dalle release vR32 a R36. Le patch rilasciate dal vendor F5 sono disponibili nelle versioni 1.31.0 e 1.30.1, che correggono il mismatch di escaping nel modulo rewrite.

Perché la named capture blocca tecnicamente l'exploit?

Il bug nasce da un mismatch di escaping tra la stima della dimensione del buffer e la scrittura effettiva, una condizione che si manifesta specificamente con unnamed regex captures ($1, $2) e replacement string contenente un punto interrogativo. L'uso di named captures modifica il modo in cui NGINX calcola e gestisce le variabili di riscrittura, evitando la condizione di heap overflow senza bisogno di alterare il codice binario.

Sono stati osservati casi concreti di RCE in-the-wild o solo tentativi di DoS?

Al momento non è confermato se i tentativi rilevati da VulnCheck abbiano portato a esecuzione remota di codice su sistemi in produzione. L'exploitation documentata punta a corruzione della memoria e denial of service, mentre l'RCE condizionale richiede che l'ASLR sia disabilitato sul target, un requisito che limita la probabilità di successo ma non esclude la necessità di patching.

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

Fonti

• https://www.schneier.com/blog/archives/2026/05/copy-fail-linux-vulnerability.html
• https://www.helpnetsecurity.com/2026/05/18/ngnix-vulnerability-exploited-cve-2026-42945/
• https://thehackernews.com/2026/05/ollama-out-of-bounds-read-vulnerability.html
• https://www.darkreading.com/application-security/trustfall-exposes-claude-code-execution-risk