NGINX corrige cinq failles dont un bug TLS qui peut contourner la vérification du certificat client
Le 14 octobre 2026, NGINX publie les versions 1.30.6 et 1.31.7 pour corriger cinq vulnérabilités, dont un bug de rotation des clés de tickets TLS capable de faire sauter la vérification du certificat client. Mettez à niveau, ou au minimum retirez le cache de session TLS partagé si votre serveur repose sur l’authentification par certificat client.
14 octobre 2026. NGINX publie les versions 1.30.6 (branche stable) et 1.31.7 (mainline) pour corriger cinq vulnérabilités. Depuis mai 2005. L’une d’elles, CVE-2026-15176, est présente dans chaque version publiée depuis vingt ans. Aucune exploitation. Aucune des cinq n’est dans le catalogue KEV de la CISA au 15 octobre, et ni NGINX ni F5 ne signale d’attaque. Pourquoi c’est important : l’une de ces failles, CVE-2026-97629, peut faire sauter la vérification du certificat client — et elle se déclenche précisément avec la directive ssl_session_cache shared que la documentation de NGINX donne en exemple.
La faille qui compte : un ticket TLS forgé
Parmi les cinq, une seule mérite une attention immédiate pour les équipes qui protègent un service par certificat client — le cas classique d’une API interne, d’un accès mTLS à un backend, ou d’un portail d’administration exposé derrière une authentification mutuelle. CVE-2026-97629 touche la rotation automatique des clés de tickets de session TLS.
Un ticket de session permet à un client de reprendre une session TLS sans refaire la poignée de main complète. Depuis la version 1.23.2 (octobre 2022), un cache de session partagé — ssl_session_cache shared:SSL:10m — fait que NGINX génère et fait tourner lui-même les clés de tickets, sauf si vous les chargez depuis un fichier avec ssl_session_ticket_key. C’est exactement ce réglage que la documentation de NGINX utilise dans sa configuration d’exemple.
La mécanique du bug est une affaire de copie incomplète. Chaque worker process conserve une copie de trois emplacements de clés. La rotation n’en copiait que deux, laissant le troisième emplacement contenir ce que la mémoire gardait auparavant. Un ticket désignant cet emplacement pouvait alors être vérifié et déchiffré avec ce matériau de clé non initialisé, « permettant une session forgée », selon le commit de correction. F5 précise que la falsification fonctionne « de manière non déterministe, hors du contrôle de l’attaquant », mais qu’elle peut servir à contourner la vérification des certificats clients. Ce n’est pas un trou dans le protocole TLS lui-même : c’est une clé résiduelle que personne n’a écrite, et qui suffit pourtant à authentifier un ticket.
Le précédent est connu. NGINX avait corrigé en février 2025 une faille de réutilisation de session avec la même conséquence, CVE-2025-23419. La réapparition du même effet, par un autre chemin, signale que la rotation des clés de session est une zone sensible qui mérite d’être audité en priorité.
Trois bugs mémoire, RCE possible sous conditions
Les trois autres failles sont des corruptions mémoire. F5 les score 9,2 (Critique) en CVSS v4.0, quand NGINX les classe « moyennes » : l’écart s’explique par les conditions d’exploitation, qui exigent chaque fois une directive que vous avez ajoutée.
CVE-2026-15176 est un débordement de tas dans un worker process, présent depuis la version 0.1.29 (mai 2005). Il se déclenche quand une location combine alias avec un rewrite qui change l’URI, et que quoi que ce soit lit $request_filename dans cette fenêtre — un return, un set, un if, un add_header ou le format du journal d’accès. Si le préfixe de la location est plus long que l’URI réécrite, la correspondance vers un chemin de fichier déborde.
CVE-2026-93479 est aussi un débordement de tas, dans les captures d’une map utilisant une expression régulière. Il se manifeste quand root ou log_format référence la variable de sortie de la map avant qu’elle ne soit finalisée. C’est la faille la plus intéressante sur le plan de l’historique : elle se situe dans le code de gestion de chaînes que NGINX avait déjà patché le 15 juillet pour CVE-2026-42533, un autre débordement noté 9,2. Le correctif de juillet a ajouté une protection contre le débordement de tampon, mais des données pouvaient encore déborder dans une zone réservée, et un second correctif a ensuite dimensionné la chaîne finale à partir de cette longueur erronée. Résultat : une machine patchée en juillet est quand même dans le périmètre affecté. Le chercheur Stan Shaw avait d’ailleurs prévenu en juillet que passer aux captures nommées laissait un chemin plus étroit ouvert, et que la mise à niveau restait « la seule correction complète ».
CVE-2026-97205 est un use-after-free, déclenché quand aio est activé avec une page SSI comportant des commandes include virtual. Chaque opération asynchrone en attente incrémente un compteur de 8 bits sans contrôle : à 256 opérations en attente, le compteur revient à zéro et la requête peut être libérée alors que ces opérations pointent encore vers sa mémoire.
Le point commun des trois : ce sont des bugs réels de corruption mémoire, mais l’attaquant doit d’abord obtenir l’exécution de code dans le worker — ce qui en fait des maillons d’une chaîne d’exploitation plus qu’une faille « un paquet, root » comme le bug TLS.
La cinquième faille et les versions à connaître
CVE-2026-95101 concerne HTTP/3 : quand une trame inconnue est découpée sur deux lectures, le compteur d’octets restants est traité comme du corps de requête et transmis au backend, en contournant la limite client_max_body_size. Elle est activée par défaut avec proxy_request_buffering on. Un attaquant peut ainsi glisser des octets supplémentaires dans une requête proxyfiée. F5 la note 6,9.
Le même jour, NGINX a aussi publié njs 1.0.2, qui corrige deux failles de traitement XML de gravité moyenne dans son module JavaScript, CVE-2026-101025 et CVE-2026-101019.
La cartographie des correctifs est simple : la branche stable passe à 1.30.6, la mainline à 1.31.7. NGINX ne publie de correctifs que pour ces deux branches. Les branches plus anciennes — 1.28 par exemple — restent donc dans le périmètre affecté, et un paquet de distribution n’est corrigé que si votre distribution a backporté les patches. Les clients NGINX Plus et les utilisateurs de l’Ingress Controller, de Gateway Fabric, d’Instance Manager et du WAF de F5 doivent consulter les avis F5 : plusieurs produits n’avaient pas de build corrigé au 15 octobre.
Ce qu’il faut faire, et dans quel ordre
La mise à niveau reste la mesure première, mais l’ordre des priorités dépend de votre configuration. Commencez par identifier ce que votre serveur active réellement, avec nginx -T, puis cherchez les cinq signatures à risque.
nginx -T > /tmp/nginx-full.conf
# 1. TLS : cache de session partagé SANS clés chargées depuis un fichier
grep -nE 'ssl_session_cache\s+shared' /tmp/nginx-full.conf
grep -nE 'ssl_session_ticket_key' /tmp/nginx-full.conf
# 2. alias + rewrite + lecture de $request_filename
grep -nE 'alias|rewrite|\$request_filename' /tmp/nginx-full.conf
# 3. aio + SSI
grep -nE '\baio\b|\bssi\b' /tmp/nginx-full.conf
# 4. HTTP/3
grep -nE 'listen.*quic' /tmp/nginx-full.confSi vous ne pouvez pas mettre à niveau immédiatement, F5 publie un contournement par faille : ne pas utiliser alias dans la location concernée ; utiliser des captures nommées et ne les référencer qu’à l’intérieur du bloc de la regex ; désactiver aio ou ne pas servir de pages SSI ; passer proxy_request_buffering off ; et pour le bug TLS, retirer le cache partagé ou charger les clés depuis un fichier avec ssl_session_ticket_key. Les serveurs avec ssl_session_tickets off ne sont pas affectés par CVE-2026-97629.
La priorité est claire. Si vous utilisez l’authentification par certificat client — mTLS, API interne, portail admin — traitez le bug TLS comme une urgence même sans preuve d’exploitation : la conséquence, un contournement silencieux du contrôle d’accès, est trop grave pour attendre le prochain cycle de maintenance. Rappelons que le débordement du module rewrite corrigé en mai, CVE-2026-42945, était exploité quelques jours après sa divulgation, selon VulnCheck. NGINX en est déjà à sa huitième publication de sécurité de l’année 2026.
Verdict
La charge de travail réelle tient dans une seule question : votre configuration utilise-t-elle ssl_session_cache shared sans ssl_session_ticket_key ? Si oui, et que vous faites du certificat client, mettez à niveau vers 1.30.6 ou 1.31.7 dès que possible, ou retirez immédiatement le cache partagé en attendant — c’est la faille qui peut contourner votre contrôle d’accès sans laisser de trace réseau évidente. Si votre parc est standard — reverse proxy HTTP/2 sans SSI, sans aio, sans ces combinaisons de directives — les trois bugs mémoire restent des risques théoriques à corriger au prochain cycle, mais sans caractère d’urgence. Dans tous les cas, lancez nginx -T et vérifiez les cinq signatures : le correctif de juillet pour la faille map n’a pas suffi, et une machine « déjà patchée » peut toujours être dans le périmètre affecté.