Italiano

← Torna all’elenco

CVE-2026-42945: la vulnerabilità nascosta per 18 anni in Nginx — funzionamento, PoC e rimedi

itadol5j

Nginx CVE-2026-42945

🚨 CVE-2026-42945: la vulnerabilità critica nascosta per 18 anni in Nginx — funzionamento, PoC e rimedi

Il 13 maggio 2026, l'azienda di ricerca sulla sicurezza depthfirst ha divulgato insieme a F5 la vulnerabilità più grave nella storia di NGINX — CVE-2026-42945:

  • Punteggio CVSS v4.0: 9.2: rientra tra le vulnerabilità ad alta gravità
  • Buffer overflow nell'heap: può portare all'esecuzione remota di codice (RCE)
  • Nascosta per 18 anni: presente nel codebase dal 2008
  • Colpisce 9,75 milioni di siti nel mondo: oltre 2,54 milioni di siti web interessati in Cina
  • PoC reso pubblico: Qianxin lo ha già replicato con successo

Si tratta di una vulnerabilità storica del modulo centrale di NGINX: basta una singola richiesta HTTP appositamente costruita perché un attaccante prenda il controllo remoto del server.

🔍 Panoramica della vulnerabilità

Informazioni di base

Proprietà della vulnerabilità Dettagli
ID vulnerabilità CVE-2026-42945
Punteggio CVSS v4.0: 9.2 | v3.1: 8.1
Tipo di vulnerabilità Buffer overflow basato su heap (Heap-based Buffer Overflow)
Tipo di minaccia Esecuzione remota di codice (RCE), denial of service (DoS)
Condizioni di sfruttamento Nessuna autenticazione richiesta: basta costruire una richiesta HTTP
Componente interessato ngx_http_rewrite_module (modulo integrato di NGINX)
Scoperta da depthfirst (individuata dal sistema automatico in 6 ore)

Ambito di diffusione

  • 9,75 milioni di siti nel mondointeressati
  • 2,54 milioni di siti web in Cinainteressati
  • NGINX ospita circa 1/3 dei siti web mondiali, la superficie d'impatto è enorme
  • Il codice risale al 2008, per una latenza di 18 anni

⚠️ Condizioni di innesco

Le tre condizioni devono verificarsi contemporaneamente

L'innesco della vulnerabilità richiede una configurazione che soddisfi una precisa combinazione di condizioni:

Condizione Descrizione Esempio
1. Catture PCRE senza nome la direttiva rewrite usa gruppi di cattura senza nome $1, $2, $3…
2. Stringa di sostituzione con punto interrogativo la stringa di sostituzione contiene il carattere ? /profile.php?id=$1&tab=$2
3. Seguita da rewrite/if/set alla direttiva rewrite seguono subito altre direttive rewrite … last; if (…) { … }

Esempio di configurazione vulnerabile

# 易受攻击配置
rewrite ^/users/([0-9]+)/profile/(.*)$ /profile.php?id=$1&tab=$2 last;
# 后跟其他指令
if ($arg_debug) {
    set $debug_flag 1;
}

Questa configurazione soddisfa contemporaneamente le tre condizioni:catture senza nome $1/$2, stringa di sostituzione con ?, seguita dalla direttiva if.

🔬 Come funziona la vulnerabilità

Incoerenza di stato nell'elaborazione in due fasi

Il motore di scripting di NGINXutilizza un'elaborazione in due fasi:

  • Prima fase: calcolo della dimensione del buffer necessaria
  • Seconda fase: copia dei dati nel buffer

Il cuore della vulnerabilità è un errore nella gestione del flag is_args:

Fase Stato di is_args Logica di elaborazione Risultato
Fase di calcolo della lunghezza is_args = 0 restituisce la lunghezza originale della cattura sottovalutazione della dimensione del buffer
Fase di copia dei dati is_args = 1 viene chiamata ngx_escape_uri: ogni byte si espande fino a 3 byte buffer overflow nell'heap

Flusso dettagliato

  1. La direttiva rewritecontiene catture senza nome $1/$2
  2. la stringa di sostituzionecontiene ? e attiva is_args = 1
  3. Fase di calcolo della lunghezza: viene usato un sotto-motore appena inizializzato, is_args = 0
  4. restituisce la lunghezza originale: viene allocato un buffer heap troppo piccolo
  5. Fase di copia dei dati: viene usato il motore principale, is_args = 1
  6. viene chiamata ngx_escape_uri: i byte si espandono e il buffer va in overflow
  7. I dati URI controllati dall'attaccantevengono scritti nella zona di overflow

Tecnica di sfruttamento

