Scoperta nuova grave falla in NGINX: basta una richiesta HTTP per bloccare il server

Una configurazione apparentemente innocua di NGINX può trasformarsi in un vettore di attacco remoto capace di mandare in crash i processi worker del server. Il problema riguarda in particolare NGINX JavaScript, ovvero il runtime noto anche come njs, affetto da una vulnerabilità identificata come CVE-2026-8711. Il difetto interessa il modulo ngx_http_js_module e combina due elementi sempre più usati nelle configurazioni moderne: la direttiva js_fetch_proxy e la funzione ngx.fetch().

La questione merita attenzione soprattutto perché negli ultimi anni njs è diventato uno strumento molto diffuso per autenticazioni custom, manipolazione delle richieste HTTP, routing dinamico e integrazione con API esterne. Il vantaggio è evidente: meno dipendenze esterne e minore latenza; il problema, invece, è che l’integrazione tra motore HTTP e codice JavaScript introduce superfici di attacco che fino a poco tempo fa semplicemente non esistevano nel web server.

Secondo le informazioni pubblicate da F5, il bug coinvolge le versioni njs dalla 0.9.4 alla 0.9.8; la correzione è arrivata con la release 0.9.9. L’errore produce un heap-based buffer overflow: nella maggior parte degli scenari l’effetto immediato consiste nel crash del worker NGINX e nel successivo riavvio automatico. In pratica un aggressore può generare una condizione di denial-of-service (DoS) persistente inviando richieste HTTP costruite “ad hoc”.

Come nasce il nuovo bug all’interno di NGINX

La vulnerabilità emerge quando la direttiva js_fetch_proxy utilizza variabili controllabili dal client HTTP: tra i casi tipici compaiono header come $http_x_user, $http_x_password oppure $http_authorization. Se tali variabili finiscono nella costruzione di un URL o di parametri passati a ngx.fetch(), un attaccante può manipolare il contenuto delle richieste fino a corrompere la memoria heap del worker.

Va detto però che la falla non si attiva in qualunque installazione njs; serve una configurazione precisa: il server deve usare ngx_http_js_module, deve richiamare una funzione JavaScript tramite direttive come js_content e quella funzione deve eseguire ngx.fetch() usando dati derivati da input controllati dal client.

Alcune configurazioni potrebbero consentire l’esecuzione di codice da remoto: il fattore decisivo è la presenza di ASLR, cioè Address Space Layout Randomization.

ASLR randomizza la disposizione delle aree di memoria di un processo durante l’esecuzione. Senza questa protezione un aggressore può prevedere con maggiore precisione l’indirizzo di strutture heap e funzioni critiche. In presenza di un buffer overflow heap, la prevedibilità degli indirizzi semplifica la costruzione di exploit affidabili.

Molti ambienti Linux moderni abilitano ASLR di default tramite kernel.randomize_va_space: il problema è che in alcune infrastrutture legacy, container minimali oppure appliance personalizzate, la randomizzazione risulta disattivata o limitata. In certi casi gli amministratori la riducono per esigenze di debugging o compatibilità software; una scelta che oggi può trasformare un semplice crash in un vettore di compromissione remota.

Mitigazioni consigliate e priorità operative

La misura principale resta l’aggiornamento a njs 0.9.9 o superiore. Chi utilizza repository ufficiali NGINX dovrebbe verificare immediatamente la versione installata tramite comandi come njs -v oppure controllando i pacchetti del sistema operativo.

Quando l’upgrade immediato non è possibile conviene intervenire sulle configurazioni più esposte: in particolare bisogna individuare utilizzi di js_fetch_proxy che incorporano dati provenienti da client HTTP. Header personalizzati, token, username e variabili derivate dalla richiesta meritano un audit accurato.

Una mitigazione pratica consiste nell’eliminare completamente la costruzione dinamica di URL basata sull’input dell’utente: dove non si può evitare, conviene introdurre whitelist severe, limiti di lunghezza e validazione sintattica dei parametri prima dell’uso in ngx.fetch().

Conviene inoltre verificare che ASLR sia realmente attivo: su Linux il valore raccomandato per /proc/sys/kernel/randomize_va_space è 2. Molti team danno per scontata questa impostazione; in pratica però container customizzati, immagini embedded o ambienti CI/CD possono modificarla senza che gli operatori se ne accorgano.