Nginx RIFT (CVE-2026-42945) : comprendre la faille vieille de 18 ans

La CVE-2026-42945, surnommée Nginx RIFT, touche le module ngx_http_rewrite_module de Nginx, un composant historique introduit en 2008.

Selon les chercheurs à l’origine de la découverte, la vulnérabilité peut mener, dans certaines conditions, à une corruption mémoire exploitable pouvant aller jusqu’à une exécution de code arbitraire (RCE). Un PoC public est déjà disponible, ce qui réduit rapidement le coût d’entrée pour tester l’exploitation.

Comme souvent, le risque réel dépend surtout du contexte : exposition réseau, configuration Nginx et version déployée.

Un bug de presque deux décennies. Le contexte compte plus que le score CVSS.

Ce qu’il faut vraiment comprendre sur cette faille

#

Nginx utilise un moteur de script pour les directives rewrite et set. Il travaille en deux passes : une pour calculer la taille des buffers nécessaires, une pour copier les données.

Dans cette CVE, le premier calcul voit un flag is_args à 0 car il s’opère sur un sous-moteur zéré. La deuxième passe voit ce même flag à 1, ce qui active ngx_escape_uri avec NGX_ESCAPE_ARGS. Chaque caractère escapable devient 3 octets.

Le buffer est donc sous-dimensionné. C’est un overflow classique, pas une magie noire.

L’exploit utilise du “feng shui” heap : en envoyant plusieurs requêtes, l’attaquant corrompt un pointeur cleanup d’un ngx_pool_t adjacent. La destruction du pool redirige vers du code malveillant.

Pourquoi ce bug a-t-il survécu ?

1. Nginx privilégie la légèreté, les corrections de sécurité ne reprennent pas toujours tous les changements
2. Le code de gestion des rewrites est vieux et complexe, les corrections sont rares
3. Le support longue durée maintient des versions vulnérables pour les environnements spécifiques

Un bug de 2008 qui survive jusqu’en 2026, c’est rare. C’est inquiétant, mais compréhensible.

Qui est réellement concerné ?

#

Reverse proxy public

#

Risque : Élevé

Votre reverse proxy est la première ligne de défense. Il est exposé à l’internet et traite toutes les requêtes. Si Nginx est vulnérable, un attaquant peut exécuter du code arbitraire sur votre serveur.

Ce qui compte :

• Exposition à l’internet via port 80/443
• Utilisation de rewrite ou set directives
• Version Nginx 0.6.27 – 1.30.0 (Open Source)

Action : Upgrade immédiat vers une version corrigée.

Kubernetes ingress-nginx

#

Risque : Élevé

L’Ingress Controller agit comme point d’entrée réseau. Sur un cluster exposé, il doit être patché.

Ce qui compte :

• Images et manifests ingress-nginx non patchés
• Exposition au réseau public
• Versions du package obsolètes

Action :

kubectl get ingress -A
kubectl describe ingress

Vérifiez les versions. Redéployez avec des images patchées.

Docker

#

Risque : Moyen

Sur un homelab ou un VPS, le risque est réel mais limité. Sur une infrastructure partagée ou critique, mieux vaut patcher.

Ce qui compte :

• Image nginx obsolète dans un container
• Exposition via ports host
• Permissions du container

Action :

docker ps
docker inspect <container> | grep nginx

Redémarrez avec une image récente.

Homelab / VPS personnel

#

Risque : Élevé

Sur un homelab, c’est votre lab. Si vous exposez des services à l’internet, un exploit réussi est possible.

Ce qui compte :

• Exposition directe à l’internet
• Versions vulnérables de Nginx
• Services accessibles depuis l’extérieur

Action : Upgrade immédiat. Sur un VPS personnel, c’est votre responsabilité.

Derrière Cloudflare

#

Risque : Variable

Cloudflare ajoute une couche de protection, mais Nginx reste vulnérable. Le risque réel dépend de la configuration :

Origin directement exposée publiquement :

• Cloudflare agit comme reverse proxy
• L’IP origin est directement joignable publiquement (sans restriction aux IP Cloudflare)
• Un attaquant peut contourner Cloudflare et viser directement votre infrastructure

Origin verrouillée (IPs Cloudflare uniquement) :

• Cloudflare protège l’IP de l’origine
• Seuls les serveurs Cloudflare accèdent à votre backend
• Les attaques ciblent Cloudflare, pas directement votre infrastructure
• WAF peut bloquer certaines attaques, mais Nginx reste vulnérable

WAF ≠ mitigation complète :

• Un WAF filtre certaines requêtes malformées
• Mais le bug exploite une limite interne de Nginx
• Le WAF ne corrige pas le buffer overflow

Action : Upgrade quand même, Cloudflare réduit le risque mais ne le supprime pas.

Services internes

#

Risque : Faible

Si votre serveur est derrière un NAT, sans accès public, l’exposition est faible.

Ce qui compte :

• Pas d’accès public
• Réseau interne uniquement
• Services backend uniquement

Action : Mettre à jour quand même, bonne pratique.

Vérifier rapidement son exposition

#

Version Nginx

#

nginx -v

Sortie typique : nginx version: nginx/1.24.0. Comparez avec la liste des versions vulnérables (jusqu’à 1.30.0).

Configuration complète

#

nginx -T

Affiche toute la configuration. Cherchez les rewrite ou set directives, surtout celles avec ? dans le remplacement.

Grep pour configs vulnérables

#

grep -RHnE 'rewrite[[:space:]]+[^;]+\$[1-9][^;]*\?|rewrite[[:space:]]+[^;]+\?[^;]*\$[1-9]' /etc/nginx/ 2>/dev/null

Liste les directives de rewrite dont le remplacement contient ? et une capture $N.

Version système

#

apt policy nginx

Sur Debian/Ubuntu, cela montre la version installée et les mises à jour disponibles.

Docker

#

docker ps
docker inspect <container> | grep nginx

Vérifiez l’image nginx utilisée et sa version dans le container.

Kubernetes

#

kubectl get ingress -A
kubectl describe ingress

Affiche les ingress et leurs configurations. Vérifiez les déploiements d’ingress-nginx.

Logs

#

journalctl -u nginx -n 50
tail -f /var/log/nginx/error.log

Vérifiez les erreurs récentes ou tentatives d’exploitation.

Mitigation

#

Upgrade

#

C’est la seule mitigation efficace.

Debian/Ubuntu :

apt update && apt upgrade nginx nginx-common

RHEL/CentOS :

yum update nginx --skip-broken

Monitoring

#

watch -n 5 'grep -i "error\|alert\|critical" /var/log/nginx/error.log'

Surveillez les anomalies.

Conclusion

#

Comme souvent avec ce type de vulnérabilité, le score CVSS ne raconte qu’une partie de l’histoire.

Un reverse proxy Nginx exposé à Internet mérite probablement un patch rapide, surtout avec un PoC public déjà disponible. À l’inverse, un Nginx interne non exposé ne demande pas forcément une intervention d’urgence.

Le vrai sujet reste le même : savoir ce que vous exposez réellement, où, et avec quel niveau de visibilité.

Sources :

• F5 Advisory K000161019
• Nginx Security Advisories
• DepthFirstDisclosures - PoC GitHub
• it-connect
• Picus Security
• DevOps Daily
• Technical write-up depthfirst