Per favore, aggiungi TurboLab.it alle eccezioni del tuo Ad Blocker. Siamo un progetto no-profit, e la pubblicità è indispensabile per pagare le spese.
In alternativa, puoi sostenerci con una donazione.
Rispetteremo ogni tua scelta, e potrai sempre utilizzare il sito senza limitazioni.
Diciotto anni. Tanto è rimasto nascosto un bug critico nel cuore di NGINX, uno dei web server e reverse proxy più diffusi al mondo - e certamente tra i più amati da chi gestisce un home server o un laboratorio domestico. La vulnerabilità, battezzata "NGINX Rift" e tracciata come CVE-2026-42945, consente l'esecuzione di codice remoto senza autenticazione. Un proof-of-concept funzionante è già pubblico su GitHub. Se avete un'istanza NGINX esposta su Internet - anche solo come reverse proxy per Jellyfin o Home Assistant - questo articolo vi riguarda direttamente.
La falla risiede nel modulo ngx_http_rewrite_module, quello che gestisce la riscrittura degli URL e l'assegnazione di variabili nelle configurazioni NGINX. Introdotta con la versione 0.6.27 del 2008, ha attraversato indisturbata ogni singola release fino alla 1.30.0 compresa. Tutte le versioni di NGINX Open Source in quel range sono vulnerabili, così come NGINX Plus da R32 a R36 e una lunga lista di prodotti correlati di F5, dall'Ingress Controller al Gateway Fabric.
A scoprirla è stata la società di ricerca depthfirst, durante un audit del codice sorgente condotto nell'aprile 2026. Il sistema automatizzato di depthfirst ha individuato la vulnerabilità dopo una singola operazione di onboarding sul codice di NGINX - e lo stesso audit ha portato alla luce tre ulteriori bug di corruzione della memoria, anch'essi corretti nell'advisory pubblicato da F5 il 13 maggio 2026.
Il cuore tecnico del problema è un'incoerenza nel motore di scripting di NGINX, che utilizza un sistema a due passate per generare gli URI riscritti. La prima passata calcola la dimensione del buffer necessario. La seconda copia i dati nel buffer allocato. In teoria, le due fasi dovrebbero concordare. Non lo fanno.
La condizione scatenante è specifica ma tutt'altro che rara: una configurazione che combini una direttiva rewrite - con una stringa di sostituzione contenente un punto interrogativo (?) - con una cattura PCRE senza nome (come $1 o $2), seguita da una direttiva rewrite, if o set. Esattamente il tipo di configurazione che si trova comunemente nei setup di API gateway e reverse proxy.
Ecco dove si inceppa il meccanismo. Quando la stringa di sostituzione contiene ?, il motore principale imposta un flag interno chiamato is_args a 1. Ma la passata di calcolo della lunghezza viene eseguita su un sotto-motore azzerato, dove is_args vale 0. La prima passata restituisce quindi la lunghezza grezza della cattura, senza considerare la codifica URI. La seconda passata, invece, vede is_args = 1 e invoca ngx_escape_uri con il flag NGX_ESCAPE_ARGS, che espande ogni byte codificabile da 1 a 3 byte.
Il risultato è un classico heap buffer overflow: nel buffer vengono scritti molti più dati di quanti ne siano stati allocati. E il dettaglio cruciale è che i byte in eccesso derivano dall'URI inviato dall'attaccante. La corruzione del heap non è casuale - è controllata.
Il proof-of-concept pubblicato da depthfirst dimostra come trasformare questo overflow in esecuzione remota di codice. La tecnica è sofisticata e sfrutta l'architettura deterministica multi-processo di NGINX. L'exploit utilizza quella che i ricercatori definiscono una sorta di heap feng shui tra richieste diverse: manipolazione del heap tramite richieste HTTP, seguita dallo spraying di strutture di pulizia fasulle attraverso il corpo di richieste POST - dato che i byte dell'URI non possono contenere null byte.
In concreto, l'overflow corrompe il puntatore cleanup di una struttura ngx_pool_t adiacente, redirezionandolo verso una struttura ngx_pool_cleanup_s fasulla che, alla distruzione del pool di memoria, invoca system() con comandi scelti dall'attaccante. L'esecuzione di codice remoto è stata dimostrata su Ubuntu 24.04.3 LTS con ASLR disabilitato.
Con ASLR attivo, l'exploit nella sua forma attuale non raggiunge la piena esecuzione di codice, ma il buffer overflow resta perfettamente riproducibile. Il risultato pratico è un ciclo di crash del processo worker: una condizione di denial-of-service che degrada la disponibilità di tutti i siti serviti dall'istanza NGINX colpita. Zero autenticazione, zero accesso pregresso, zero sessioni attive. Basta la raggiungibilità HTTP del server.
Come ha sintetizzato depthfirst: «Un attaccante che riesce a raggiungere un server NGINX vulnerabile via HTTP può inviare una singola richiesta che provoca un overflow del heap nel processo worker e ottiene l'esecuzione di codice remoto».
La combinazione di direttive rewrite e set è un pattern comune nelle configurazioni di API gateway - esattamente il tipo di setup che si trova in moltissimi home server dove NGINX fa da reverse proxy verso applicazioni interne. Se avete configurato NGINX per instradare il traffico verso diversi servizi in base al percorso dell'URL, con riscrittura e variabili, la probabilità di avere una configurazione vulnerabile non è trascurabile.
Il punteggio CVSS v4 di 9.2 (critico) riflette la gravità della situazione: attacco remoto, nessun requisito di autenticazione, impatto completo su confidenzialità, integrità e disponibilità. Con un proof-of-concept già pubblico, la finestra temporale tra divulgazione e sfruttamento attivo si misura in giorni, non settimane.
» Leggi anche: Come installare NGINX su Ubuntu - La Guida Definitiva per configurare un Server Web con Linux (video)
L'advisory di F5 non si limita a CVE-2026-42945. Lo stesso ciclo di patch corregge tre ulteriori vulnerabilità scoperte durante l'audit di depthfirst:
ngx_http_scgi_module e ngx_http_uwsgi_module. Un attaccante remoto non autenticato, in posizione di man-in-the-middle, potrebbe leggere la memoria del processo worker o forzarne il riavvio.ngx_http_ssl_module, sfruttabile quando sono attive la verifica del certificato client e OCSP. Permette modifiche limitate ai dati o il riavvio del processo.ngx_http_charset_module, che può portare a divulgazione di contenuti in memoria o riavvio del processo NGINX.La remediation è chiara: aggiornare a NGINX Open Source 1.30.1 o 1.31.0. Per chi utilizza NGINX Plus, le patch sono disponibili nelle versioni R32 P6 e R36 P4. Chi ancora esegue versioni nella fascia 0.6.27-0.9.7 non riceverà alcuna correzione: l'unica strada è la migrazione a un ramo supportato.
Per chi non può aggiornare immediatamente, vale la pena fare un audit delle proprie configurazioni alla ricerca di combinazioni di direttive rewrite e set (o if) con stringhe di sostituzione contenenti ? e catture PCRE senza nome. Dove possibile, un ulteriore livello WAF davanti alle istanze NGINX esposte può ridurre la superficie d'attacco.
L'advisory completo di F5 è consultabile all'indirizzo my.f5.com/manage/s/article/K000160932.
Un bug che ha sonnecchiato per diciotto anni nel codice di uno dei componenti più critici dell'infrastruttura web globale - e quando qualcuno lo ha trovato, aveva già un exploit funzionante da mostrare al mondo. La longevità di un progetto open source non è sinonimo di sicurezza. E un reverse proxy esposto su Internet merita la stessa attenzione riservata a qualsiasi altro servizio in prima linea.
Nessuno ha ancora commentato.
