NGINX : cinq failles corrigées, trois jugées critiques

Ce qui s'est passé

NGINX est la porte d'entrée d'une immense partie du web : serveur de sites, proxy inverse devant les API, répartiteur de charge, contrôleur d'entrée dans les clusters Kubernetes. Le 14 octobre 2026, nginx.org a publié les versions 1.30.6 (stable) et 1.31.7 (mainline), qui corrigent cinq vulnérabilités. Le même jour, F5, l'éditeur de NGINX, a diffusé un avis de sécurité hors calendrier couvrant NGINX Plus et ses produits dérivés, et le module njs a reçu deux correctifs séparés.

• CVE-2026-15176 (9,2) : débordement de mémoire quand alias est combiné à un rewrite qui modifie l'URI et à la variable $request_filename. Présente depuis la version 0.1.29, soit 2005.
• CVE-2026-93479 (9,2) : débordement de mémoire lors de l'évaluation d'expressions qui utilisent les captures d'une expression régulière dans un bloc map. Il s'agit d'une régression introduite par le correctif de juillet (CVE-2026-42533). Versions 1.30.0 à 1.30.5 et 1.31.2 à 1.31.6.
• CVE-2026-97205 (9,2) : use-after-free avec les inclusions SSI (include virtual) et les entrées-sorties asynchrones (aio). Un compteur interne sur 8 bits repart à zéro après 255 opérations, et une requête est libérée alors qu'elle est encore utilisée. Présente depuis la version 0.8.11.
• CVE-2026-97629 (8,3) : falsification de session TLS. Depuis la version 1.23.2 (octobre 2022), la rotation automatique des clés de tickets TLS ne copiait que deux emplacements sur trois ; le troisième contenait de la mémoire non initialisée.
• CVE-2026-95101 (6,9) : injection de données dans le corps des requêtes en HTTP/3, transmises au serveur applicatif en contournant la limite client_max_body_size. Depuis la version 1.25.0.

Les notes sont celles de F5, sur l'échelle CVSS 4.0.

Qui les a découvertes, et comment

• CVE-2026-15176 : les équipes de F5, en interne.
• CVE-2026-93479 : Matt Suiche (Tolmo) et Mateusz Gierblinski, en examinant le correctif publié en juillet.
• CVE-2026-97205 : un chercheur indépendant connu sous le pseudonyme Cyberlanc3r.
• CVE-2026-97629 : PhiNode Labs.
• CVE-2026-95101 : Hansol Lee (GOTROOT).

Ces failles arrivent dans une année chargée. En mai, « NGINX Rift » (CVE-2026-42945, module rewrite, vieille de seize ans) avait été corrigée le 13 mai puis exploitée dans la nature dès le 16, peu après la publication d'une preuve de concept. En juillet, CVE-2026-42533 touchait déjà les captures d'expressions régulières de map. Le code de NGINX n'a jamais été autant scruté, et une des failles d'octobre est née du correctif de juillet.

Comment elles se sont répandues

Au 15 octobre, ni NGINX ni F5 ne signalaient d'attaque, et les cinq CVE ne figuraient pas au catalogue des vulnérabilités exploitées de la CISA. Nous n'avons pas trouvé, depuis, de signalement d'exploitation confirmée. Le précédent de NGINX Rift rappelle pourtant que trois jours peuvent suffire.

Ce qui s'étend, c'est le périmètre touché, car le code vulnérable est embarqué partout :

• NGINX Open Source jusqu'à 1.30.5 et 1.31.6, dans les paquets des distributions et les images Docker. Les branches plus anciennes, comme 1.28, ne reçoivent pas de correctif de nginx.org : seul le rétroportage de votre distribution vous protège.
• NGINX Plus R33 à R37.
• Produits F5 dérivés : NGINX Ingress Controller 5.6.0 à 5.6.3, NGINX Gateway Fabric 1.5.0 à 1.6.2 et 2.1.0 à 2.7.2, NGINX Instance Manager 2.18.0 à 2.23.0, F5 WAF for NGINX 5.9.0 à 5.15.0, NGINX App Protect WAF, F5 DoS for NGINX. BIG-IP, BIG-IQ et F5OS ne sont pas concernés.
• Kubernetes : le contrôleur communautaire ingress-nginx n'est plus maintenu depuis mars 2026 et embarque NGINX 1.27.1. Il ne recevra pas ces correctifs. Dans sa configuration par défaut, la plupart des failles n'y sont pas atteignables, mais vos scanners les signaleront.

Pour donner un ordre de grandeur, le moteur de recherche ZoomEye recensait le 26 octobre près de 50 millions de réponses NGINX sur le port 443. C'est la surface visible, pas le nombre de serveurs vulnérables : tout dépend de la configuration.

Les risques encourus

