NGINX Rift: il bug rimasto nascosto 18 anni che porta all'esecuzione di codice da remoto

Una porzione enorme del traffico Web mondiale passa ogni giorno attraverso NGINX. Server web, CDN, reverse proxy, piattaforme SaaS, API gateway, cluster Kubernetes: il software ideato nel 2004 da Igor Sysoev occupa una posizione centrale nell’infrastruttura Internet. Proprio per questo la pubblicazione della vulnerabilità CVE-2026-42945, ribattezzata NGINX Rift, ha subito attirato l’attenzione della comunità di sicurezza. Il problema riguarda un heap buffer overflow presente nel modulo ngx_http_rewrite_module, introdotto nel codice di NGINX addirittura nel 2008 e rimasto invisibile addirittura per quasi 18 anni.

La vulnerabilità non si limita a provocare un crash del worker di NGI: in configurazioni specifiche può portare all’esecuzione di codice da remoto senza autenticazione. La gravità tecnica del problema è ancora maggiore perché la vulnerabilità interessa componenti delle configurazioni NGINX utilizzati da anni in modo molto diffuso, come le direttive rewrite, le variabili di cattura PCRE usate per elaborare le espressioni regolari e la gestione dei parametri presenti negli URI.

Secondo F5, risultano vulnerabili le versioni open source dalla 0.6.27 alla 1.30.0, mentre le release corrette sono la 1.30.1 e la nuova 1.31.0. Anche NGINX Plus riceve patch dedicate per le release R32-R36.

Perché il modulo rewrite di NGINX è così delicato

Chi amministra NGINX sa bene quanto il motore rewrite sia potente. Le direttive rewrite, set e if permettono manipolazioni avanzate dell’URI, riscrittura di parametri query, redirect interni e logica condizionale. A sovrintendere il funzionamento vi è un interprete interno piuttosto sofisticato, costruito negli anni per privilegiare velocità ed efficienza.

La vulnerabilità si trova nel motore di scripting interno usato durante l’elaborazione delle regole di rewrite. NGINX adotta un meccanismo a due passaggi: nella prima fase calcola la dimensione del buffer necessario; nella seconda copia materialmente i dati nel buffer heap allocato.

I ricercatori di DepthFirst AI spiegano che con una particolare modalità di gestione delle espressioni regolari abbinata a una stringa di sostituzione che contiene il carattere ?, utilizzato per indicare l’inizio dei parametri in un URL, può verificarsi una situazione anomala. Alcuni caratteri speciali, cioè, possono occupare fino a tre byte invece di uno: di conseguenza la memoria allocata risulta insufficiente rispetto alla quantità reale di dati copiati. Tale comportamento può causare un heap overflow, cioè una scrittura di dati oltre i limiti della memoria allocata dinamicamente, sfruttabile tramite URI appositamente creati per attivare la vulnerabilità.

Dall’overflow all’esecuzione del codice dannoso

Molti heap overflow terminano con un crash e poco altro, soprattutto in ambienti Linux recenti. NGINX Rift però mostra caratteristiche che rendono lo sfruttamento della vulnerabilità in questione decisamente più critico.

Il proof of concept pubblicato dai ricercatori utilizza una tecnica che modella progressivamente la disposizione degli oggetti heap attraverso richieste HTTP multiple fino a posizionare strutture critiche accanto al buffer vulnerabile. La struttura presa di mira è ngx_pool_t, il “nocciolo” dell’allocator memory pool di NGINX.

È opportuno evidenziare che la sfruttabilità reale dipende molto dalla specifica configurazione del sistema. Con ASLR attivo, porre in essere una condizione RCE (remote code execution) affidabile diventa più complesso.

Alcuni vendor, tra cui AlmaLinux, sottolineano infatti che il crash del worker è facilmente riproducibile mentre l’esecuzione arbitraria di codice da remoto richiede condizioni aggiuntive.

Un punto delicato sono i container: molte immagini Docker continuano a distribuire release NGINX non aggiornate, spesso integrate in appliance software o stack applicativi che gli amministratori non aggiornano frequentemente. Negli ambienti Kubernetes la situazione può complicarsi ulteriormente: ingress controller personalizzati e configurazioni generate automaticamente possono nascondere direttive rewrite vulnerabili senza che il team operativo se ne accorga immediatamente.

Patch, mitigazioni e verifiche operative

Come accennato in precedenza, la correzione ufficiale arriva nelle versioni NGINX 1.31.0 e 1.30.1. Per NGINX Plus, F5 distribuisce fix nelle release R36 P4, R35 P2 e R32 P6.

Chi gestisce infrastrutture esposte pubblicamente dovrebbe verificare immediatamente la versione tramite il comando nginx -v.

Conviene poi analizzare le configurazioni alla ricerca di direttive rewrite che utilizzano capture anonime come $1, $2 e replacement string con query arguments.

Chi usa distribuzioni enterprise deve inoltre verificare eventuali backport dei vendor: AlmaLinux, ad esempio, ha rilasciato rapidamente pacchetti aggiornati adattando le patch upstream anche a versioni NGINX precedenti rispetto alla 1.31.0.

Vale la pena controllare anche appliance di terze parti, WAF integrati e ingress controller basati su NGINX: in diversi casi il componente vulnerabile non appare immediatamente visibile perché incluso come dipendenza interna.

Un bug nato nel 2008 che racconta molto sul software infrastrutturale

Le vulnerabilità “longeve” non rappresentano una novità assoluta. Heartbleed, Shellshock e vari bug nel kernel Linux hanno mostrato in passato quanto codice apparentemente consolidato possa restare vulnerabile per anni.

NGINX Rift però colpisce per almeno due motivi. Primo: interessa uno dei server Web più diffusi al mondo. Secondo: il bug nasce da una discrepanza logica molto sottile tra due passaggi interni del motore rewrite.

Il fatto è che vulnerabilità simili sfuggono facilmente sia alla review manuale sia ai normali test funzionali. Servono analisi profonde dei percorsi di memoria e delle condizioni di stato interne.

Il team di DepthFirst dichiara di aver individuato automaticamente quattro vulnerabilità di corruzione della memoria in NGINX (oltre a CVE-2026-42945 ci sono CVE-2026-42946, CVE-2026-40701 e CVE-2026-42934) dopo aver caricato una sola volta il codice sorgente all’interno del proprio sistema di analisi basato su AI. Non ci troviamo più dinanzi al fuzzing tradizionale o all’analisi statica classica; qui entra in gioco un approccio automatizzato capace di seguire flussi di memoria complessi e condizioni multi-step difficili da intercettare con strumenti convenzionali.

Quindi se è vero che da un lato i sistemi basati su AI producono molto rumore e segnalazioni di vulnerabilità di sicurezza che alla fine non si rivelano tali, è altrettanto vero che – nell’insieme di informazioni restituite – fanno emergere anche falle critiche, spesso rimaste nascoste ad anni di verifiche da parte di occhi esperti.