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. Questa vulnerabilità esiste dal 2008 (versione 0.6.27), ovvero da 18 anni.
Per sfruttarla, è necessaria una specifica combinazione di direttive nella configurazione del server; non è presente ovunque, ma può apparire in certe situazioni, ad esempio:
rewrite ^(.*) /new?c=1;
set $myvar $1;
return 200 $myvar;
Dettagli significativi:
- inizialmente c'è la direttiva rewrite, dove (il primo argomento) un'espressione regolare con un parametro catturato (qualcosa tra parentesi) viene sostituita con (il secondo argomento) un percorso che contiene un punto interrogativo;
- la direttiva set (può anche essere usata un'altra rewrite o if) che utilizza il parametro catturato dal percorso riscritto (in questo caso $1).
La vulnerabilità funziona così:
- la prima direttiva rewrite, incontrando un punto interrogativo, imposta un flag interno is_args, che significa "stiamo raccogliendo parametri GET per l'URL riscritto, dobbiamo tutto eseguire l'escaping", e (questo è il cuore del bug) dimentica di resettare questo flag alla fine della sua esecuzione;
- la successiva direttiva set, durante la formulazione del valore per $myvar, applica erroneamente il precedente is_args impostato, scrivendo in my_var un valore esaminato del parametro selezionato $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, il che significa che il valore esaminato risulta più lungo del buffer allocato, causando così la scrittura al di fuori del buffer allocato in altre strutture dati del server. È sufficiente inviare una richiesta con caratteri da esaminare, come i segni «più», nel punto di allocazione del parametro dell'espressione regolare.
Se non c'è ALSR sul host, questa vulnerabilità può essere sfruttata per l'esecuzione remota di codice con i diritti del processo nginx, c'è PoC (non è un exploit in senso stretto, è una dimostrazione in 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 era già stato corretto in un altro posto nelle vicinanze.
——-
Sul sito F5 c'è 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 denominati con parametri denominati, 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;
diventato: rewrite ^/users/(?<user_id>[0-9]+)/profile/(?<section>.*)$ /profile.php?id=$user_id&tab=$section last;
Le informazioni sulla vulnerabilità sono state fornite da Zhenpeng (Leo) Lin di DepthFirst. Inoltre, ha segnalato i seguenti problemi, che sono stati anche risolti:
- CVE-2026-40701 (commit) uso-after-free durante l'uso di ssl_verify_client+ssl_ocsp (sembra senza RCE)
- CVE-2026-42934 (commit) lettura oltre il buffer nel parser utf-8 in circostanze specifiche, può portare a una piccola perdita di dati o al crash del processo di lavoro
- CVE-2026-42946 (commit) eccesso di allocazione di memoria e lettura oltre il buffer durante l'uso dei moduli scgi/uwsgi, il problema si manifesta in presenza di un backend malevolo (upstream) attraverso i protocolli indicati, o durante un attacco mitm sul canale di comunicazione con il backend, può portare alla lettura della memoria di nginx o al crash del processo di lavoro
Fonte: linux.org.ru
