Faille Nginx Rift: CVE-2026-42945, une vulnérabilité critique dans ngx_http_rewrite_module

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:

nginx -v

Puis inspectez la configuration chargée:

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.

• Découvrir notre offre d’infogérance
• Nous contacter
• Prendre rendez-vous

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.