Nginx Rift (CVE-2026-42945) : RCE dans le module rewrite, l'ANSSI relaie

Le CERT-FR a publié le 26 mai 2026 l'avis CERTFR-2026-AVI-0643 relayant la vulnérabilité CVE-2026-42945, baptisée NGINX Rift, dans le module ngx_http_rewrite_module de Nginx. Il s'agit d'un débordement de tas (heap buffer overflow) CVSS v4.0 9.2 — Critique (CVSS v3.1 : 8.1). F5, en tant que CNA, a publié l'avis upstream le 13 mai ; le PoC est public et VulnCheck a confirmé une exploitation dans la nature.

La faille se déclenche lorsqu'une directive rewrite est suivie d'une directive rewrite, if ou set utilisant des captures PCRE non nommées combinées à un point d'interrogation dans la chaîne de remplacement. Un attaquant non authentifié peut, dans cette configuration, provoquer le crash du worker — ou, si ASLR est désactivé sur l'hôte, exécuter du code arbitraire à distance via une requête HTTP forgée.

Versions affectées

D'après l'enregistrement CVE publié par F5 :

• NGINX Open Source : versions 0.6.27 jusqu'à 1.30.0 inclus.
• NGINX Plus R32 : antérieures à R32 P6.
• NGINX Plus R36 : antérieures à R36 P4.
• NGINX Plus R37 : non affectée.

Les correctifs disponibles sont 1.30.1 et 1.31.0 côté open source, ainsi que les patches P6 et P4 côté Plus.

Conditions d'exploitation

Deux nuances à garder en tête avant de céder à la panique :

1. La faille ne se déclenche qu'avec une configuration rewrite spécifique — captures PCRE non nommées + ? dans la cible. Une configuration sans rewrite exotique ne tombe pas dans la fenêtre d'exploit. L'audit prioritaire concerne donc les déploiements avec des règles complexes (reverse-proxy applicatifs, CDN maison, ingress controllers Kubernetes générant du Nginx à la volée).
2. L'exécution de code à distance n'est possible que si ASLR est désactivé sur l'hôte. Les distributions Linux modernes activent ASLR par défaut ; un crash worker (déni de service applicatif) reste néanmoins atteignable indépendamment d'ASLR.

Cela ne dispense pas de patcher : un worker Nginx qui tombe en boucle est un trou de disponibilité, et le PoC public de l'équipe DepthFirst place la barre d'exploitation à un niveau très bas pour les hôtes mal durcis.

Statut de l'exploitation

VulnCheck rapporte une exploitation dans la nature ; DepthFirst, qui a publié le travail de recherche et codé l'exploit, a mis à disposition une preuve de concept sur GitHub. Le CERT-FR cite ces éléments dans son avis. La fenêtre entre divulgation (13 mai) et adoption massive du patch par les opérateurs reste ouverte, ce qui en fait une cible opportuniste pour les scans de surface.

Que faire

1. Inventorier les versions de Nginx dans votre parc, y compris celles intégrées dans des distributions Kubernetes (ingress-nginx), des appliances de sécurité OEM et des images Docker baselines. La diffusion de Nginx en composant transparent est sa principale exposition.
2. Mettre à jour : 1.30.1 ou 1.31.0 pour l'open source, R32 P6 ou R36 P4 pour NGINX Plus. Côté Plus, R37 est déjà sain.
3. Mitiger sans patch immédiat : remplacer dans toute directive rewrite impactée les captures non nommées par des captures nommées. C'est le contournement officiel recommandé par F5 quand le déploiement d'une version corrigée prend du temps (homologation, fenêtre de maintenance).
4. Vérifier ASLR sur les hôtes Nginx exposés : /proc/sys/kernel/randomize_va_space doit être à 2. Si vous trouvez 0 quelque part en production, le sujet est plus large que cette CVE.
5. Surveiller les logs Nginx pour des crashs worker répétés et des requêtes HTTP malformées ciblant des chemins avec règles rewrite. Un workflow d'exploitation laisse souvent une trace de tentatives ratées avant d'atterrir.

Contexte

Nginx héberge une part importante du trafic web public, et la fenêtre d'attaque sur rewrite est précisément ce que les CDN, frontaux applicatifs et ingress controllers utilisent abondamment. Le module est aussi un point chaud connu : la quasi-totalité des CVE Nginx historiques tournent autour du parsing HTTP ou de la mécanique de rewrite/proxy. Les opérateurs qui maintiennent leurs propres règles complexes restent les plus exposés.

Au-delà du patch immédiat, la bonne pratique reste de toujours préférer les captures PCRE nommées dans les rewrite : la verbosité gagnée est compensée par la lisibilité et, comme cette CVE le montre, par une surface d'attaque plus étroite quand un bug de parser apparaît côté parser.

L'avis complet est disponible sur cert.ssi.gouv.fr. L'analyse technique d'origine est publiée par DepthFirst et le bulletin F5 sur my.f5.com.