NGINX : trois failles critiques corrigées hors cycle

Ce qui se passe

F5 a publié le 14 octobre, hors de son calendrier habituel, une série d'avis corrigeant onze vulnérabilités de NGINX, dont trois notées 9,2 en CVSS v4.0 et qualifiées de critiques. CVE-2026-15176, la plus commentée, est un débordement de tas déclenché par des requêtes HTTP fabriquées lorsque la configuration marie la directive alias, une réécriture d'URL et la variable $request_filename : le processus de travail plante, et l'exécution de code devient possible quand la randomisation de l'espace d'adressage (ASLR) est désactivée ou contournée. Les deux soeurs, CVE-2026-93479 (débordement via les captures regex de la directive map) et CVE-2026-97205 (libération d'un objet encore référencé dans les entrées/sorties asynchrones), suivent le même schéma : exploitation sans identifiants, déni de service garanti, exécution selon la configuration. Les correctifs des distributions continuent de sortir au moment où nous écrivons, le 5 novembre pour Ubuntu avec USN-8955-2. F5 ne signale pas d'exploitation dans la nature à la date de ses avis.

Pourquoi c'est grave pour un hôtel

NGINX sert de porte d'entrée à une large part des moteurs de réservation, microsites et passerelles d'API du secteur, souvent administrée par un prestataire et rarement patchée en direct. Un plantage du processus de travail, c'est la page de réservation qui tombe en pleine haute saison ; l'exécution de code sur le serveur web, c'est la fenêtre directe sur le tiroir-caisse en ligne : injection de skimming sur le formulaire de paiement, vol des cookies de session du personnel. Le plan de données est seul touché, pas la console d'administration, mais c'est précisément le plan que les clients traversent.

Qui est concerné

NGINX Open Source 1.30.5 et antérieur et 1.31.0 à 1.31.6, NGINX Plus R33 à R37, Ingress Controller 5.6.0 à 5.6.3, Gateway Fabric et Instance Manager dans les plages listées par F5. L'exposition dépend de la configuration : la directive alias combinée à $request_filename, des captures regex anonymes dans map, ou les entrées/sorties asynchrones et le SSI activés. Beaucoup de déploiements standard n'emploient pas ces motifs. La bonne démarche est donc un inventaire : demander à l'intégrateur ou sortir de la machine hébergeante la version exacte de NGINX et les blocs de configuration concernés, établissement par établissement.

Comment corriger

1. Inventorier les serveurs NGINX du parc, y compris microsites et moteurs de réservation hébergés chez un prestataire, avec la version exacte (nginx -v) et le canal d'administration des mises à jour.
2. Mettre à niveau vers 1.30.6 ou 1.31.7 pour NGINX Open Source, ou les versions de correction indiquées dans les avis K000162416, K000162607 et K000162608 pour NGINX Plus et les produits dérivés ; pour les paquets système, appliquer les avis de la distribution, par exemple USN-8955-2 pour Ubuntu.
3. Faute de fenêtre immédiate, appliquer les mesures conservatoires : retirer l'usage de la directive alias et de la variable $request_filename, basculer les captures regex anonymes en captures nommées, désactiver les entrées/sorties asynchrones et le SSI quand le site ne s'en sert pas.
4. Vérifier après mise à jour que les processus repartent normalement et que le journal ne montre plus d'erreurs de segmentation du processus de travail.

Contexte

Trois semaines après les avis d'origine, la vague de backports des distributions rappelle la règle du genre : la faille est publique, correctifs et analyses le sont aussi, et l'horloge de l'attaquant tourne plus vite que le calendrier de maintenance des microsites. Le secteur a déjà vu des serveurs web hôteliers rester en ligne des mois derrière un correctif disponible, jusqu'à l'incident de paiement qui déclenche l'enquête. Traitez cette fiche comme la liste de vérification qui manquait.