Heap Feng Shui su più richieste:

  • Corpo delle richieste POSTper lo spray della memoria heap (l'URI non può contenere byte nulli)
  • I dati in overflowcorrompono i puntatori cleanup dell'ngx_pool_t adiacente
  • Viene falsificato ngx_pool_cleanup_s, che punta a system()
  • Alla distruzione del poolviene innescata la chiamata a system()
  • realizzando la RCE

Impatto di ASLR

  • Con ASLR attivo: si ottiene solo il crash del processo worker (DoS)
  • Con ASLR disattivo: è possibile ottenere l'esecuzione remota di codice (RCE)

📊 Versioni interessate

NGINX Open Source

Intervallo di versioni Versioni corrette
0.6.27 – 1.30.0 1.31.0, 1.30.1

NGINX Plus

Intervallo di versioni Versioni corrette
R32 – R36 R36 P4, R35 P2, R32 P6

Altri componenti interessati

  • NGINX Instance Manager: 2.16.0 – 2.21.1
  • NGINX App Protect WAF: 4.9.0 – 5.8.0
  • NGINX Ingress Controller: 3.5.0 – 5.4.1
  • NGINX Gateway Fabric: 1.3.0 – 2.5.1
  • F5 DoS for NGINX: 4.8.0

🔥 Stato del PoC

PoC reso pubblico

  • Repository GitHub:https://github.com/DepthFirstDisclosures/Nginx-Rift
  • Qianxin lo ha replicato: i ricercatori del centro di threat intelligence lo hanno replicato con successo
  • Dettagli tecnici resi pubblici: depthfirst ha pubblicato l'analisi tecnica
  • Sfruttamento in the wild: non ancora rilevato

Modalità d'uso del PoC

# 构建容器
./setup.sh

# 启动易受攻击的 NGINX 服务器
docker compose -f env/docker-compose.yml up

# 执行 PoC 获取 Shell
python3 poc.py --shell

✅ Rimedi

Metodo 1: aggiornare la versione

# 升级到修复版本
NGINX Open Source >= 1.31.0
NGINX Open Source >= 1.30.1
NGINX Plus >= R32 P6
NGINX Plus >= R36 P4

# 升级后重启 NGINX
nginx -s reload

Metodo 2: modificare la configurazione (mitigazione)

Sostituire le catture senza nome con le catture con nome:

# 易受攻击配置（未命名捕获）
rewrite ^/users/([0-9]+)/profile/(.*)$ /profile.php?id=$1&tab=$2 last;

# 修复后配置（命名捕获）
rewrite ^/users/(?[0-9]+)/profile/(?.*)$ /profile.php?id=$user_id&tab=$section last;

Le catture con nome non innescano la vulnerabilità.

Metodo 3: verificare la configurazione

Controllare la presenza di configurazioni vulnerabili:

# 搜索易受攻击的 rewrite 指令
grep -E "rewrite.*\$[0-9]+.*\?.*(rewrite|if|set)" /etc/nginx/nginx.conf
grep -rE "rewrite.*\$[0-9]+.*\?.*(rewrite|if|set)" /etc/nginx/conf.d/

🔍 Come è stata scoperta

Scoperta automatizzata

depthfirst: il sistema di analisi della sicurezza

  • in 6 oreha individuato 5 problemi
  • 4 confermati da NGINX
  • CVE-2026-42945è la vulnerabilità più grave
  • riconducibile al 2008, presente in quasi tutte le build standard

Altre vulnerabilità correlate

  • CVE-2026-42946: problema di corruzione della memoria
  • CVE-2026-40701: problema di corruzione della memoria
  • CVE-2026-42934: problema di corruzione della memoria

📝 Conclusioni

CVE-2026-42945è una delle vulnerabilità più gravi nella storia di NGINX:

  • 18 anni di latenza: il codice risale al 2008
  • CVSS 9.2: buffer overflow nell'heap, con possibile RCE
  • Condizioni di innesco: direttiva rewrite con catture senza nome + stringa di sostituzione con ? + altre direttive a seguire
  • Diffusione: 9,75 milioni di siti nel mondo, 2,54 milioni in Cina
  • PoC pubblico: repository GitHub + replica riuscita di Qianxin
  • Rimedi: aggiornare la versione o usare catture con nome

Una vulnerabilità latente da 18 anni è ormai emersa: si consiglia di aggiornare o modificare la configurazione al più presto.

Comunicato ufficiale:https://my.f5.com/manage/s/article/K000161019

Repository del PoC:https://github.com/DepthFirstDisclosures/Nginx-Rift

Analisi tecnica:https://depthfirst.com/research/nginx-rift