• Déni de service. Pour les trois corruptions mémoire, l'issue la plus fiable est le plantage du processus worker. Répétée, l'attaque rend le service instable.
• Exécution de code. F5 la juge possible lorsque la protection ASLR est désactivée ou contournée et que la configuration vulnérable est présente. NGINX étant placé devant tout le reste, le compromettre revient à voir passer tout le trafic : certificats, identifiants, cookies de session.
• Contournement de l'authentification par certificat client. Avec CVE-2026-97629, une session forgée pourrait passer outre la vérification mTLS qui protège des API B2B, des back-offices ou des objets connectés. F5 précise que cette falsification n'est pas déterministe.
• Contournement de limites. En HTTP/3, des données injectées atteignent le serveur applicatif sans passer par les contrôles de taille.

« Moyenne » pour NGINX, « critique » pour F5 : qui croire ?

NGINX classe les cinq failles en sévérité moyenne, parce que la configuration par défaut n'y est pas exposée. F5, autorité de numérotation des CVE, note le pire cas plausible : un attaquant non authentifié, à distance, avec une requête préparée. Les deux lectures sont justes. Votre niveau de risque réel dépend de votre configuration, et c'est elle qu'il faut auditer.

Les correctifs disponibles

• NGINX Open Source : 1.30.6 (stable) ou 1.31.7 (mainline), ou plus récente. La 1.31.8 est sortie le 21 octobre.
• NGINX Plus : 37.1.0.1 ou 37.0.5.1.
• Produits dérivés F5 : versions corrigées indiquées dans les avis F5 K000162416, K000162607 et K000162608.
• Distributions Linux : paquets rétroportés, à vérifier dans le bulletin de sécurité de votre distribution.
• ingress-nginx communautaire : pas de correctif officiel. Planifiez la migration vers Gateway API ou un contrôleur maintenu ; des offres de maintenance étendue existent en attendant.

Comment les appliquer, étape par étape

• 1. Identifier la version : nginx -v sur chaque serveur, docker run --rm <image> nginx -v pour chaque image.
• 2. Auditer la configuration. Affichez la configuration complète et cherchez les déclencheurs : sudo nginx -T | grep -nE 'alias|request_filename|map|ssi on|aio|ssl_session_cache|ssl_session_ticket_key|quic'. Un serveur qui présente l'un d'eux passe en priorité absolue ; les autres doivent être corrigés aussi, avec un peu moins d'urgence.
• 3. Mettre à jour. Sous Debian ou Ubuntu : sudo apt update && sudo apt install --only-upgrade nginx. Sous Red Hat, Rocky ou AlmaLinux : sudo dnf upgrade nginx. Avec Docker : passez à nginx:1.30.6 ou plus récent, reconstruisez puis redéployez.
• 4. Tester puis redémarrer : sudo nginx -t && sudo systemctl restart nginx. Attention, un simple reload relit la configuration mais garde l'ancien binaire en mémoire. Pour éviter toute coupure, NGINX sait remplacer son binaire à chaud (signal USR2).
• 5. Vérifier la version en service, et que la protection ASLR est active : cat /proc/sys/kernel/randomize_va_space doit renvoyer 2.

Si vous ne pouvez pas mettre à jour tout de suite, F5 propose des contournements, faille par faille :

• CVE-2026-15176 : évitez alias dans les blocs location qui réécrivent l'URI, et n'utilisez plus $request_filename, y compris dans vos formats de journaux ;
• CVE-2026-93479 : remplacez les captures numérotées ($1, $2) par des captures nommées, utilisées uniquement dans le bloc qui contient l'expression régulière ;
• CVE-2026-97205 : aio off; ou désactivation de SSI ;
• CVE-2026-97629 : ssl_session_tickets off;, ou chargement de vos propres clés avec ssl_session_ticket_key ;
• CVE-2026-95101 : proxy_request_buffering off; pour le trafic HTTP/3, ou désactivation temporaire de HTTP/3.

Ces contournements réduisent l'exposition, ils ne la suppriment pas. Un chercheur a déjà signalé qu'une voie d'attaque plus étroite subsiste pour CVE-2026-93479. Seule la mise à jour corrige.

Ce que nous en retenons

Votre configuration est votre surface d'attaque. Pour ces failles, deux serveurs à la même version n'ont pas le même risque. Versionnez votre configuration NGINX dans Git et relisez-la comme du code.

Un correctif peut en appeler un autre. CVE-2026-93479 est née du correctif de juillet. Ce n'est pas une raison de différer les mises à jour, mais une raison de les tester et de surveiller les suivantes.

Un composant abandonné est une dette de sécurité. ingress-nginx ne sera plus corrigé : la migration n'est plus une option de confort.

NGINX est en première ligne devant vos sites et vos API ? Nous auditons sa configuration, appliquons les mises à jour sans coupure de service et accompagnons la migration de vos clusters Kubernetes vers Gateway API. Parlez-nous de votre projet.

Sources : nginx.org, F5 (avis K000162416, K000162607, K000162608), CSA Singapour, The Hacker News, BleepingComputer, HeroDevs, SecurityWeek (avis publiés du 14 au 26 octobre 2026).