CVE-2026-42945 NGINX Rift : RCE sans auth après 18 ans de vulnérabilité

Les faits

Le 15 mai 2026, les chercheurs de DepthFirstDisclosures ont publié un advisory coordonné avec F5 sur CVE-2026-42945, une vulnérabilité de type heap buffer overflow localisée dans le module ngx_http_rewrite_module de NGINX. Surnommée NGINX Rift, cette faille est présente dans toutes les versions du serveur web depuis la 0.6.27, publiée en 2008 — soit 18 années de code vulnérable en production mondiale. Le score CVSS v4 attribué est de 9.2, classant cette vulnérabilité dans la catégorie critique. L'exploitation ne requiert aucune authentification et s'effectue directement via HTTP.

La condition d'exploitabilité est la présence de directives rewrite spécifiques dans la configuration NGINX. La vulnérabilité se déclenche lorsqu'une directive rewrite est suivie d'une directive rewrite, if ou set utilisant un groupe de capture PCRE non nommé — par exemple $1 ou $2 — dans une chaîne de remplacement contenant un point d'interrogation (?). Ce pattern de configuration est extrêmement courant dans les déploiements NGINX utilisés comme reverse proxy pour des applications web avec des URL canoniques (WordPress, Laravel, Symfony, Django, etc.).

Techniquement, l'exploitation provoque un débordement du tampon alloué sur le tas lors du traitement de la directive de réécriture par ngx_http_rewrite_module. Un attaquant envoie une requête HTTP spécialement forgée qui force NGINX à écrire au-delà des limites du buffer alloué, corrompant les métadonnées du tas adjacent. Selon la configuration système et les protections mémoire en place, cette corruption peut provoquer un crash du worker process NGINX (déni de service), ou permettre l'exécution de code arbitraire avec les privilèges du processus NGINX.

La chaîne RCE complète, publiée par DepthFirstDisclosures sur leur dépôt GitHub public dès le 16 mai 2026 sous le nom Nginx-Rift, inclut un module de bypass ASLR (Address Space Layout Randomization). Ce bypass combine l'overflow avec une primitive de lecture de fichier arbitraire (LFI) fréquemment présente sur les serveurs hébergeant NGINX en reverse proxy devant des applications web. La chaîne complète permet une exécution de code root-level sans authentification préalable, et les chercheurs d'Akamai ont confirmé son fonctionnement sur des systèmes Ubuntu 22.04, Debian 12 et CentOS Stream 9 dans leurs environnements de test.

L'exposition mondiale est particulièrement préoccupante. Selon les relevés Netcraft de mai 2026, NGINX est le serveur web le plus déployé au monde avec environ 34% des sites web actifs. Les versions NGINX Plus R34 et antérieures sont également affectées ; F5 a publié NGINX Plus R34 P1 comme version corrective pour les clients sous contrat. Par ailleurs, l'Ingress-NGINX Controller pour Kubernetes est affecté selon les analyses publiées par HeroDevs, étendant la surface d'attaque aux infrastructures cloud-native et aux pipelines CI/CD exposant des endpoints HTTP.

F5, éditeur de NGINX depuis son acquisition en 2019, a publié les versions correctives 1.30.1 (branche stable) et 1.31.0 (branche mainline) le 16 mai 2026, le lendemain de la divulgation coordonnée. Les patches corrigent le calcul de la longueur du buffer dans ngx_http_rewrite_module en ajoutant une vérification de borne explicite avant toute écriture dans la région de mémoire heap concernée.

Les premières tentatives d'exploitation actives ont été observées dans les honeypots d'Akamai dès le 17 mai 2026, soit 24 heures seulement après la publication du PoC. Les payloads observés à ce stade ciblent principalement le déni de service sur des instances NGINX non patchées. Cependant, les chercheurs avertissent que l'intégration de la chaîne RCE dans des frameworks d'exploitation automatisés comme Metasploit est imminente, ce qui élargira considérablement le spectre des attaquants capables d'exploiter cette vulnérabilité.

Les configurations les plus exposées combinent NGINX comme reverse proxy avec des règles de réécriture d'URL complexes — configuration standard pour les applications web utilisant des URL propres ou des routes REST. Les distributions Linux qui incluent NGINX dans leurs dépôts officiels — Ubuntu, Debian, CentOS, Alpine Linux — ont publié des mises à jour de paquets dans les 48 heures suivant la divulgation, facilitant la mise à jour sur les systèmes bien maintenus.

Impact et exposition

Le périmètre d'exposition couvre potentiellement des centaines de millions de serveurs NGINX dans le monde. Les configurations les plus vulnérables incluent : les reverse proxies NGINX avec règles rewrite pour applications PHP ou Python, les déploiements Kubernetes utilisant Ingress-NGINX Controller, les serveurs hébergeant WordPress ou autres CMS avec règles de réécriture pour URL canoniques, et les APIs REST exposées via NGINX avec des règles de routage basées sur des expressions régulières. Pour qu'une exploitation RCE soit réalisée (et non seulement un DoS), la configuration doit présenter des patterns rewrite spécifiques — mais la prévalence de ce pattern dans les déploiements réels est suffisamment élevée pour que le risque soit considéré comme généralisé.

Recommandations

• Mettre à jour immédiatement vers NGINX 1.30.1 (stable) ou 1.31.0 (mainline), ou vers NGINX Plus R34 P1 pour les clients F5 sous contrat de support.
• En cas d'impossibilité de mise à jour immédiate : auditer les fichiers nginx.conf et sites-enabled pour identifier les directives rewrite utilisant des captures PCRE ($1, $2) dans des chaînes contenant un point d'interrogation.
• Pour les déploiements Kubernetes : vérifier la version du chart Ingress-NGINX Controller et appliquer le patch de l'image Docker correspondante.
• Activer la journalisation détaillée des anomalies sur les workers NGINX et monitorer les crashes inattendus du processus worker — ils peuvent indiquer des tentatives d'exploitation en cours.
• Déployer une règle WAF temporaire bloquant les requêtes HTTP avec des séquences de réécriture malformées (les équipes Akamai et Cloudflare ont publié des signatures spécifiques à CVE-2026-42945).