CVE-2026-42945, surnommée Nginx RIFT par ses découvreurs, est un dépassement de tampon dans ngx_http_rewrite_module. Le défaut existe depuis Nginx 0.6.27 et peut être déclenché à distance lorsqu’une configuration utilise une séquence particulière de directives rewrite et set avec des données contrôlées par le client.
L’équipe de recherche depthfirst a démontré une exécution de code avec l’ASLR désactivé. Cette preuve établit que la corruption mémoire est exploitable dans un environnement préparé, mais elle ne démontre pas une exécution de code fiable sur toute installation Nginx moderne.
Nginx classe la vulnérabilité au niveau medium. Les versions 0.6.27 à 1.30.0 sont affectées. Les branches 1.30.1 et 1.31.0 ont introduit le correctif.
Mise à jour du 28 août 2026 : la première version de cet article évaluait trop largement le risque comme élevé pour les reverse proxies, homelabs et ingress Kubernetes. La priorité dépend d’abord de la version et de la présence du chemin
rewrite/setvulnérable. La qualification amont est medium.
En bref#
- Vulnérabilité distante, mais dépendante de la configuration.
- Composant concerné :
ngx_http_rewrite_module. - Versions affectées : Nginx 0.6.27 à 1.30.0.
- Première version corrigée de la branche stable : 1.30.1.
- Première version corrigée de la branche mainline : 1.31.0.
- Un PoC public provoque la corruption mémoire et une démonstration de RCE existe avec l’ASLR désactivé.
- Un WAF ou Cloudflare ne corrige pas le processus Nginx vulnérable.
- Les paquets des distributions peuvent contenir un rétroportage sans reprendre le numéro de version amont.
Explication technique#
Le module rewrite compile les directives rewrite et set dans un petit moteur de script. Lors de l’exécution, Nginx effectue une première passe pour calculer la taille du résultat, puis une seconde pour copier les données.
Dans la séquence vulnérable, l’état is_args, qui indique le traitement de la partie arguments d’une URI, n’est pas propagé de la même manière entre les deux passes. La première sous-estime alors la taille nécessaire. La seconde applique l’échappement URI, où certains octets occupent trois caractères, et écrit au-delà du tampon alloué sur le tas.
Le chercheur montre qu’une disposition contrôlée des allocations peut conduire à l’écrasement d’un pointeur de nettoyage d’un pool Nginx. Dans sa démonstration de RCE, l’ASLR est désactivé afin de rendre les adresses prévisibles.
Cette nuance est importante :
- la corruption mémoire à distance est établie ;
- l’exécution de code a été démontrée dans un environnement préparé ;
- l’exploitation fiable avec les protections mémoire habituelles demande des conditions supplémentaires.
Impact réel#
Reverse proxy public avec configuration atteignable#
Un Nginx exposé à Internet mérite une mise à jour rapide si sa version est affectée et si des données de requête peuvent atteindre la séquence de rewrite vulnérable. C’est le scénario prioritaire, car l’attaquant n’a pas besoin d’un compte local.
L’exposition du port 443 ne suffit cependant pas à conclure que le chemin vulnérable existe. Un serveur statique sans les directives concernées n’a pas la même surface.
Nginx interne#
Un service accessible uniquement depuis un réseau maîtrisé réduit la probabilité d’exploitation, pas l’impact d’une corruption mémoire. Il faut le mettre à jour dans le cycle normal de maintenance et vérifier si des applications internes non fiables peuvent lui envoyer des requêtes.
Docker et Kubernetes#
Un conteneur n’annule pas la vulnérabilité. Il peut toutefois limiter les conséquences selon l’utilisateur du processus, les capacités Linux, les volumes montés et les droits du service account.
Pour ingress-nginx, le numéro de version du contrôleur ne correspond pas directement au numéro de Nginx embarqué. Il faut examiner l’image réellement déployée et les avis du projet ingress-nginx, puis mettre à jour le contrôleur par son mécanisme normal.
Origine derrière un CDN ou un WAF#
Restreindre l’origine aux seules adresses du CDN réduit les chemins directs vers le serveur. Cela ne constitue pas un correctif : les requêtes transmises atteignent toujours Nginx et aucune règle générique de WAF ne garantit le blocage de toutes les formes exploitables.
Vérifier son exposition#
Version et paquet#
Afficher la version du binaire :
nginx -vSur Debian ou Ubuntu, relever aussi la version du paquet et sa provenance :
dpkg-query -W -f='${Package}\t${Version}\n' nginx nginx-common 2>/dev/null
apt-cache policy nginxNe pas conclure à partir du seul nginx -v. Un paquet maintenu par la distribution peut intégrer le correctif par rétroportage. L’avis du fournisseur et le changelog du paquet font foi.
Configuration effective#
Afficher la configuration complète, y compris les fichiers inclus :
sudo nginx -T 2>&1 | lessRechercher les directives concernées :
sudo nginx -T 2>&1 | rg -n '^[[:space:]]*(rewrite|set)[[:space:]]'Cette recherche produit un inventaire, pas une preuve de vulnérabilité. Le chemin précis dépend de l’enchaînement des directives, de l’utilisation de captures et des données fournies dans l’URI.
Conteneur Docker#
Identifier l’image, puis interroger le binaire dans le conteneur :
docker inspect --format '{{.Config.Image}}' <conteneur>
docker exec <conteneur> nginx -vUne image nommée latest ne prouve pas que le conteneur en cours d’exécution a été recréé depuis la dernière version disponible.
Ingress Kubernetes#
Lister les images déployées dans le namespace ingress-nginx :
kubectl -n ingress-nginx get deploy \
-o jsonpath='{range .items[*].spec.template.spec.containers[*]}{.image}{"\n"}{end}'Comparer ensuite ces références avec les avis et notes de publication du contrôleur utilisé.
Détection#
Il n’existe pas de signature de log universelle pour CVE-2026-42945. Une requête peut provoquer un crash de worker, mais une tentative plus avancée ne produit pas nécessairement une ligne explicite.
Les vérifications suivantes peuvent faire apparaître des crashs ou redémarrages inhabituels :
journalctl -u nginx --since "7 days ago" --no-pager
coredumpctl list nginx 2>/dev/nullChercher notamment des signaux SIGSEGV, des sorties inattendues de workers ou des redémarrages répétés. Ces événements ont de nombreuses causes possibles. Leur absence ne permet pas d’écarter une tentative.
Ne pas lancer le PoC public contre une instance de production. Le résultat le plus probable est un crash, avec un impact direct sur la disponibilité.
Correctifs et mitigations#
Mettre à jour#
Pour CVE-2026-42945, les versions amont minimales corrigées sont 1.30.1 et 1.31.0. Depuis, Nginx a publié d’autres correctifs de sécurité. Il est donc préférable d’installer le paquet actuellement recommandé par le fournisseur plutôt que de viser uniquement ces versions minimales.
Sur Debian ou Ubuntu :
sudo apt update
apt list --upgradable 2>/dev/null | rg '^nginx'
sudo apt install --only-upgrade nginx nginx-commonL’installation peut recharger ou redémarrer Nginx selon le paquet et la distribution. Vérifier ensuite la configuration et l’état du service :
sudo nginx -t
systemctl status nginx --no-pagerPour une image de conteneur, tirer une image corrigée ne modifie pas les conteneurs existants. Il faut reconstruire ou redéployer le service, puis contrôler la version dans le nouveau conteneur.
Réduire temporairement l’exposition#
Si la mise à jour est impossible immédiatement :
- identifier les blocs utilisant
rewriteetset; - désactiver la route concernée ou remplacer la logique de rewrite si cela peut être testé ;
- restreindre l’accès réseau au service ;
- isoler le worker Nginx avec un utilisateur non privilégié et des permissions minimales.
Ces mesures réduisent le risque sans corriger le dépassement de tampon. Une modification de rewrite peut aussi changer le routage applicatif et doit passer par un test de non-régression.
Conclusion#
CVE-2026-42945 est une vraie corruption mémoire distante avec un démonstrateur public. Elle ne justifie toutefois pas de classer automatiquement chaque serveur Nginx comme exposé à une RCE triviale.
La décision opérationnelle tient en trois contrôles : version du paquet, présence de la logique rewrite/set concernée et accessibilité de cette route par une source non fiable. Quand ces conditions se cumulent, la mise à jour doit être priorisée. Dans tous les cas, utiliser le paquet corrigé du fournisseur reste plus fiable qu’une mitigation par WAF.
Sources#
Sources vérifiées le 28 août 2026 :
