NGINX Rift e Fragnesia: due falle critiche nel cuore…

Un heap overflow latente dal 2008 colpisce quasi 19 milioni di server NGINX con RCE non autenticata, mentre un exploit Linux locale corrompe la page cache per

Una vulnerabilità remota non autenticata latente da 18 anni nel server web più diffuso al mondo e un exploit locale per il kernel Linux che corrompe la page cache per ottenere root: nella seconda settimana di maggio 2026, l'infrastruttura di internet ha subito una doppia frattura. La concomitanza non è casuale. Entrambe le falle sono state scoperte con assistenza di strumenti AI, confermando che il tempo di incubazione delle vulnerabilità long-lived — bug che dormono nel codice per anni o decenni — sta collassando da un orizzonte pluriennale a mesi o settimane. Il calcolo del rischio per chi gestisce patching prioritario cambia in modo strutturale.

Punti chiave

CVE-2026-42945, soprannominata NGINX Rift, è un heap buffer overflow nel modulo rewrite di NGINX presente dal 2008 con CVSS 9.2; permette RCE non autenticata con una singola richiesta HTTP
F5 Networks ha rilasciato patch il 13 maggio 2026 dopo disclosure responsabile del 21 aprile 2026; le versioni 0.6.27-0.9.7 non riceveranno correzioni
Fragnesia, scoperto da William Bowling, sfrutta il sottosistema XFRM ESP-in-TCP del kernel Linux per corrompere la page cache di file leggibili e scalarne i privilegi fino a root
DepthFirst AI ha identificato automaticamente quattro vulnerabilità di corruzione memoria in NGINX — inclusa Rift — caricando una sola volta il codice sorgente nel sistema di analisi

NGINX Rift: 18 anni di latenza, una richiesta per compromettere il server

Il 21 aprile 2026, i ricercatori di depthfirst hanno consegnato a F5 Networks la disclosure responsabile di una vulnerabilità nel ngx_http_rewrite_module. Il 13 maggio 2026, F5 ha distribuito le patch. Secondo l'advisory del vendor, il difetto si manifesta quando una direttiva rewrite è seguita da set, rewrite o if con cattura PCRE senza nome — come $1, $2 — e una stringa di replacement che contiene il carattere ?.

Il meccanismo è una discrepanza tra fasi. Nella prima fase, il motore di rewrite calcola la dimensione del buffer allocando spazio per i caratteri speciali in forma decodificata. Nella seconda fase, copia effettivamente i byte dalla URI originale. Quando un carattere come ? in URL encoding occupa tre byte invece di uno, la copia supera l'allocazione: heap overflow controllato dall'attaccante. I byte oltre il limite derivano dalla URI dell'attaccante, quindi la corruzione è modellata, non casuale.

Secondo depthfirst, citato da The Hacker News: "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. There is no authentication step, no prior access requirement, and no need for an existing session." La stessa fonte precisa che "the bytes written past the allocation are derived from the attacker's URI, so the corruption is shaped by the attacker rather than random."

Il PoC pubblico su GitHub combina l'overflow con una primitiva LFI/arbitrary-file-read sullo stesso host per bypassare ASLR. La versione base dell'exploit richiede ASLR disabilitato; la chain avanzata che bypassa ASLR è più complessa. Non emergono conferme di exploitation attiva in-the-wild allo stato attuale.

"NGINX Plus and NGINX Open Source have a vulnerability in the ngx_http_rewrite_module module... when the rewrite directive is followed by a rewrite, if, or set directive and an unnamed Perl-Compatible Regular Expression (PCRE) capture (for example, $1, $2) with a replacement string that includes a question mark (?)" — F5 Networks advisory

La superficie di attacco: quasi 19 milioni di istanze, molte senza patch

Secondo Rod Trent, autore della newsletter originale su Substack, circa 19 milioni di istanze NGINX sono esposte worldwide. Il numero non è verificabile indipendentemente dalle fonti disponibili, ma la diffusione del server web — usato come reverse proxy, load balancer, ingress controller in Kubernetes — rende plausibile un ordine di grandezza multimillionario.

