Dix-huit ans que le bug dormait dans le code. Des milliers d'audits humains sont passés devant sans le voir. Un système d'analyse automatique a mis six heures à le débusquer.
Le serveur web le plus utilisé au monde a un problème de mémoire (au sens propre du terme). Le 13 mai 2026, F5 a publié un avis de sécurité couvrant CVE-2026-42945, un débordement de tas dans le module de réécriture d'URL de NGINX, noté 9,2 sur 10 sur l'échelle CVSS v4. Le bug a été introduit dans la version 0.6.27, sortie en 2008. Il aura survécu dix-huit ans, traversé des centaines de mises à jour et alimenté environ un tiers des sites web de la planète sans que personne ne le remarque. C'est la start-up DepthFirst, spécialisée dans l'analyse de code par intelligence artificielle, qui l'a identifié le 18 avril 2026 au cours d'une session de scan automatique de six heures.
Un débordement de tas déclenché par une simple requête HTTP
Quand NGINX traite une règle rewrite contenant un point d'interrogation dans la chaîne de remplacement, il calcule la taille du buffer de destination sous une hypothèse, puis copie les données sous une autre. Résultat : des octets contrôlés par l'attaquant débordent sur le tas du processus worker. Les pré-conditions sont précises (capture PCRE non nommée, point d'interrogation dans le remplacement, directive supplémentaire dans la même portée), mais suffisamment courantes pour toucher un parc considérable de configurations en production.
DepthFirst a publié un proof-of-concept sur GitHub, démontrant qu'une seule requête HTTP suffit pour crasher un worker NGINX (déni de service fiable). L'exécution de code à distance est théoriquement possible via un « Heap Feng Shui » inter-requêtes, mais l'équipe d'AlmaLinux a souligné que la PoC publiée ne fonctionne de manière fiable qu'avec l'ASLR désactivé. En conditions réelles, le DoS est le scénario le plus probable. Ce qui n'est pas exactement rassurant quand on parle d'un logiciel qui propulse un tiers des serveurs web mondiaux selon W3Techs et près de 47 % du top 1 000 des sites les plus visités.
Les versions correctives sont disponibles : NGINX Open Source 1.31.0 (mainline) et 1.30.1 (stable), NGINX Plus R36 P4 et R32 P6. En attendant le patch, une mitigation existe : remplacer les captures non nommées ($1, $2) par des captures nommées dans les règles de réécriture. Trois autres vulnérabilités ont été découvertes lors de la même session de scan, dont CVE-2026-42946 (allocation mémoire excessive pouvant atteindre 1 To dans les modules SCGI/UWSGI, CVSS 8.3).
Le club des failles oubliées accueille un nouveau membre
NGINX Rift rejoint une galerie qui commence à être bien fournie. PwnKit (CVE-2021-4034, 12 ans dans Polkit pkexec, découverte par Qualys en 2022), SinkClose (CVE-2023-31315, environ 20 ans dans les processeurs AMD, révélée à la DEF CON 2024 par IOActive) et la faille 0.0.0.0-day (18 ans dans Chrome, Firefox et Safari, exposée par Oligo Security en août 2024) ont toutes le même profil : un bug enfoui si profondément dans une couche logicielle fondamentale que des années d'audits successifs l'ont intégré au décor sans le questionner.
La particularité de NGINX Rift tient moins à la faille elle-même qu'à la méthode de découverte. DepthFirst décrit son outil comme un système d'analyse statique autonome alimenté par un modèle de langage, capable de scanner une base de code C/C++ de grande taille après un simple onboarding du dépôt source. Google DeepMind avait ouvert la voie fin 2024 avec Big Sleep (ex-Naptime), qui avait trouvé une vulnérabilité réelle dans SQLite. Mais c'était un cas isolé, en laboratoire. Ici, on parle de quatre CVE dans un projet open source critique, trouvées en une session commerciale de six heures. La trajectoire se dessine : 2024, les preuves de concept en labo. 2025, les outils internes des éditeurs. 2026, le premier scalp open source majeur.
Pour les hébergeurs français (OVHcloud, Scaleway, Infomaniak, Gandi), qui utilisent massivement NGINX en frontal de leurs offres mutualisées et de leurs load balancers, le message est assez limpide : patcher vers 1.31.0 ou 1.30.1 sans attendre, et vérifier les configurations de réécriture en production. AlmaLinux a poussé les correctifs dès le 14 mai pour l'ensemble de ses streams, y compris les versions en fin de vie. Les machines qui tournent encore sur des paquets NGINX non maintenus n'auront pas cette chance.
