RCE di 18 anni in nginx (CVE-2026-42945)

Il 13 maggio è stata corretta una vulnerabilità nel popolare server web nginx, utilizzato in sistemi ad alto carico: CVE-2026-42945, che potrebbe portare a RCE. La vulnerabilità è emersa 18 anni fa (nel 2008) nella versione 0.6.27.

Per sfruttarla, nella configurazione del server deve essere presente una determinata combinazione di direttive, non necessariamente presente in tutti, ma presente sporadicamente; ad esempio:
rewrite ^(.*) /new?c=1;
set $myvar $1;
return 200 $myvar;

Dettagli significativi:

• inizia con la direttiva rewrite, dove (il primo argomento) l'espressione regolare con il parametro catturato (qualcosa tra parentesi) viene sostituita con (il secondo argomento) un percorso che contiene un punto interrogativo;
• la direttiva set (anche un secondo rewrite o if funzionerebbe), che utilizza il parametro catturato dal percorso riscritto (in questo caso è $1).

La vulnerabilità funziona così:

• la prima direttiva rewrite, individuando il punto interrogativo, imposta un flag interno is_args, che indica "stiamo raccogliendo i parametri get per l'url sostituito, bisogna tutto escappare", e (qui sta il problema) dimentica di resettare questo flag alla fine del suo lavoro;
• la successiva direttiva set, nel formare il valore per $myvar, applica erroneamente is_args impostato in precedenza e registra in my_var il valore escappato del parametro catturato $1; il problema è che il buffer per $myvar viene allocato prima, ancora prima dell'esecuzione delle sostituzioni, e la sua lunghezza è calcolata con is_args=0, ovvero il valore escappato risulta più lungo del buffer allocato, causando scritture al di fuori del buffer allocato in altre strutture di dati del server. Affinchè ciò accada, è sufficiente inviare una richiesta con caratteri da escapare, ad esempio segni “più”, nel punto in cui si cattura il parametro dell'espressione regolare.

Se sull'host non è presente l'ASLR, questa vulnerabilità può essere sfruttata per un'esecuzione remota di codice con i privilegi del processo di nginx, c'è PoC (non c'è un exploit in senso stretto, ma una dimostrazione in un sandbox).

La vulnerabilità è stata corretta nella versione stabile di nginx 1.30.1 e nella nuova versione di sviluppo 1.31.0. link al commit.

È interessante notare che 14 anni fa (nel 2012), un errore simile è stato già corretto in un'altra parte.

——-

Sul sito F5 è disponibile una raccomandazione per la neutralizzazione temporanea della vulnerabilità nel caso in cui non sia possibile aggiornare rapidamente la versione di nginx: è necessario sostituire i parametri non nominati con parametri nominati e, in questo caso, secondo loro, la vulnerabilità non si manifesterà. Ecco un esempio da lì:
era: rewrite ^/users/([0-9]+)/profile/(.*)$ /profile.php?id=$1&tab=$2 last;
diventa: rewrite ^/users/(?[0-9]+)/profile/(?