Cinq failles de sécurité de NGINX ont été corrigées, mais l’exposition dépend des configurations des serveurs. Trois vulnérabilités de corruption mémoire pourraient permettre l’exécution de code à distance dans certaines conditions.
F5 a publié des correctifs le 14 octobre 2026 pour corriger les failles mémoire, ainsi que des vulnérabilités d’injection de requêtes HTTP/3 et de falsification de sessions TLS. Les mises à jour sont disponibles dans les versions 1.30.6 et 1.31.7 de NGINX Open Source, avec des correctifs correspondants pour les produits d’entreprise concernés.
Les administrateurs qui gèrent des serveurs web, des reverse proxies et des infrastructures Kubernetes doivent vérifier les versions installées et les fonctionnalités activées. L’exposition dépendante de la configuration complique également la correction des récentes vulnérabilités d’authentification de NetScaler, pour lesquelles les déploiements concernés nécessitent davantage qu’une simple vérification de la version logicielle.
Les cinq failles de NGINX et les configurations concernées
Les avis de sécurité de NGINX classent les cinq vulnérabilités comme présentant une gravité moyenne. F5 attribue toutefois aux trois failles de corruption mémoire un score CVSS v4.0 critique de 9,2.
| CVE | Vulnérabilité | Configuration concernée |
|---|---|---|
| CVE-2026-15176 | Dépassement de tampon sur le tas | alias et rewrite avec certaines utilisations de $request_filename |
| CVE-2026-93479 | Dépassement de tampon sur le tas | Références de capture d’expressions régulières prématuréesmap ou certaines expressions de variables non mises en cache |
| CVE-2026-97205 | Utilisation après libération | E/S de fichiers asynchrones avec inclusions virtuelles SSI |
| CVE-2026-95101 | Injection du corps des requêtes HTTP/3 | HTTP/3 avec mise en mémoire tampon concernée des requêtes proxy |
| CVE-2026-97629 | Falsification de session TLS | Cache partagé de sessions TLS avec rotation automatique des clés de ticket |
Les trois vulnérabilités de corruption mémoire pourraient provoquer le plantage des processus workers de NGINX. Une exécution de code à distance pourrait également être possible si l’Address Space Layout Randomization (ASLR) est désactivé ou contourné.
L’avis technique de F5 identifie la alias, rewrite, ainsi que la $request_filename combinaison à l’origine de CVE-2026-15176. CVE-2026-93479 implique une évaluation prématurée des variables, tandis que CVE-2026-97205 concerne des E/S asynchrones combinées à Server Side Includes (SSI) utilisant des inclusions virtuelles.
Les autres vulnérabilités affectent le traitement des requêtes et l’authentification. CVE-2026-95101 pourrait transmettre des données non prévues du corps d’une requête aux applications backend, tandis que CVE-2026-97629 pourrait permettre la falsification de sessions TLS et le contournement de la vérification des certificats clients dans certaines conditions non déterministes. Aucune exploitation confirmée publiquement de ces cinq vulnérabilités n’a été identifiée dans les sources examinées au 20 octobre 2026.
Corriger les failles et réduire l’exposition de NGINX
Les administrateurs doivent mettre à niveau NGINX Open Source vers la version stable 1.30.6 ou la version mainline 1.31.7. Les clients de NGINX Plus doivent suivre les consignes de correction propres au produit, tandis que les opérateurs Kubernetes doivent déployer NGINX Ingress Controller 5.7.0 ou la mise à jour appropriée prise en charge à long terme.
Les équipes de sécurité doivent donner la priorité aux installations exposées sur Internet et prendre les mesures suivantes :
- Corriger et vérifier les installations : Appliquez les correctifs pris en charge, confirmez les versions avec
nginx -v, et recherchez les correctifs rétroportés. Des mises à jour de sécurité auparavant inefficaces soulignent l’importance de vérifier la correction. - Auditer les configurations vulnérables : Utilisez
nginx -Tpour inspecter les paramètres pertinentsalias,rewrite,map, AIO, SSI, HTTP/3 et du cache de sessions TLS. - Appliquer des mesures d’atténuation temporaires : Lorsque cela est approprié, désactivez HTTP/3 ou les fonctionnalités SSI/AIO inutilisées, examinez les paramètres des tickets TLS et corrigez les combinaisons vulnérables de directives.
- Restreindre l’accès aux systèmes backend : Limitez les connexions des serveurs applicatifs aux proxies autorisés et aux réseaux de confiance.
- Surveiller les activités suspectes : Examinez les plantages inattendus de workers, les activités inhabituelles liées au corps des requêtes et les anomalies d’authentification TLS. L’exploitation récente d’une faille RCE de WordPress illustre également l’intérêt de rechercher une compromission après l’application des correctifs.
- Tester les plans de réponse aux incidents : Validez l’escalade, la préservation des éléments de preuve, les procédures de retour en arrière et la restauration des services.
Les modifications de configuration doivent être testées avant leur déploiement en production. L’application des correctifs reste la principale mesure corrective, suivie de la vérification du bon fonctionnement des services concernés et des mécanismes d’authentification.
À lire aussi : Citrix a corrigé une faille RCE critique de NetScaler touchant des configurations SAML spécifiques, autre exemple de l’importance d’associer les vérifications de version à une évaluation des configurations.