Le 14 mai 2026, l'équipe nginx a divulgué CVE-2026-42945, baptisée NGINX Rift. Une faille de type heap buffer overflow dans le module ngx_http_rewrite_module, notée CVSS 9.2, exploitable sans authentification. Deux jours après la publication d'un proof-of-concept, des tentatives d'exploitation ont été détectées in-the-wild. Si vous opérez des serveurs nginx en production, vous devez agir maintenant.
Cet article s'adresse aux développeurs, ops et décideurs techniques qui veulent comprendre ce qui se passe réellement — et savoir quoi faire.
Qui est concerné
La vulnérabilité touche :
- NGINX Open Source versions 0.6.27 jusqu'à 1.30.0 incluse
- NGINX Plus versions R32 à R36 incluses
En clair : pratiquement toutes les installations nginx déployées avant fin mai 2026 sont potentiellement exposées. nginx est l'un des serveurs web les plus utilisés au monde — on parle de millions de serveurs.
Le risque réel varie selon votre configuration. Les serveurs qui ne comportent aucune directive rewrite avec captures anonymes ($1, $2) ne sont pas exploitables pour du RCE. Mais le DoS (crash du worker process) reste faisable sur des configurations standards. Et dans tous les cas, la présence de la faille dans le binaire suffit à justifier le patch.
Ce qui se passe techniquement
Le module vulnérable
ngx_http_rewrite_module est le composant nginx qui gère les règles de réécriture d'URL. C'est l'un des modules les plus utilisés — presque toutes les configurations nginx non triviales y ont recours pour rediriger des URLs, nettoyer des query strings ou router vers des scripts backend.
Le pattern vulnérable
La faille se déclenche quand trois conditions sont réunies simultanément dans la configuration :
- Une directive
rewriteutilise une capture anonyme —$1,$2(et non une capture nommée comme(?P<name>...)). - La chaîne de remplacement contient un point d'interrogation
?(séparateur de query string). - Une autre directive (
rewrite,if, ouset) suit dans le même bloc de configuration.
Exemple de configuration vulnérable :
location /app {
rewrite ^/app/(.*)$ /index.php?route=$1 last;
rewrite ^/old/(.*)$ /new/$1 break;
}
Ce pattern est courant sur des applications PHP, des migrations d'URL legacy, ou des configurations PrestaShop et Symfony mal nettoyées après une refonte.
Ce qui se passe en mémoire
Quand un attaquant envoie une requête avec une URI spécialement forgée, nginx alloue un buffer trop petit pour stocker la chaîne reconstruite après substitution. L'écriture déborde sur des zones adjacentes du heap du worker process.
Le résultat immédiat est un crash du worker (DoS fiable). Avec ASLR désactivé ou contournable, l'attaquant peut contrôler précisément ce qui est écrit et où — c'est la porte vers l'exécution de code arbitraire (RCE).
L'attaque est unauthenticated : elle ne nécessite qu'un accès réseau au serveur et la capacité d'envoyer des requêtes HTTP. Pas de session, pas de compte, pas de token.
Ce que ça coûte en production
Un crash de worker nginx entraîne une indisponibilité partielle ou totale du service selon le nombre de workers configurés. nginx redémarre automatiquement ses workers, mais pendant l'intervalle — quelques secondes à plusieurs dizaines de secondes selon la configuration — les requêtes entrantes ne sont pas traitées.
Sur des serveurs à fort trafic, un attaquant peut enchaîner les requêtes pour maintenir les workers en état de crash permanent. C'est une attaque DoS ciblée, difficile à distinguer du trafic légitime au niveau réseau, et particulièrement efficace contre des applications sans load balancer devant nginx.
Dans les cas où l'ASLR est désactivé — ce qui arrive encore sur certains serveurs configurés manuellement ou sur des images cloud anciennes — le risque passe au RCE non authentifié. C'est le scénario catastrophe : accès complet au serveur, exfiltration de données, persistance, pivot vers d'autres systèmes du réseau interne.
Pour un site e-commerce, une application métier ou un ERP exposé sur le web, les conséquences d'un RCE sont celles d'une compromission totale. Les exploitations in-the-wild ont démarré le 16 mai 2026 — les attaquants n'ont pas attendu que les équipes ops aient le temps de patcher.
Actions immédiates
1. Patcher nginx
C'est la seule solution définitive. Les packages patchés sont disponibles sur les principales distributions :
Ubuntu / Debian :
sudo apt update && sudo apt upgrade nginx
nginx -v # doit afficher nginx/1.30.1 ou supérieur
AlmaLinux / RHEL :
sudo dnf update nginx
nginx -v
nginx Plus : mettre à jour vers R37 via le dépôt F5.
Redémarrez nginx après la mise à jour :
sudo systemctl restart nginx
2. Mitigation sans patch immédiat
Si vous ne pouvez pas patcher immédiatement (environnement bloqué, fenêtre de maintenance en attente), la mitigation consiste à remplacer toutes les captures anonymes par des captures nommées dans vos règles rewrite.
Avant (vulnérable) :
rewrite ^/blog/(.*)$ /index.php?slug=$1 last;
Après (mitigé) :
rewrite ^/blog/(?P<slug>.*)$ /index.php?slug=${slug} last;
Cette modification élimine le vecteur d'exploitation sans impacter le comportement fonctionnel des rewrites. Auditez l'intégralité de vos fichiers de configuration : nginx.conf, fichiers de vhosts, et tout fichier inclus via include.
grep -r '\$[0-9]' /etc/nginx/
Chaque occurrence de $1, $2, etc. dans un bloc avec une autre directive rewrite, if ou set est une ligne à corriger.
3. Vérifier l'état de l'ASLR
cat /proc/sys/kernel/randomize_va_space
La valeur doit être 2 (randomisation complète). Si elle est à 0 ou 1, corrigez immédiatement :
echo 2 | sudo tee /proc/sys/kernel/randomize_va_space
# Pour rendre permanent :
echo "kernel.randomize_va_space = 2" | sudo tee -a /etc/sysctl.conf
sudo sysctl -p
4. Surveiller vos logs
Recherchez des patterns de requêtes avec des URIs contenant des séquences inhabituelles : ? répétés, $, chemins bruteforcés à haute fréquence. Ce sont les signatures les plus courantes des scanners automatisés qui testent la vulnérabilité.
Si vous utilisez un WAF (Cloudflare, Nginx App Protect, ModSecurity), des règles spécifiques à CVE-2026-42945 ont été publiées — activez-les ou vérifiez qu'elles sont à jour.
Ce que ça révèle sur votre infrastructure
CVE-2026-42945 est une faille sérieuse, mais elle illustre un problème structurel courant : la dette de configuration nginx s'accumule silencieusement. Des règles de rewrite héritées de migrations passées, copiées depuis des tutoriels, jamais auditées depuis la mise en production. Des serveurs qui tournent depuis des années sans révision systématique de leur surface d'attaque.
Un audit technique permet d'identifier ce type de risque avant qu'une CVE ne le rende urgent. Configuration serveur, dépendances exposées, règles de sécurité applicative — c'est exactement ce qu'on passe en revue lors d'un audit infrastructure.
Si vous voulez aussi sécuriser vos pratiques de déploiement ou refondre votre stack avec une base saine, c'est le bon moment pour faire le point.
FAQ
Suis-je concerné si je n'utilise pas de directive rewrite dans nginx ?
Si votre configuration nginx ne contient aucune directive rewrite avec des captures anonymes ($1, $2), vous n'êtes pas vulnérable à l'exploitation RCE. Vous restez cependant exposé à un DoS sur certaines configurations. Patcher reste la seule façon d'éliminer le risque complètement.
Le patch est-il disponible pour ma distribution Linux ?
Oui pour Ubuntu, Debian et AlmaLinux — les packages nginx patchés ont été publiés dans les jours suivant la divulgation. Sur Ubuntu : sudo apt update && sudo apt upgrade nginx. Vérifiez que vous êtes sur une version ≥ 1.30.1 (open source) ou ≥ R37 (nginx Plus).
Qu'est-ce que l'ASLR et pourquoi est-ce critique ici ?
L'ASLR (Address Space Layout Randomization) est une protection du noyau Linux qui randomise les adresses mémoire à chaque démarrage de processus. Sans ASLR, un attaquant qui corrompt le heap peut prédire les adresses mémoire et passer d'un simple crash (DoS) à une exécution de code à distance (RCE). Vérifiez avec : cat /proc/sys/kernel/randomize_va_space — la valeur doit être 2.