# Faille Nginx Rift: CVE-2026-42945, une vulnérabilité critique dans ngx_http_rewrite_module > Point opérationnel sur CVE-2026-42945, alias Nginx Rift: versions touchées, risque réel, correctifs et mesures à prendre sur les serveurs NGINX. - URL canonique : [https://forgetaboutit.fr/blog/faille-nginx-rift-cve-2026-42945/](https://forgetaboutit.fr/blog/faille-nginx-rift-cve-2026-42945/) - Publication : 2026-05-19T10:30:00.000Z - Catégorie : Sécurité - Sujets : NGINX, Nginx Rift, CVE, CVE-2026-42945, Patch management, Cybersécurité Dans le cadre de notre **veille sécurité**, nous signalons **CVE-2026-42945**, aussi appelée **Nginx Rift**. La vulnérabilité touche **NGINX Open Source** et **NGINX Plus**, plus précisément le module **`ngx_http_rewrite_module`**. Le sujet est sérieux: le CNA F5 lui attribue un score **CVSS 4.0 de 9.2**, avec une criticité **CRITICAL**, et un score **CVSS 3.1 de 8.1**. Le point à retenir: toutes les installations NGINX ne sont pas automatiquement exploitables, mais les serveurs exposés qui utilisent certaines règles `rewrite`, `if` ou `set` doivent être qualifiés rapidement. ## Ce que l'on sait sur CVE-2026-42945 D'après le NVD, la faille apparaît dans un cas de configuration précis: une directive `rewrite` suivie d'une directive `rewrite`, `if` ou `set`, avec une capture PCRE non nommée comme `$1` ou `$2`, et une chaîne de remplacement contenant un point d'interrogation. Dans ces conditions, un attaquant non authentifié peut envoyer des requêtes HTTP spécialement construites. L'impact décrit est un **heap buffer overflow** dans le processus worker NGINX. La conséquence minimale peut déjà être opérationnellement gênante: redémarrage du worker, instabilité, déni de service partiel ou bruit d'exploitation répété. Le NVD précise aussi qu'une **exécution de code** est possible sur les systèmes où l'ASLR est désactivé. ## Pourquoi Nginx Rift doit être traité rapidement NGINX est souvent placé en frontal: reverse proxy, terminaison TLS, routage applicatif, équilibrage simple, protection d'applications internes. Une faille sur cette couche mérite donc une réaction rapide, surtout si: - le serveur est exposé sur Internet; - la configuration contient des directives `rewrite` complexes; - des captures PCRE comme `$1`, `$2` sont utilisées; - plusieurs règles `rewrite`, `if` ou `set` s'enchaînent; - l'environnement sert des applications critiques; - le serveur tourne sur une version ancienne ou hors support. Le dépôt public **Nginx-Rift** ajoute un élément important: un proof of concept existe publiquement. Cela ne signifie pas que chaque serveur NGINX est compromis, mais cela réduit la marge d'attente pour les environnements concernés. ## Versions affectées et versions corrigées Le dépôt DepthFirstDisclosures indique les plages suivantes:
Produit Versions affectées Versions corrigées
NGINX Open Source 0.6.27 à 1.30.0 1.31.0, 1.30.1
NGINX Plus R32 à R36 R36 P4, R35 P2, R32 P6
En pratique, il faut vérifier la version réellement exécutée, pas seulement le paquet attendu. Les environnements Docker, les images custom, les appliances et les reverse proxies intégrés dans une stack applicative peuvent parfois rester en retard. ## Qualification rapide sur vos serveurs NGINX Le premier objectif est de savoir si vous êtes dans le périmètre. Commencez par relever la version: ```bash nginx -v ``` Puis inspectez la configuration chargée: ```bash nginx -T ``` Cherchez en priorité les blocs qui combinent: - `rewrite`; - `if`; - `set`; - des captures PCRE non nommées comme `$1`, `$2`, `$3`; - une chaîne de remplacement qui contient `?`. Cette revue doit être faite sur la configuration effective, y compris les fichiers inclus. Un `nginx -T` est souvent plus utile qu'une recherche manuelle dossier par dossier, parce qu'il montre la configuration telle qu'elle est comprise par NGINX. ## Mesures immédiates face à Nginx Rift Si un serveur est potentiellement concerné, nous recommandons une approche courte et méthodique. 1. **Identifier les serveurs NGINX exposés** Commencer par les reverse proxies Internet, load balancers, fronts applicatifs et passerelles publiées. 2. **Vérifier la version NGINX réellement active** Comparer la version en production aux versions corrigées. Ne pas oublier les conteneurs, images internes et environnements de staging exposés. 3. **Auditer les règles `rewrite` sensibles** Chercher les enchaînements `rewrite`, `if` ou `set` avec captures PCRE non nommées et remplacement contenant `?`. 4. **Patcher vers une version corrigée** La remédiation durable reste la mise à jour vers une version corrigée ou un paquet corrigé fourni par votre distribution ou votre éditeur. 5. **Réduire l'exposition si le patch doit attendre** Si une fenêtre de maintenance est nécessaire, limiter temporairement l'accès réseau, simplifier les règles de réécriture à risque quand c'est possible, ou isoler les services les plus exposés. 6. **Surveiller après correction** Contrôler les logs d'erreur NGINX, les redémarrages de workers, les pics de 5xx et les requêtes anormales sur les emplacements utilisant des règles de réécriture. ## Ne pas confondre CVSS élevé et exposition automatique Le score critique est justifié par l'impact possible et par le fait qu'un attaquant non authentifié peut déclencher le scénario décrit. Mais l'exploitation dépend d'un alignement de conditions: version vulnérable, module concerné, règles de réécriture particulières, captures PCRE non nommées, remplacement avec `?`, et contexte mémoire favorable. La bonne réponse n'est donc ni la panique, ni l'attente. C'est une qualification rapide: - avons-nous NGINX dans le périmètre; - quelles versions tournent réellement; - quelles configurations utilisent `rewrite`; - quels fronts sont exposés; - quel plan de patch est possible aujourd'hui. ## Ce que nous faisons dans ce type d'alerte Chez Forget About IT, ce type de vulnérabilité entre directement dans le champ de l'exploitation courante: **veille CVE**, qualification de l'exposition, priorisation, patch, mitigation temporaire et contrôle post-intervention. Sur une faille comme **CVE-2026-42945**, le travail utile n'est pas seulement de lire l'alerte. Il faut la croiser avec la réalité du parc: - inventaire des serveurs et conteneurs NGINX; - versions réellement actives; - configuration effective; - exposition Internet; - criticité métier des applications derrière le reverse proxy; - capacité à patcher sans interruption excessive. C'est cette discipline qui réduit la fenêtre d'exposition sans casser inutilement la production. ## Conclusion **Nginx Rift / CVE-2026-42945** est une vulnérabilité critique à traiter sérieusement sur les environnements NGINX exposés, en particulier lorsqu'ils utilisent des règles `rewrite` avancées. Le bon réflexe est clair: - inventorier les serveurs NGINX; - vérifier les versions; - auditer les règles `rewrite`, `if` et `set`; - mettre à jour vers une version corrigée; - surveiller les workers et les logs après intervention. Si vous avez besoin d'aide pour qualifier l'exposition ou organiser la remédiation sur vos serveurs Linux, nous pouvons vous accompagner dans le cadre de notre [infogérance](/infogerance/). - [Découvrir notre offre d'infogérance](/infogerance/) - [Nous contacter](/contact/) - [Prendre rendez-vous](https://koalendar.com/e/faboutit) ## Sources - NVD - CVE-2026-42945 - DepthFirstDisclosures - Nginx-Rift ## FAQ: Nginx Rift et CVE-2026-42945 ### Qu'est-ce que CVE-2026-42945, alias Nginx Rift ? C'est une vulnérabilité critique touchant le module `ngx_http_rewrite_module` de NGINX, liée à certaines directives `rewrite`, `if` ou `set` et à l'utilisation de captures PCRE non nommées. ### La faille Nginx Rift permet-elle une attaque à distance ? Oui, le scénario décrit par le NVD implique un attaquant non authentifié envoyant des requêtes HTTP forgées, mais l'exploitation dépend de conditions de configuration précises. ### Quels sont les impacts possibles de CVE-2026-42945 ? Le NVD indique un heap buffer overflow pouvant entraîner le redémarrage d'un worker NGINX. Sur des systèmes sans ASLR, une exécution de code est également possible. ### Quelles versions corrigent Nginx Rift ? Le dépôt DepthFirstDisclosures indique des correctifs en NGINX Open Source 1.31.0 et 1.30.1, ainsi qu'en NGINX Plus R36 P4, R35 P2 et R32 P6. ### Que faut-il faire en priorité ? Identifier les serveurs NGINX exposés, vérifier l'usage des règles `rewrite` concernées, mettre à jour vers une version corrigée et surveiller les redémarrages anormaux de workers.