Vulnérabilité RCE de 18 ans dans nginx (CVE-2026-42945)

Le 13 mai, une vulnérabilité a été corrigée dans le serveur web nginx, populaire pour les systèmes chargés : CVE-2026-42945, qui pourrait potentiellement conduire à une exécution de code à distance (RCE). La vulnérabilité est apparue il y a 18 ans (en 2008) dans la version 0.6.27.

Pour l'exploiter, une certaine combinaison de directives doit être définie dans la configuration du serveur ; ce n'est pas quelque chose que tout le monde a, mais cela peut exister par endroits, par exemple :
rewrite ^(.*) /new?c=1;
set $myvar $1;
return 200 $myvar;

Détails importants :

• la directive rewrite est d'abord exécutée, où (le premier argument) une expression régulière avec un paramètre capturé (quelque chose entre parenthèses) est remplacée par (le deuxième argument) un chemin contenant un point d'interrogation ;
• la directive set (un second rewrite ou if conviendrait également), qui utilise le paramètre capturé du chemin réécrit (dans ce cas, c'est $1).

La vulnérabilité fonctionne ainsi :

• la première directive rewrite, en rencontrant un point d'interrogation, définit un drapeau interne is_args, signifiant « nous sommes en train de collecter des paramètres GET pour l'URL réécrite, tout doit être échappé », et (c'est là le cœur du bug) oublie de réinitialiser ce drapeau à la fin de son traitement ;
• la directive set suivante, lors de la formation de la valeur pour $myvar, applique par erreur l'is_args précédemment défini, et enregistre dans my_var une valeur échappée du paramètre capturé $1 ; le problème est que le tampon pour $myvar est alloué plus tôt, avant même l'exécution des substitutions, et sa longueur est calculée avec is_args=0, donc la valeur échappée est plus longue que le tampon alloué, ce qui entraîne l'écriture en dehors du tampon alloué dans d'autres structures de données du serveur. Pour que cela se produise, il suffit d'envoyer une requête contenant des caractères à échapper, comme des signes « plus », au point où le paramètre de l'expression régulière est capturé.

S'il n'y a pas d'ASLR sur l'hôte, cette vulnérabilité peut être exploitée pour une exécution de code à distance avec les privilèges du processus nginx ; il existe PoC (il n'y a pas d'exploit pur, juste une démonstration dans un bac à sable).

La vulnérabilité a été corrigée dans la branche stable de nginx 1.30.1, et dans la nouvelle version de développement 1.31.0. lien vers le commit.

Il est remarquable que 14 ans auparavant (en 2012), une erreur similaire avait déjà été corrigée à un autre endroit à proximité.

——-

Sur le site de F5, il y a une recommandation pour neutraliser temporairement la vulnérabilité dans le cas où il serait impossible de mettre à jour rapidement la version de nginx — il faut remplacer les arguments non nommés par des arguments nommés, et dans ce cas, selon leurs dires, la vulnérabilité ne se manifestera pas. Exemple tiré de là :
était : rewrite ^\/users\/([0-9]+)\/profile\/(.*)$ \/profile.php?id=$1&tab=$2 last;
devenu : rewrite ^\/users\/(?[0-9]+)\/profile\/(?