Le versioni affette di NGINX Open Source spaziano dalla 0.6.27 alla 1.30.0; le correzioni arrivano nella 1.30.1 e nella 1.31.0. F5 ha esplicitamente dichiarato che le versioni dalla 0.6.27 alla 0.9.7 non riceveranno fix. NGINX Plus è vulnerabile dalle release R32 a R36; le patch sono R32 P6 e R36 P4. Contemporaneamente, F5 ha corretto altre tre vulnerabilità: CVE-2026-42946 (CVSS 8.3), CVE-2026-40701 (CVSS 6.3) e CVE-2026-42934 (CVSS 6.3).

Secondo il NVD, il CVSS ufficiale di CVE-2026-42945 è 8.1 HIGH con vettore CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H. Rod Trent riporta invece CVSS 9.2. La discrepanza non è risolta nel dossier; entrambi i numeri sono attribuiti alle rispettive fonti. La fonte italiana ilsoftware.it corrobota il meccanismo heap overflow con analisi tecnica aggiuntiva, confermando versioni e tempistiche.

Fragnesia: corrompere la page cache del kernel per diventare root

Parallelamente alla Rift, il ricercatore William Bowling ha pubblicato Fragnesia: un exploit locale per il kernel Linux che sfrutta il sottosistema XFRM ESP-in-TCP, coinvolgendo i moduli esp4, esp6 e rxrpc. Il percorso è insolito. L'exploit manipola la gestione dei socket buffer tramite skb_try_coalesce() e le primitive di splicing per corrompere la page cache di file leggibili dall'utente non privilegiato — come /usr/bin/su o /etc/passwd.

Una volta corrotto il contenuto della page cache, Fragnesia chaina a privilegi di root tramite decryption AES-GCM in-place sui fragment di page cache spliced. Il PoC è pubblico su GitHub. Le patch sono in rollout su AlmaLinux, Fedora e Ubuntu, ma il dossier non specifica versioni kernel esatte né timeline definitive. Il CVE non è menzionato nelle fonti disponibili; il CVSS non è riportato.

La minaccia è massima in ambienti multi-tenant cloud e container, dove l'isolamento dei privilegi è il confine di sicurezza fondamentale. Un container breakout via Fragnesia comprometterebbe l'intero nodo. Rod Trent cita "Microsoft and others" tra chi raccomanda mitigazioni, ma il dossier non identifica advisory specifici di Microsoft.

Cosa fare adesso

Verificare la presenza di direttive rewrite seguite da set/rewrite/if con catture PCRE e carattere ? nella stringa di replacement: questa configurazione attiva la superficie di attacco di NGINX Rift
Aggiornare a NGINX Open Source 1.30.1 o 1.31.0, oppure a NGINX Plus R32 P6 / R36 P4, entro la finestra di patching prioritaria; le versioni 0.6.27-0.9.7 richiedono migrazione forzata
Per Fragnesia, monitorare il rollout delle patch del kernel Linux sulla propria distribuzione e verificare lo stato dei moduli esp4, esp6, rxrpc; dove applicabile, valutare la disabilitazione dei moduli non necessari
Audire l'uso di AI-assisted code review nel ciclo di sviluppo: la discovery di quattro vulnerabilità in un singolo caricamento sorgente da parte di DepthFirst AI indica che la competizione offensiva-difensiva si è spostata sulla velocità di analisi automatizzata

Perché l'AI sta ridisegnando il calendario del rischio

La vera novità non è la gravità singola di Rift o Fragnesia, entrambe falle documentate con patch disponibili. È il pattern sistemico: due vulnerabilità long-lived in codice maturo — il kernel Linux, NGINX — scoperte nel medesimo intervallo con metodologie assistite da intelligenza artificiale. DepthFirst AI ha trovato quattro bug di corruzione memoria caricando una volta il sorgente NGINX. Il tempo di incubazione, quella finestra in cui un bug esiste senza essere individuato, si è accorciato drasticamente.

Per chi gestisce infrastruttura, questo significa che il modello di rischio basato sulla "vecchiaia" del codice perde validità predittiva. Codice che ha resistito a decenni di audit umano può essere rivelato vulnerabile in settimane da strumenti automatici. Il patching prioritario deve quindi ridefinirsi: non più gerarchia per anzianità del software, ma per criticità del footprint esposto e velocità di movimento dell'attaccante. La doppia frattura di maggio 2026 è un campanello d'allarme, non un'eccezione.

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

Fonti

Fonti e riferimenti