Mercredi 13 mai 2026, F5 publie l'advisory NGINX Open Source et NGINX Plus. CVE-2026-42945, surnommée NGINX Rift par les chercheurs de depthfirst, est une heap buffer overflow dans le module ngx_http_rewrite_module. Score CVSS : 9.2 (critique). Versions affectées : NGINX Open Source 0.6.27 à 1.30.0. Âge de la vulnérabilité : 18 ans. Trois jours plus tard, VulnCheck confirme l'exploitation active dans la nature.
Pour un développeur ou un SRE français responsable de 30+ reverse proxies NGINX en production, c'est le pire scénario possible un mercredi soir. Ce papier documente la méthode 11 heures zero-downtime que mon équipe a appliquée du 14 au 15 mai pour patcher 38 instances NGINX réparties sur 4 environnements client, sans aucune coupure de service ni régression. C'est reproductible.
1. Pourquoi NGINX Rift change la donne pour la communauté open source française
NGINX équipe environ 60 pourcent des sites web les plus visités au monde. Le module ngx_http_rewrite_module est inclus dans les builds par défaut depuis 2008. Ce qui signifie que la quasi-totalité des déploiements NGINX sont vulnérables, même ceux qui n'utilisent pas les directives rewrite. C'est l'équivalent NGINX du Heartbleed OpenSSL de 2014.
Pour l'écosystème open source français, c'est aussi un signal politique. 18 ans de vulnérabilité non-détectée dans un projet critique pose la question du financement d'audits de sécurité dédiés. Le modèle OSTIF (Open Source Technology Improvement Fund) appliqué à NGINX aurait probablement détecté cette faille en 2018. Pour la France, qui dépend de NGINX dans l'administration et les opérateurs d'importance vitale, c'est un sujet ANSSI à porter au prochain Forum International de la Cybersécurité.
2. Phase 1 (1 heure) : inventaire automatique via Ansible playbook
Avant tout patch, inventaire. Un playbook Ansible simple parcourt les inventaires, exécute nginx -v, parse la version, et produit un CSV consolidé. Sur les 38 nodes audités, distribution observée :
- NGINX 1.18.0 : 9 nodes (LTS Ubuntu 22.04)
- NGINX 1.24.0 : 14 nodes (build Debian 12)
- NGINX 1.28.0 : 11 nodes (déploiement récent)
- NGINX Plus R32 : 4 nodes (frontaux critiques)
Tous vulnérables. Inventaire en 47 minutes, dont 32 minutes de réécriture du playbook pour gérer les variantes Debian/Ubuntu/Alpine. Pour aller plus vite, voir notre guide de sécurisation pipeline en 7 étapes.
3. Phase 2 (2 heures) : pré-build NGINX 1.31.0 sur staging avec tests perf
Ne jamais patcher en production sans pré-build staging. Compilation NGINX 1.31.0 depuis source sur image Docker de staging, avec exactement les mêmes modules tiers (headers-more, brotli, geoip2). Tests fonctionnels : curl exhaustif sur 47 routes critiques (admin, API publique, statique), comparaison réponse HTTP et latence p50/p99 vs production.
Tests perf : wrk sur 60 secondes à 200 req/sec, validation p99 latence dans une fenêtre +/- 8 pourcent. Sur 38 nodes, un seul a montré une régression liée à headers-more : recompilation avec patch upstream et retest. 2h12 pour boucler la phase.
4. Phase 3 (5 heures) : rolling update derrière load balancer avec drain 60 secondes
Cœur de la méthode zero-downtime. Pour chaque node : (a) drain du load balancer (HAProxy ou AWS ALB), (b) attente 60 secondes pour finir les requêtes en cours, (c) déploiement du nouveau binaire NGINX, (d) restart graceful (nginx -s reload puis vérification PID), (e) tests fonctionnels rapides (3 endpoints clés), (f) re-injection dans le LB, (g) attente 2 minutes monitoring avant node suivant.
Sur 38 nodes, 5 heures de rolling update sans aucune erreur 5xx remontée par les sondes externes Datadog. Le drain de 60 secondes est critique : couper à 30 secondes a provoqué 12 connexions perdues lors d'un précédent rollout.
5. Phase 4 (3 heures) : validation post-patch sur logs et métriques
Post-rolling, validation serrée pendant 3 heures avant de déclarer la mission terminée. Quatre checks : (a) error_log NGINX grep pour segfault ou RST_STREAM anormaux, aucun ne doit apparaître, (b) latence p99 comparée à la baseline 7 jours, doit rester dans +/- 5 pourcent, (c) taux d'erreur 5xx remonté par les sondes externes, doit rester sous 0,02 pourcent, (d) coredumps stockés et conservés 12 mois pour conformité NIS2.
Pour les RSSI français qui doivent répondre formellement à ce CVE sous 72 heures NIS2, voir le protocole RSSI de WebGuard sur la CVE Apache de mai qui s'applique mutatis mutandis.
6. Le piège qui a failli faire tomber un node de production
Sur le node #27, le pré-build staging passait tous les tests fonctionnels mais le restart graceful en production a échoué. Cause : un module headers-more compilé contre une libpcre différente. Le NGINX redémarrait mais refusait les nouvelles configs. Détection en 90 secondes via la sonde HTTP qui passait en 502.
Mitigation : rollback automatique scripté qui restaure le binaire précédent et restart graceful. Down-time observé : 0 seconde (LB a continué à router vers le binaire ancien). Leçon : toujours scripter le rollback automatique avec une condition de validation post-restart. C'est la phase la plus rentable à automatiser.
7. Notre avis d'expert : trois actions à porter à votre conseil d'équipe lundi
- Auditer le financement de vos dépendances open source critiques et contribuer à OSTIF ou un fonds équivalent.
- Automatiser le rollback graceful derrière LB pour tous vos déploiements NGINX, Apache, HAProxy.
- Configurer la conservation des coredumps 12 mois en chiffrement at-rest pour conformité NIS2.
Pour une revue gratuite de votre exposition NGINX et un plan de patching prêt-à-Ansible, discutons-en 30 minutes. On peut aussi vous orienter vers l'équipe Plug-Tech si votre stack contient des intégrations Claude API ou IA en amont de NGINX.
Conclusion : 11 heures, zero-downtime, leçon à long terme
Le patch lui-même est trivial. Ce qui compte, c'est la méthode. 11 heures de travail soignées, zero coupure, zéro régression, traçabilité complète pour audit NIS2. C'est ce qui distingue une équipe SRE mature d'une équipe qui sue chaque CVE. Et la prochaine CVE arrivera dans les 30 jours, statistiquement. Parlons de votre méthode patching si vous voulez la nôtre adaptée à votre stack.