Vulnérabilités NGINX : causes, correctifs et vérification de la production

Date historique de l’article : 2026-10-14 (date de divulgation et de publication de sécurité). Sources vérifiées et informations complétées via 2026-10-27.

Cet article est archivé par date d’événement ; les mises à jour des versions et des versions publiées après le 14 octobre sont incluses ci-dessous. Public : Site Web NGINX Open Source / NGINX Plus et personnel d’exploitation et de maintenance du proxy inverse, personnel d’intervention en matière de sécurité, responsables de la distribution, ainsi que ingénieurs qui auto-compilent NGINX et maintiennent des modules tiers.

Cet article se concentre sur les cinq vulnérabilités principales NGINX qui ont été divulguées et corrigées de manière intensive le 14 octobre 2026, et revient également sur les vulnérabilités représentatives de sécurité de la mémoire et d’intégrité des demandes de mai à septembre 2026. Le contenu couvre les conditions de déclenchement, les causes au niveau du code, la portée de l’impact, le flux de travail de correction, les mesures d’atténuation à court terme, la mise en œuvre officielle des correctifs, les rétroportages vers les anciennes branches et la vérification de la production. Les références telles que S1 renvoient à l’annexe source. Les exemples de configuration sont uniquement utilisés pour illustrer les idées de déploiement et d’audit et doivent être vérifiés en fonction de la version réelle, de l’héritage de configuration, des dépendances et de la capacité commerciale avant la mise en œuvre.

TL;DR : Actions prioritaires

1. Donnez la priorité aux mises à niveau de sécurité. Pour les packages Open Source nginx.org, mettez à jour la branche Stable 1.30 vers au moins 1.30.6 et la branche Mainline 1.31 vers au moins 1.31.7.. À la date de vérification, 1.31.8 est la dernière version de Mainline. Il s’agit de lignes de base de branche distinctes ; ne comparez pas leurs chiffres entre les succursales. S1S2
2. Vérifiez les installations de distribution par version complète du package. Ubuntu 22.04 / 24.04 / 26.04 / 26.10 ont des rétroportages de fournisseur ; Debian 13 (trixie) nécessite au moins 1.26.3-3+deb13u10. Lors de la vérification, le package Debian 12 (bookworm) 1.22.1-9+deb12u10 est toujours marqué comme étant affecté. Vérifiez chaque CVE ; l’avis Debian 13 n’établit pas que Debian 12 est corrigé. S13S14S15
3. Auditez cinq combinaisons de configuration : alias + rewrite + $request_filename, map + regex + évaluation de variable, aio + ssi + include virtual, HTTP/3 avec proxy_request_buffering on et ssl_session_cache shared:... avec rotation automatique des clés du ticket de session TLS. La présence d’une directive à elle seule n’établit pas l’exploitabilité ; évaluer le chemin de la demande et la portée de la configuration. S1S3S4
4. Remplacez tous les anciens processus et conteneurs. Exécutez nginx -t, puis redémarrez le service ou effectuez un déploiement continu à haute disponibilité. Confirmez que les anciens processus master/worker se sont terminés ; nginx -s reload à lui seul ne prouve pas que le binaire en cours d’exécution a changé.
5. Vérifiez les points de terminaison réels : HTTP/1.1, HTTP/2, HTTP/3 si activé, les téléchargements par proxy et les corps de requête API, l’authentification par certificat mTLS, les pages SSI et les journaux d’accès. Enregistrez la provenance du package, la version, le résumé de l’image, les processus en cours d’exécution et les résultats pour chaque point de terminaison.
6. Si une mise à niveau immédiate est impossible, supprimez les conditions de déclenchement applicables : désactivez les références de variables SSI/AIO ou HTTP/3 inutiles, examinez les références de variables alias/rewrite/map vulnérables et évaluez les ssl_session_tickets off; temporaires pour les services mTLS concernés. WAF, ASLR, les limites de débit et les modifications de configuration ne couvrent que certaines conditions et ne peuvent pas remplacer les correctifs officiels. S3S4S8S12

1. Aperçu de la vulnérabilité et jugement des risques

NGINX a publié 1.30.6 (Stable) et 1.31.7 (Mainline) le 14 octobre 2026, corrigeant cinq problèmes de sécurité. Trois impliquent des débordements de tas ou une utilisation après libération et ont reçu des scores F5 CVSS v4.0 de 9.2 / Critique. Les deux autres affectent l’intégrité des requêtes HTTP/3 et l’authentification du certificat client TLS. S1S2S3

Distinguez les systèmes de notation : nginx.org répertorie les cinq problèmes comme medium, tandis que F5 CVSS v4.0 et certaines agences de sécurité nationale classent les trois problèmes de mémoire comme critiques. Cela ne signifie pas que tous les cinq permettent l’exécution inconditionnelle de code à distance. La configuration, l’accessibilité du trafic et les conditions hors du contrôle d’un attaquant sont importantes. La corruption de la mémoire et le RCE fiable sont différents niveaux de preuve. S1S3S4

CVE	Problèmes techniques et conditions de déclenchement typiques	impact central	Évaluation et élimination
CVE-2026-15176	Mappage de chemin alias + modification rewrite URI + évaluation $request_filename	Débordement de tampon de tas, crash Worker ; potentiel RCE sous certaines conditions	F5 CVSS v4.0 9.2 ; prioriser le dépannage
CVE-2026-93479	Évaluation du script HTTP/Stream, en particulier la capture d’expressions régulières map et le répertoire root, référence croisée des variables de journal	Le tampon réservé est écrasé et le tas déborde ; potentiel RCE sous certaines conditions	F5 CVSS v4.0 9.2 ; il y a un risque de régression après des réparations antérieures
CVE-2026-97205	Les inclusions virtuelles SSI et le fonctionnement AIO/asynchrone ; dépassement du nombre d’opérations en suspens	Use-After-Free, crash Worker, corruption de mémoire ; potentiel RCE	F5 CVSS v4.0 9.2 ; nécessite une configuration autre que celle par défaut
CVE-2026-95101	HTTP/3 La trame inconnue est fragmentée dans les tampons, la mise en mémoire tampon du corps de la requête proxy est activée	Injection incorrecte d’octets non DATA dans le corps de la requête en amont, contournant éventuellement la limite de taille du corps de la requête	Cette vulnérabilité affecte l’intégrité des requêtes. Il ne fournit pas lui-même l’exécution de code à distance (RCE).
CVE-2026-97629	Cache de session TLS partagé, rotation automatique des clés et mise en miroir des clés Worker	Contrefaçon de ticket de séance ; Un contournement de l’authentification du certificat client peut se produire pour le service mTLS concerné.	Une attention particulière doit être accordée à l’impact commercial du type d’authentification par certificat API.

Le score CVSS ci-dessus est donné par F5 en utilisant v4.0 ; la même vulnérabilité peut présenter une gravité différente dans les propres niveaux et niveaux de gravité de distribution de CVSS 3.1, nginx.org. S1S3S4

1.1 Donner la priorité à l’exposition au déploiement plutôt qu’aux seuls scores CVE

Formulaire de déploiement	Points clés de l’enquête	Recommandations prioritaires d’élimination
Proxy inverse de réseau public, y compris rewrite personnalisé, alias et map complexe	CVE-2026-15176, CVE-2026-93479 et vulnérabilités de réécriture/cartographie de mai à juillet	P0 : Auditer et mettre à jour immédiatement
API / Plan de gestion utilisant le certificat client comme authentification unique ou d’entrée principale	Configuration du ticket de session et du cache partagé de CVE-2026-97629	P0 : confirmez immédiatement la limite d’authentification et mettez à jour
Fournir un téléchargement externe HTTP/3, une interface de changement de statut et une classe de transaction API	CVE-2026-95101, en particulier le corps de la requête est transmis par proxy au backend	P0/P1 : Organiser en fonction de l’importance commerciale
SSI Page dynamique ou E/S de fichier asynchrone	CVE-2026-97205	P1 : Confirmer les conditions de combinaison et réparer dès que possible
Uniquement pages statiques + proxy inverse simple HTTP/1.1/2	La configuration et la version doivent encore être auditées, mais certaines conditions CVE peuvent manquer	P1 : Inclus dans la fenêtre de mise à niveau de sécurité d’urgence
Utiliser la communauté Kubernetes à la retraite ingress-nginx	Le projet arrête la maintenance de la sécurité, et les risques ne se limitent pas à ces cinq CVE	Élaborer un plan de migration de contrôleur individuel

P0/P1 correspondent aux suggestions d’élimination en matière d’exploitation et de maintenance données dans cet article pour l’exposition du réseau public et la sensibilité de la certification. Il ne s’agit pas d’une classification officielle CVSS et elle ne doit pas non plus remplacer l’évaluation interne des actifs et des risques de changement de l’entreprise.

1.2 Limite d’impact et autorisations d’attaque

Les principales vulnérabilités de ce lot se situent principalement dans le plan de données NGINX : le point d’entrée de l’attaque est la connexion et la demande du client, et l’impact réel se produit généralement dans le processus Worker. Si les conditions exploitables pour la corruption de la mémoire sont remplies, l’autorisation d’exécution de code est généralement limitée par l’utilisateur en cours d’exécution, les contraintes du conteneur, la fonctionnalité Linux, les autorisations de montage et réseau du Worker ; Le potentiel RCE n’implique pas automatiquement les privilèges root ou la compromission de l’hôte. S4

Mais même si le processus n’est pas privilégié, il peut toujours avoir accès aux informations d’identification du proxy, aux fichiers lisibles contenant les clés privées de certificat, aux jetons de service en amont, aux fichiers temporaires, au API interne et aux réseaux accessibles. Pour mTLS, le contournement de l’authentification en lui-même peut avoir de graves conséquences commerciales et ne doit pas nécessairement s’accompagner de l’exécution de code.

2. Analyse des causes

2.1 Comprendre les trois limites sujettes aux erreurs dans NGINX

Un NGINX worker est un processus de longue durée piloté par les événements qui maintient l’état des demandes, les opérations asynchrones et les analyseurs de protocole. Cette vulnérabilité incarne des contraintes à trois niveaux d’ingénierie :

1. L’évaluation des variables et la taille de la mémoire doivent être cohérentes : rewrite Après avoir modifié la demande URI, le mappage de chemin doit être cohérent avec le location actuellement en vigueur ; lorsque l’interpréteur de script calcule la longueur variable, l’espace d’écriture doit couvrir la sortie réelle et les zones réservées.
2. Les opérations asynchrones doivent prolonger le cycle de vie de la mémoire demandée : lorsqu’il y a des lectures et écritures de fichiers inachevées, des tâches d’attente de cache ou de thread, le pool de mémoire de requête concerné ne peut pas être libéré à l’avance.
3. l’état du protocole et l’état de sécurité ne peuvent pas être mélangés ou omis : HTTP/3 La longueur du saut de trame inconnu ne peut pas être considérée comme la longueur du corps de la demande DATA ; TLS Tous les emplacements de clé participant à la vérification de signature doivent être correctement initialisés et synchronisés pendant la rotation des tickets de session.

Le contenu suivant est basé sur la validation du correctif en amont NGINX et l’annonce du fournisseur pour expliquer le mécanisme de défaillance qui peut être déclenché ; le fragment d’exemple est destiné à l’analyse, il ne s’agit pas du code complet qui peut être directement utilisé pour réparer l’environnement de production. S5S6S7S8S9

2.2 CVE-2026-15176 : le mappage de chemin entre alias et URI réécrit n’est pas valide.

Dans NGINX, le location correspondant et son alias déterminent le chemin du fichier ; rewrite peut modifier la demande actuelle URI. Après la réécriture, les hypothèses utilisées par le mappage location d’origine peuvent ne plus être valables.

Le chemin de traitement concerné n’a pas vérifié de manière adéquate si la demande avait été réécrite lors de la vérification du statut alias dans ngx_http_map_uri_to_path(). Lorsque la configuration continue d’évaluer $request_filename après la réécriture, le chemin peut être construit avec des hypothèses qui ne sont pas conformes à l’état actuel de URI, déclenchant éventuellement une écriture hors limites dans la mémoire tas. S5

Combinaison typique (utilisée uniquement comme contre-exemple pour l’audit de configuration, le déploiement n’est pas recommandé) :

# 仅用于识别风险模式：不是修复配置
location /foo/ {
    alias /srv/alias-root/;
    rewrite ^/foo/.*$ /new-path;
    return 200 $request_filename;
}

Le danger ne se limite pas à return : set, if, add_header, log_format, etc. doivent également être audités si l’évaluation $request_filename est déclenchée dans le même processus de demande. return dans l’exemple ne fait que rendre ce chemin d’état facile à voir ; il ne peut pas être utilisé pour déduire que toutes les configurations de production produiront des débordements. S5S10

Conséquences de l’attaque : La construction d’une requête peut entraîner le redémarrage de Worker ou une interruption du service ; dans des conditions telles que ASLR étant fermé ou pouvant être contourné, il existe un potentiel RCE. Le cœur du correctif en amont est de refuser de terminer le mappage de chemin URI réécrit dans le contexte alias qui n’est plus valide, plutôt que de simplement étendre un certain tampon. S5S10

2.3 CVE-2026-93479 : incompatibilité entre « espace réservé » et la longueur réelle de la variable dans l’évaluation du script

Les modules HTTP et Stream de NGINX disposent d’évaluateurs de script qui concatènent des chaînes littérales et des valeurs de variable dans la chaîne de résultat. Les exemples d’application incluent les chemins du document HTTP root, les chemins du journal d’accès et les expressions de variables dans Stream.

Certaines configurations d’expressions régulières map + permettent aux valeurs capturées d’être lues par d’autres expressions avant que la variable de résultat map ne soit évaluée. Combinée à la méthode d’exécution de script avec longueur réservée, l’ancienne implémentation comptera à l’avance l’espace réservé len dans l’accumulateur de longueur évaluée, de sorte que les calculs ultérieurs du pointeur d’écriture ne soient plus cohérents avec la limite du tampon. Dans une séquence d’évaluation de variable spécifique, les écritures de chaîne ultérieures peuvent écraser la zone réservée, provoquant un débordement de tas. S6

éléments participatifs	Pourquoi cela vaut la peine d’y prêter attention
expression régulière dans map	L’évaluation des variables de capture peut avoir un cycle de vie et un comportement de mise en cache indépendants
Captures anonymes telles que $1, $2, etc.	Facilement écrasé par d’autres expressions régulières ou expressions, ce qui rend difficile le suivi de la propriété
Variables dans root	Exécution de script et réservation de tampon lors du déclenchement de la création de chemin
log_format/Chemin du journal dynamique	Le même type d’évaluation peut être déclenché ultérieurement dans la demande
Expressions de script dans stream	Le correctif en amont modifie également ngx_stream_script_run(). Vous ne pouvez pas uniquement consulter le module HTTP.

Relation de régression importante : le code lié à cette vulnérabilité est lié aux modifications précédentes qui ont corrigé CVE-2026-42533. Le DSA officiel pour Debian 13 indique clairement que le code concerné a été introduit dans le package trixie via un rétroport de sécurité antérieur. Par conséquent, « Le correctif de vulnérabilité map de juillet a été installé » ne signifie pas que le correctif de vulnérabilité CVE-2026-93479 d’octobre a été couvert ; la chaîne complète des correctifs de sécurité doit être vérifiée. S6S14S17

Le risque potentiel RCE est ici lié à l’environnement de protection de la mémoire, et il ne faut pas prétendre que l’expression régulière map pourra à elle seule être exploitée par des attaquants anonymes. S11

2.4 CVE-2026-97205 : AIO Le bouclage du nombre d’opérations inachevées provoque une utilisation après libération

Cette vulnérabilité ne consiste pas simplement à « activez SSI et vous obtiendrez UAF ». La clé réside dans le décompte de références d’opérations asynchrones détenu par la requête principale.

NGINX Utilisez r->main->blocked pour suivre le traitement asynchrone qui n’est pas encore terminé. Dans l’ancienne implémentation, il s’agissait d’un nombre de 8 bits ; certains chemins n’ont pas effectué de vérification de limite supérieure avant d’incrémenter le décompte. Lorsque la même requête principale accumule 256 opérations en attente, le décompte peut passer de 255 à 0. Les processus suivants croiront à tort qu’aucune opération asynchrone n’empêche la requête d’être libérée, libérant ainsi le pool de mémoire de requête qui est toujours référencé par la tâche. S7

Le processus d’échec peut être divisé en :

1. Avec le chemin d’E/S/thread asynchrone associé activé, la page SSI introduit plusieurs sous-requêtes ou opérations de lecture via include virtual.
2. Les opérations en cours d’une certaine requête principale sont accumulées jusqu’à la limite supérieure représentée par le champ de comptage.
3. Le nombre de 8 bits s’enroule, exprimé à tort comme « aucune opération en attente ».
4. Le pool de mémoire de requête est libéré, tandis que les lectures de fichiers, les attentes de cache ou les rappels de tâches de thread en conservent toujours les références.
5. Les rappels d’achèvement asynchrones ultérieurs accèdent à la mémoire libérée, ce qui entraîne des plantages de UAF, Worker ou une corruption potentielle de la mémoire.

Le correctif officiel ajoute NGX_HTTP_MAX_BLOCKED 250 au fichier d’en-tête de requête et ajoute des restrictions au filtre de sortie, à la lecture du cache et au chemin du thread en amont ; lorsque le seuil est atteint, les opérations avec des chemins synchronisés sont terminées de manière synchrone et si elles ne peuvent pas être traitées en toute sécurité, l’ajout de tâches en attente sera refusé. S7

jugement d’applicabilité : il doit être évalué si SSI, AIO, l’inclusion virtuelle, les sous-requêtes et les opérations asynchrones associées peuvent se produire en combinaison dans la même chaîne de requêtes. Ce ne sont généralement pas les configurations de proxy statiques par défaut. aio off; ou ssi off; peuvent supprimer des éléments déclencheurs spécifiques, mais les dépendances des fonctions métier doivent d’abord être confirmées. S4S7S25

2.5 CVE-2026-95101 : la trame inconnue HTTP/3 est confondue avec l’état du corps de la demande DATA

L’analyseur de trames HTTP/3 doit faire la distinction entre les trames DATA (qui doivent être transmises au traitement du corps de la requête HTTP) et les trames inconnues qui doivent être ignorées. La longueur des trames inconnues doit également être préservée avec précision lors de la fragmentation dans les tampons réseau.

L’ancienne implémentation de ngx_http_v3_parse_data() utilisait le champ st->length pour enregistrer le « nombre restant d’octets à ignorer » lors du saut de trames inconnues, tandis que le filtre du corps de la requête interprétait le même champ comme la « longueur restante de la charge utile DATA ». Si la trame inconnue s’étend sur plusieurs appels d’analyse, le prochain lot d’octets après l’interruption de l’analyse peut être confondu avec le corps de la requête. S8

Deux types de risques se présentent :

• Injection du corps de la demande : la charge utile de la trame non DATA soumise par le client peut être transmise à l’application en amont, modifiant ainsi les données réellement reçues par le backend.
• contournements de limite de taille : client_max_body_size et autres restrictions. Les contrôles attendus sont concentrés sur le chemin DATA, et un contenu mal converti peut contourner la vérification correspondante.

Le scénario de déclenchement typique décrit par le responsable est celui où ngx_http_v3_module reçoit la demande HTTP/3 et transmet proxy_request_buffering on. La mise en mémoire tampon du corps de la demande de proxy est activée par défaut dans ngx_http_proxy_module. Par conséquent, le proxy inverse qui active HTTP/3 doit être vérifié en premier. Il n’est pas approprié de supposer qu’il n’y a pas de condition de déclenchement simplement parce que proxy_request_buffering on; n’est pas explicitement écrit. S8S18

La conséquence directe de cette vulnérabilité appartient à la modification de l’intégrité des requêtes backend et des limites de sécurité, qui n’est pas l’expression équivalente de RCE directement complétée dans le noyau NGINX. L’impact commercial final dépend de la manière dont ces octets sont analysés et approuvés en amont. S24

2.6 CVE-2026-97629 : TLS La rotation des billets manque le troisième emplacement de clé

Dans les configurations concernées, NGINX peut générer et faire pivoter automatiquement les clés de ticket de session TLS via le cache de mémoire partagée, permettant à plusieurs Worker de traiter le même lot de tickets.

La logique de synchronisation appropriée alloue 3 emplacements de clé pour chaque Worker, et le rappel de décryptage traversera également ces emplacements ; mais l’ancienne implémentation ne copie à chaque fois que 2 emplacements de clé de la mémoire partagée, ce qui donne le nom de clé, la clé HMAC et l’AES du troisième emplacement. La clé peut rester non initialisée. Si l’identifiant de clé d’un ticket correspond à ce statut, le matériel de clé non initialisé peut être utilisé pour la vérification et le déchiffrement de la signature, formant ainsi un chemin pour falsifier la session TLS. S9

Les combinaisons de déploiement à haut risque sont généralement :

# 仅为排查触发条件所示：共享缓存本身不是恶意配置
ssl_session_cache shared:SSL:10m;
# 未显式配置 ssl_session_ticket_key 文件，使用自动轮换机制

La conséquence commerciale la plus grave de cette vulnérabilité est que sur les services qui utilisent l’authentification par certificat client (mTLS) dans ssl_verify_client on; et d’autres manières, les sessions de récupération falsifiées peuvent contourner la vérification du certificat client. Le succès de l’attaque est également soumis à des conditions incontrôlables ; un site qui utilise uniquement un certificat HTTPS côté serveur normal et aucune authentification par certificat client ne doit pas être présenté à tort comme “l’attaquant peut contourner l’intégralité de la connexion au site Web”. S9S12

Il s’agit d’un problème d’état d’authentification de session TLS et n’a rien à voir avec le fait que la clé privée TLS du serveur soit piratée ou si le certificat public CA root est affecté. S24

2.7 Comment comprendre DoS, RCE, le contournement d’authentification et les exploits connus

• DoS : une erreur de mémoire provoque le crash ou le redémarrage massif de Worker. Le fait que cela provoque une indisponibilité globale est lié à la pression du trafic, à la capacité de redémarrage des processus, au temps de maintenance de la connexion et à l’architecture à haute disponibilité.
• potentiel RCE : certaines annonces indiquent qu’il existe une possibilité d’exécution de code lorsque ASLR est fermé ou contourné. Cela ne signifie pas qu’une chaîne d’attaque publique capable d’exécuter des commandes de manière stable et universelle a été divulguée. S4
• Contournement de l’injection/de l’authentification de la demande : il peut modifier directement le statut commercial protégé ou le contenu de la demande, et ne peut être ignoré simplement parce qu’il n’obtient pas directement le shell.
• a découvert des tentatives d’attaque : CVE-2026-42945 en mai 2026 a signalé des activités d’exploitation dans la nature ; Il ne faut pas déduire directement de ce fait historique que les cinq CVE d’octobre ont été exploitées avec succès à grande échelle. S23

3. Version de réparation et sélection de correctifs

Base de référence officielle du patch 3.1 NGINX Open Source

branche amont	La première version officielle couvrant cinq vulnérabilités en octobre	Recommandations à partir du 2026-10-27
Stable 1.30.x	1.30.6（2026-10-14）	Installez au moins 1.30.6 et effectuez un suivi avec les versions de sécurité ultérieures.
Mainline 1.31.x	1.31.7（2026-10-14）	1.31.8（2026-10-21）
L’ancienne branche NGINX Open Source	Il ne peut pas être jugé uniquement sur la base de “d’anciens correctifs de vulnérabilité ont été appliqués”.	Migrez d’abord vers la branche maintenue ; sinon, le fournisseur est tenu de fournir une preuve formelle de support sur une base CVE-by-CVE.

Ce sont les conclusions de la version du code source/branche officielle en amont nginx.org et ne doivent pas être utilisées pour refuser directement le package de sécurité avec les correctifs rétroportés fournis par le fournisseur de distribution. Même si la valeur de 1.31.6 est supérieure à 1.30.6, elle reste inférieure à la ligne de base du correctif de la branche principale. S1S2

3.2 Portée d’impact en amont de cinq CVE

Les plages suivantes sont répertoriées selon le texte original du bulletin de sécurité nginx.org et doivent être comprises en conjonction avec la « branche en cours d’exécution » et le « chemin de configuration réel » :

CVE	Versions concernées par les balises en amont	Version fixe officiellement étiquetée
CVE-2026-15176	0.1.29–1.31.6	1.30.6+ ou 1.31.7+, au sein de leurs succursales respectives
CVE-2026-93479	1.30.0–1.30.5，1.31.2–1.31.6	Idem que ci-dessus
CVE-2026-97205	0.8.11–1.31.6	Idem que ci-dessus
CVE-2026-95101	1.25.0–1.31.6	Idem que ci-dessus
CVE-2026-97629	1.23.2–1.31.6	Idem que ci-dessus

CVE-2026-93479 a des limites spécifiques à la version d’introduction ; Toutes les anciennes versions de NGINX ne sont pas affectées par cette régression. Les versions plus anciennes en dehors de ces plages peuvent toujours être affectées par la vulnérabilité d’expression régulière map antérieure, CVE-2026-42533. S1

3.3 Ubuntu : rétroportages de distribution (USN-8955-1)

Canonical USN-8955-1 du 26 octobre 2026 fournit une mise à jour de sécurité pour quatre versions de Ubuntu : S13

Version Ubuntu	nginx et la même version fixe du package source	Descriptif
22.04 LTS	1.18.0-6ubuntu14.22	Il s’agit d’un rétroportage de fournisseur ; le numéro de version en amont indique toujours 1.18.0
24.04 LTS	1.24.0-2ubuntu7.19	Idem que ci-dessus
26.04 LTS	1.28.3-2ubuntu1.12	Idem que ci-dessus
26.10	1.30.4-7ubuntu1.1	Idem que ci-dessus

L’annonce contient les versions corrigées correspondantes de packages homologues tels que nginx-core, nginx-extras, nginx-full et nginx-light. Ne tirez pas de conclusions sur l’opportunité de le réparer à partir de la partie en amont uniquement indiquée par nginx -v. tels que Ubuntu, 24.04 et 1.24.0-2ubuntu7.19 ont été corrigés par ce fournisseur, mais 1.24.0, quelle qu’en soit la source, n’est pas intrinsèquement sûr.

Ubuntu a également clairement indiqué que CVE-2026-95101 n’affecte que Ubuntu 26.04 / 26.10, et CVE-2026-97629 n’affecte que Ubuntu 24.04 / 26.04 / 26.10. Voici Emballage et portée fonctionnelle propres à Ubuntu, qui ne peuvent pas être directement promus vers d’autres distributions. S13

3.4 Debian : Les différences entre les versions doivent être vérifiées séparément

L’avis Debian DSA-6575-1 (2026-10-21) couvre ces cinq CVE et identifie le package nginx fixe pour Debian 13 / trixie comme :

1.26.3-3+deb13u10

Cependant, au moment de la vérification de ce rapport, 1.22.1-9+deb12u10 pour Debian 12 / bookworm est toujours signalé comme vulnérable par le système de suivi de sécurité Debian. Par conséquent :

• Debian 13 Il suffit de mettre à jour et d’accepter conformément au DSA-6575-1.
• Debian 12 doit vérifier les correctifs de sécurité fournis par le fournisseur actuel de Security Tracker ou ELTS un par un ; avant que le correctif ne soit confirmé dans l’annonce, ne déclarez pas que les cinq éléments ont été corrigés en fonction du succès de apt upgrade.
• Le package source Debian peut contenir un ensemble de correctifs indépendant du numéro de version nginx.org. Pour les versions personnalisées, vous devez vérifier l’ensemble complet de correctifs du package de code source, et vous ne pouvez pas simplement copier une seule validation en amont et la considérer comme terminée.

La distinction ci-dessus est basée sur les enregistrements de suivi DSA et CVE. S14S15S16

3.5 NGINX Plus, njs et contrôleur d’entrée

Produits/Composants	Points clés de la sélection et de la vérification des titres
NGINX Plus (version commerciale)	Veuillez vous référer à l’annonce et aux instructions de mise à niveau de la branche Plus correspondant à F5. Le dernier CR au moment de la vérification est PLS.37.2.0.1, et la version de sécurité de LTS est PLS.37.0.7.1 ; la version Plus et le backport inclus ne peuvent pas être directement remplacés par le seuil 1.30/1.31 d’Open Source. S19
njs / ngx_http_js_module	2026-10-14 publie njs 1.0.2 et corrige CVE-2026-101019 et CVE-2026-101025 ; si vous utilisez njs, vous devez également vérifier la compatibilité du module avec NGINX. S20
Contrôleur d’entrée/tissu de passerelle F5 NGINX	Le noyau NGINX est une chaîne de distribution de logiciels connexe mais indépendante. Corrigez les vulnérabilités pertinentes avec leurs contrôleurs, images et notes de version respectifs. Vous ne pouvez pas simplement remplacer un binaire NGINX dans le Pod.
Communauté Kubernetes kubernetes/ingress-nginx	Le projet est mis hors service en mars 2026 et n’assurera plus de nouvelle maintenance de sécurité. Vous devez prévoir de migrer vers un contrôleur maintenu ou Gateway API plutôt que de confondre son numéro de version avec le contrôleur d’entrée F5 NGINX. S21

3.6 Quel patch devriez-vous réellement choisir ?

Formulaire de déploiement	Pratiques recommandées	Preuve de réparation
Package officiel DEB/RPM nginx.org	Mise à niveau vers la version fixe de la branche amont	nginx -v/-V, source du package, annonce officielle de sécurité
Dépôt officiel Ubuntu/Debian	Installer les packages de sécurité du fournisseur	Version complète du package + fournisseur USN/DSA + statut CVE
RHEL/Alma/Rocky/SUSE/Autres distributions	Mise à niveau en fonction des bulletins de sécurité de distribution spécifiques et des versions de packages	CSAF/annonce du fournisseur correspondant, la version Ubuntu/Debian ne peut pas être appliquée
Images de conteneurs officielles ou personnalisées	Reconstruisez ou extrayez l’image de réparation vérifiée et remplacez-la progressivement	Résumé d’image, création de SBOM, exécution de l’ID d’image du pod/conteneur
NGINX, OpenResty, Tengine auto-compilés ou versions corrigées avec des modules tiers	Prioriser l’utilisation de la version de sécurité complète du responsable ; effectuer des rétroportages de correctifs révisés pour l’arborescence source cible si nécessaire	Cinq correctifs de vulnérabilités, compatibilité ABI/module, régression des unités et des métiers

OpenResty et Tengine sont des systèmes de version différents ; ce tableau décrit uniquement la méthode de vérification. ne signifie pas que toutes ses versions sont affectées en même temps que le standard NGINX, et que le correctif de code en amont ne peut pas non plus être appliqué sans condition.

4. Processus de réparation formel

4.1 Inventaire des instances réelles de réception de trafic externe

Rassemblez pour chaque entrée au moins :

• Nom de domaine, équilibrage de charge/CDN/lien proxy Edge, méthode d’exposition du site d’origine et protocole réseau utilisé.
• Produits NGINX (Open Source, Plus, Ingress, etc.), version complète, source du référentiel de packages, résumé d’images.
• nginx -V affiche les modules de construction et les paramètres de compilation ; s’il existe des modules dynamiques njs, Lua, OpenResty et tiers.
• PID master/worker en cours d’exécution réel, unité de service/conteneur/pod, réplique et nœud Worker.
• Les configurations http/stream, server, location, include effectives réelles.
• Qu’il s’agisse d’activer HTTP/3, mTLS, SSI/AIO, le chemin de journal dynamique, le map complexe et la capture d’expressions régulières.

Ne vous contentez pas de vérifier la valeur par défaut /etc/nginx/nginx.conf. L’environnement de production charge souvent plusieurs sites, TLS et configurations de modules via include. Il peut également exister plusieurs chemins d’installation NGINX ou plusieurs couches proxy.

4.2 Vérifier les informations de version et de compilation

# NGINX 版本及构建选项
nginx -v
nginx -V 2>&1

# Linux：查看实际运行的 NGINX 进程
ps -eo pid,ppid,user,comm,args | grep '[n]ginx'

# Debian / Ubuntu：查看完整已安装包版本、来源
apt-cache policy nginx
# 兼顾 nginx-core / nginx-full / nginx-extras 等实际已安装包
dpkg-query -W 'nginx*' 2>/dev/null

# RPM 系：以实际安装包及仓库公告为准
rpm -qa | grep '^nginx'

nginx -V signale la construction du binaire trouvé sur le chemin de la ligne de commande ; cela ne prouve pas que le worker en cours d’exécution l’a chargé. nginx -v peut omettre le suffixe complet du package de la distribution, alors vérifiez également le gestionnaire de packages ou les enregistrements de la chaîne d’approvisionnement.

4.3 Exportez la configuration effective et effectuez le premier cycle de filtrage statique

nginx -T testera la configuration et videra la configuration fusionnée. La sortie peut contenir des informations sensibles telles que des informations d’authentification, des chemins de clé, des noms d’hôte internes, etc. Il est recommandé d’enregistrer le terminal contrôlé avec les autorisations root et les autorisations de fichiers privés, et de ne pas publier les fichiers originaux sur des bons de travail publics :

sudo sh -c 'umask 077; nginx -T > /root/nginx-effective.conf 2> /root/nginx-config-check.log'

sudo grep -nE \
  'alias|rewrite|map[[:space:]]|request_filename|aio[[:space:]]|ssi[[:space:]]|quic|http3|proxy_request_buffering|ssl_session_cache|ssl_session_ticket_key|ssl_session_tickets|ssl_verify_client|log_format|root[[:space:]]' \
  /root/nginx-effective.conf

Il s’agit simplement d’un localisateur de chemin candidat, et non d’un outil de détermination automatique CVE fiable :

1. grep ne peut pas déterminer si les variables se trouvent dans le même location ou dans la même chaîne d’évaluation de demande, ni en déduire la relation d’héritage de configuration.
2. proxy_request_buffering on, certaines configurations de cache et de ticket ont des valeurs par défaut, et ne pas écrire les instructions correspondantes ne signifie pas que le risque disparaît.
3. Les configurations générées par les proxys inverses, CDN, les side-cars de conteneurs ou les contrôleurs peuvent différer des fichiers inspectés manuellement.
4. Les caractéristiques du NGINX Plus et des modules dynamiques peuvent devoir être confirmées à l’aide de leurs outils de gestion officiels respectifs.

4.4 Déployer le correctif via des canaux de confiance

Debian/Ubuntu (dépôt de distribution officiel) :

sudo apt-get update
apt-cache policy nginx

# 升级发行版仓库中已经安装的 NGINX 及相关包；
# 先确认 Candidate 属于修复版本，再执行升级。
sudo apt-get install --only-upgrade nginx

# 对实际安装的 nginx-core / nginx-full / nginx-extras 等包
# 确认它们的版本和依赖一同达到厂商修复要求。
dpkg-query -W 'nginx*' 2>/dev/null

Cet ensemble de commandes ne peut pas générer à partir de rien des correctifs de sécurité qui ne sont pas encore disponibles. Surtout pour Debian 12, si le package mis à niveau est toujours jugé vulnérable par le système de suivi de sécurité, des mesures supplémentaires de réparation, d’isolement ou de migration du fournisseur sont nécessaires. S13S14S15

Package officiel nginx.org :

# 先确认仓库来自 nginx.org、目标分支和候选版本
apt-cache policy nginx
# 经变更审批后再执行对应仓库的升级命令
sudo apt-get install --only-upgrade nginx

Si vous utilisez OpenResty, Tengine ou NGINX Plus auto-compilés, utilisez la version du correctif prise en charge par le responsable correspondant et ne mélangez pas nginx.org, la distribution et les packages de référentiel tiers. Les binaires/images, configurations, signatures et manifestes de déploiement de restauration d’origine doivent être conservés.

Conteneurs/Kubernetes : mettez à jour l’image immuable, enregistrez son résumé et remplacez toutes les anciennes répliques par un déploiement par étapes. kubectl rollout status confirme uniquement que le contrôleur de déploiement est terminé ; vérifiez également les résumés d’images, le routage d’entrée et les répliques défectueuses.

4.5 Vérifier la configuration et remplacer l’ancien Worker

sudo nginx -t
# 按服务实际名称、主机高可用和变更窗口执行重启
sudo systemctl restart nginx
sudo systemctl status nginx --no-pager

# 核查真正存在的 master / worker
ps -eo pid,ppid,user,comm,args | grep '[n]ginx'

Ne considérez pas nginx -s reload comme une preuve qu’un nouveau binaire est en cours d’exécution : les rechargements de configuration ordinaires permettent à l’ancien master de démarrer de nouveaux travailleurs sans remplacer son exécutable. NGINX prend en charge une procédure de mise à niveau binaire en ligne dédiée, mais elle nécessite des étapes et une vérification supplémentaires. Sans procédure établie, utilisez un commutateur de trafic à haute disponibilité suivi d’un redémarrage du service ou déployez des conteneurs de remplacement. S22

Si vous gérez NGINX via le socket systemd, le script d’entrée de conteneur ou plusieurs installations, vous devez vérifier la cible de lancement réelle et le chemin du processus au lieu de supposer directement que systemctl restart nginx couvre toutes les instances.

4.6 Accepter et effectuer une régression commerciale à partir de la véritable entrée extérieure

Il est recommandé d’effectuer au minimum :

• Le HTTPS normal, les routes réécrites, les ressources statiques et les pages de mappage alias sont-ils corrects ?
• La distribution map standard, le chemin variable root, le chemin du journal d’accès, le routage SNI/certificat et le proxy Stream sont-ils corrects ?
• Les téléchargements normaux, les téléchargements fragmentés, les requêtes API et les limites de volume en amont pour HTTP/3 (lorsqu’ils sont activés) sont-ils toujours comme prévu ?
• mTLS : les demandes de certificat légitimes doivent aboutir ; les certificats manquants, expirés ou non autorisés doivent toujours être rejetés, et la reprise/reconnexion de TLS ne doit pas modifier accidentellement les autorisations.
• Si la page SSI et l’accès aux fichiers asynchrones sont normaux ; le journal des erreurs ne montre aucune demande anormale de références de mémoire ou de plantages répétés de Worker.
• Après le changement de trafic, le processus de l’ancienne version et l’ancienne réplique d’image auraient dû se terminer.

Les tests doivent être effectués dans un environnement propre ou autorisé. Le test de fumée de requête normal ne peut pas à lui seul prouver que la vulnérabilité de la mémoire a été corrigée ; en fin de compte, la version corrigée, le correctif du code source et le test d’exécution du fournisseur doivent être acceptés conjointement pour acceptation.

5. Mesures d’atténuation lorsqu’une mise à niveau immédiate n’est pas possible

Cette section est une option de réduction des risques et non un remplacement de correctif. Toutes les modifications de configuration temporaires doivent être sauvegardées, exécutées nginx -t, publiées par lots et rapidement annulées si nécessaire. S3S4

5.1 Contrôler la priorité du trafic en fonction de l’exposition externe

Donnez la priorité à la réduction de la surface d’attaque des services qui ne peuvent pas être mis à niveau à temps : sur la surface de gestion et en interne API Ajoutez un contrôle d’accès aux sources fiables, une isolation du réseau en amont ou une mise hors ligne à court terme ; ajouter des limites de connexion, de corps de demande et de tarif aux entrées à haut risque ; assurez-vous que l’authentification de la source se produit au niveau de l’entrée NGINX avant la chaîne de traitement de la demande. Il convient de noter que la plupart des vulnérabilités elles-mêmes se trouvent dans NGINX. À l’intérieur du plan de données, les règles WAF traditionnelles peuvent ne pas déterminer avec précision les conditions de déclenchement de la configuration personnalisée.

5.2 alias / rewrite : éviter d’évaluer $request_filename après la réécriture

Il est recommandé de vérifier et d’ajuster :

• Essayez de ne pas exécuter rewrite qui modifiera URI en même temps que location en utilisant alias.
• Évitez d’utiliser $request_filename lorsque URI a été réécrit mais que la correspondance de position correcte n’est pas encore terminée.
• Recherchez les références de variables indirectes dans return, set, if, add_header, accédez au format du journal et incluez les fichiers.
• Utilisez root clair/try_files/indépendant location lorsque les affaires le permettent, mais remplacez uniquement alias par root. Cela peut également modifier la sémantique du chemin de fichier, qui doit être vérifiée une par une.

Ne copiez pas directement le « modèle de réécriture sécurisé » commun sur Internet pour écraser la configuration existante. Différents préfixes location et cibles de réécriture entraînent un épissage de chemin avec des significations complètement différentes. S5

5.3 map/Regex : réduire le mélange d’états variables de capture

Il est recommandé de donner la priorité aux captures nommées et de limiter leur portée de propagation, plutôt que de permettre la réutilisation de captures anonymes telles que $1 sur différents chemins d’évaluation d’expression régulière au fil du temps. Par exemple :

# 演示具名捕获的结构，实际变量名和匹配表达式须按业务调整
map $host $tenant_root {
    default /srv/www/default;
    ~^(?<tenant>[a-z0-9-]+)\.example\.net$ /srv/www/$tenant;
}

Cet extrait démontre uniquement une structure de propriété variable plus facile à auditer ; ne signifie pas qu’il a été prouvé qu’il élimine indépendamment tous les chemins de déclenchement de CVE-2026-93479. En particulier, vérifiez si les variables de capture sont référencées à l’avance par d’autres root ou log_format, et s’il existe des volatile, des chemins dynamiques et des chaînes d’évaluation interdépendantes. F5/CERT recommande d’utiliser la capture nommée et de limiter la portée d’utilisation à la configuration de correspondance régulière correspondante comme solution à court terme. S3S6

5.4 AIO + SSI : Arrêtez les combinaisons de fonctions inutiles

Pour les serveurs/chemins qui ne nécessitent pas SSI ou des E/S de fichiers asynchrones, utilisez :

# 在适当的 http/server/location 上下文中配置
ssi off;
aio off;

Du point de vue des conditions déclenchant la vulnérabilité, la fermeture de l’une des deux suffit généralement à supprimer la chaîne spécifique décrite ; la fermeture simultanée n’est applicable qu’aux scénarios dans lesquels l’entreprise ne s’appuie pas sur cette capacité. Vérifiez le comportement de include virtual, des sous-requêtes, du cache et du pool de threads ; lorsque la charge du proxy inverse est élevée, l’arrêt du AIO peut modifier la latence et les performances d’E/S. S7

5.5 HTTP/3 Demander une injection corporelle : fermer temporairement l’entrée si nécessaire

Désactivez l’écouteur quic impliquant HTTP/3, annulez l’en-tête de réponse Alt-Svc qui annonce HTTP/3 et vérifiez si la couche périphérique/l’équilibreur de charge envoie toujours les requêtes QUIC directement au NGINX non réparé :

# 示意：保留 HTTPS/TCP；暂时移除此前的 QUIC/UDP listen
server {
    listen 443 ssl;  # 保留 HTTPS/TCP 入口
    # 对支持新版语法的构建，可在此使用 http2 on;
    # 删除原有的 listen 443 quic reuseport;
    # 删除原有的 add_header Alt-Svc ...;（仅限宣传 h3 的那项）
    # 其余证书、server_name、location 等配置保持不变
}

Ce qui précède n’est qu’une description de la différence de changement, et non une configuration complète du serveur pouvant être activée individuellement. La syntaxe de configuration de HTTP/2 est liée à la version NGINX ; si vous devez conserver HTTP/2, vous devez utiliser http2 on; ou la syntaxe valide existante selon la version correspondante, et vérifier auprès de nginx -t. doit être fusionné avec la configuration du serveur existante avant le déploiement, au lieu de remplacer la section entière par cette section. vérifie également le pare-feu UDP 443, l’emplacement de terminaison HTTP/3 et le chemin de secours client de CDN/proxy frontal.

Un autre type d’atténuation à court terme consiste à utiliser proxy_request_buffering off; sur le chemin de proxy concerné, mais cela modifiera le comportement du flux de corps de requête en amont, des tentatives d’échec et de certains flux de travail de téléchargement ; ne doit être utilisé qu’après des tests suffisants et la confirmation que la directive atteint bien le chemin proxy HTTP/3 concerné. S8S18

5.6 TLS Ticket de session : protection prioritaire mTLS Limite d’authentification

Si la mise à niveau n’est pas possible et que l’instance repose sur le cache de session partagé + la rotation automatique des clés de ticket, évaluez :

# 在 nginx http/server 适当作用域进行配置
ssl_session_tickets off;

Cela peut désactiver le mécanisme de ticket de session TLS, supprimant ainsi le chemin de falsification de ticket décrit dans cette vulnérabilité ; cependant, cela peut affecter les performances de reprise de session. Vous ne pouvez pas simplement désactiver la vérification du certificat client mTLS pour « éviter les vulnérabilités », car cela supprimerait directement la limite d’authentification d’origine. S9S12

Les fichiers ssl_session_ticket_key explicites et la rotation sécurisée peuvent également être utilisés par les processus de gestion professionnels TLS pour contourner les conditions générées automatiquement, mais la conservation des clés, la distribution complète des nœuds, la rotation et les anciens cycles de vie des tickets doivent tous être soigneusement audités. Il n’est pas recommandé de coder en dur une clé réutilisable à long terme dans une configuration Web ordinaire ou dans des scripts en cas d’urgence temporaire. Les services critiques qui utilisent mTLS doivent en outre être surveillés pour détecter le comportement de reprise de session TLS et le rejet des demandes sans certificat client valide. S12

5.7 Le rôle du système d’exploitation et la protection des frontières

# Linux：常见值 2 表示进程地址空间随机化处于完整启用状态
sysctl kernel.randomize_va_space

ASLR, les travailleurs non-root, les systèmes de fichiers de conteneurs en lecture seule, les autorisations de fichiers minimales et l’isolation du réseau peuvent réduire l’impact d’un RCE potentiel. ASLR ne corrige pas les débordements de tas ni UAF et ne peut garantir que les travailleurs ne planteront pas. WAF, les limites de débit et les limites de taille du corps de la demande ne corrigent pas la synchronisation des clés de ticket TLS. S4

5.8 Malentendu courant : Ces opérations ne suffisent pas à terminer la réparation

Opérations courantes	Pourquoi est-ce insuffisant ?
“nginx -v semble relativement nouveau”	La branche à laquelle il appartient, la version complète du package rétroporté de la version finale et le processus en ligne ne sont pas vérifiés.
« Un seul des intranets a été mis à niveau »	L’ancienne instance d’origine Worker/ancien conteneur/ancienne instance d’origine CDN reçoit toujours des requêtes
”Le site n’utilise pas de balises PHP/dynamiques”	Le défaut se produit dans l’analyse du chemin principal ou du protocole NGINX et ne repose pas sur l’exécution de PHP.
”Ouvrir WAF/Cloudflare suffit”	Il n’est pas prouvé que WAF bloque toutes les failles de mémoire dépendant de la configuration NGINX ou les failles de reprise TLS.
”ASLR déjà ouvert”	Je profite simplement de l’atténuation des difficultés ; DoS avec injection sur demande est toujours possible
”HTTP/3 n’est pas exposé au réseau public, il n’est donc pas nécessaire de procéder à une mise à niveau”	Les quatre autres CVE nécessitent encore une évaluation indépendante ; et il peut y avoir des liens directs avec des origines cachées
”La vulnérabilité map de juillet a été corrigée”	Octobre CVE-2026-93479 implique des problèmes de régression d’évaluation de script ultérieurs
”La désactivation de la mise en cache résout tous les problèmes”	Affecte uniquement certains scénarios de cache TLS ou AIO, et ne couvre pas les alias, les scripts et HTTP/3.

6. Idées de mise en œuvre du correctif officiel et points de révision

Cette section fait suite aux correctifs NGINX en amont d’octobre 2026. Les extraits illustrent les modifications représentatives pour la révision des correctifs ; ce ne sont pas des correctifs complets et compilables indépendamment. Pour les versions personnalisées, examinez les validations complètes, le code et les tests environnants, et préférez une version complète prise en charge. S5S6S7S8S9

6.1 CVE-2026-15176 : URI a été réécrit pour inclure les conditions de rejet du mappage de chemin alias.

Le commit en amont a modifié ngx_http_map_uri_to_path() dans src/http/ngx_http_core_module.c :

- if (alias && !r->valid_location) {
+ if (alias && (!r->valid_location || r->uri_changed)) {

point de révision : le chemin du système de fichiers ne peut pas continuer à être calculé lorsque URI a changé, mais la sémantique d’emplacement correspondante de alias n’est plus fiable. Il s’agit d’une amélioration de la contrainte pré-état. Il ne s’agit pas d’une simple vérification si la requête URI contient des caractères illégaux. S5

6.2 CVE-2026-93479 : distinguer correctement la longueur des données de sortie et la longueur réservée

La validation en amont met à jour src/http/ngx_http_script.c et src/stream/ngx_stream_script.c en même temps. L’intention fondamentale peut être résumée comme suit :

- n = len;
+ n = 0;
  /* ...计算实际脚本输出长度... */
- value->len = n;
- value->data = ngx_pnalloc(pool, n);
+ value->len = n + len;
+ value->data = ngx_pnalloc(pool, n + len);

Ici, pool est un nom de paramètre illustratif : les expressions d’allocation HTTP et Stream réelles diffèrent. Le changement calcule d’abord la longueur de sortie du script, puis ajoute la longueur réservée à l’allocation finale afin que la sortie n’écrase pas l’espace réservé. S6

Lors de l’audit et du rétroportage, l’évaluateur correspondant de HTTP/Stream doit également être couvert ; la seule vérification du fichier de syntaxe de configuration de map ne peut pas prouver que le défaut a été corrigé.

6.3 CVE-2026-97205 : définir le seuil de sécurité pour le nombre d’opérations asynchrones de 8 bits

En amont ajouté à src/http/ngx_http_request.h :

#define NGX_HTTP_MAX_BLOCKED 250

Et ajoutez des entrées similaires à la lecture de fichiers asynchrone, à l’attente du cache, au filtrage de sortie et au fonctionnement des threads :

if (r->main->blocked >= NGX_HTTP_MAX_BLOCKED) {
    /* 使用同步路径，或者拒绝新的异步操作 */
}

objectif de la révision : tous les chemins de code réels qui ajouteront r->main->blocked doivent être couverts. Vous ne pouvez pas simplement écrire la constante de seuil dans le fichier d’en-tête. Backport doit également vérifier la coordination complète du repli synchrone, du rappel asynchrone et du retour d’erreur pour garantir qu’un blocage ou une fuite de référence ne sera pas causé par le rejet direct des tâches. S7

6.4 CVE-2026-95101 : conserver le statut skip séparément pour les trames inconnues

L’amont ajoute le champ skip dans la structure de statut de l’analyseur HTTP/3 et effectue la séparation des statuts :

if (st->type != NGX_HTTP_V3_FRAME_DATA && st->length > 0) {
    st->skip = st->length;
    st->length = 0;
    st->state = sw_skip;
}
/* ... */
rc = ngx_http_v3_parse_skip(b, &st->skip);

La clé n’est pas de “désactiver les trames HTTP/3 inconnues”, mais de garantir qu’au cours de plusieurs lectures, le nombre d’octets ignorés et la longueur de la charge utile DATA sont toujours gérés par des états indépendants. Les examens doivent se concentrer sur le partage de tampons croisés de trames inconnu et sur la cohérence éventuelle de client_max_body_size. S8

6.5 CVE-2026-97629 : synchronisez la matrice complète d’emplacements de clé TLS

Les modifications en amont se situent à src/event/ngx_event_openssl.c :

  ngx_memcpy(keys->elts, cache->ticket_keys,
-            2 * sizeof(ngx_ssl_ticket_key_t));
+            keys->nelts * sizeof(ngx_ssl_ticket_key_t));

L’image originale contenait trois emplacements pour clés, mais seuls les deux premiers ont été copiés. Au lieu de cela, synchronisez en fonction du nombre réel d’éléments du tableau pour garantir que le jeu de clés de vote de Worker est cohérent avec la mémoire partagée. Lors de l’examen, confirmez également que l’allocation du tableau, l’initialisation, le verrouillage partagé et la logique de rotation sont cohérents, plutôt que de simplement vérifier une seule fois la modification de la longueur du memcpy. S9

6.6 Pourquoi n’est-il pas recommandé d’appliquer uniquement des fragments de patch dispersés ?

Ces cinq modifications couvrent respectivement src/http, src/stream, src/http/v3 et src/event, et les anciennes versions peuvent avoir des rétroportages de sécurité et des extensions non officielles. Le rétroportage doit former la matrice de contrôle suivante :

Vérifier l’objet	Ce qui doit être confirmé
source du correctif	Soumission officielle, version cible correspondante, vérification complète du correctif et de la signature
Ensemble de patchs originaux	N’entre pas en conflit avec les modifications historiques telles que CVE-2026-42533, le rétroportage de distribution, etc.
chemin du code	HTTP + script Stream, AIO/thread, HTTP/3, OpenSSL Ticket sont tous couverts
Compatible compilé	OpenSSL, PCRE, module ABI, module dynamique et dépendances de lien sont cohérents
régression fonctionnelle	Réécriture alias, journal dynamique, SSI/AIO, téléchargement HTTP/3, reprise de session mTLS
durée d’exécution	Tous les Worker/Pods exécutent de nouvelles versions vérifiées, il ne reste aucune image héritée

Pour les équipes qui gèrent leurs propres versions, il est recommandé de conserver les ID de correctif, les versions de package, les journaux de build et les rapports de régression vérifiables pour chaque CVE ; pour l’exploitation et la maintenance ordinaires, la solution la plus sûre consiste à installer les mises à jour de sécurité complètes du fournisseur.

7. Retour en arrière sur les vulnérabilités historiques, anciennes branches et autres produits

Vulnérabilité principale 7.1 NGINX digne d’une confirmation simultanée de mai à septembre 2026

De nombreuses instances NGINX qui n’ont pas été mises à jour depuis longtemps ne sont pas seulement affectées par le nouveau problème d’octobre. Voici les nœuds de réparation représentatifs dans un avenir proche : S1S2

CVE	Première version du correctif	Principaux risques et conditions nécessitant un audit
CVE-2026-42945	Stable 1.30.1 / Mainline 1.31.0, 13 mai	rewrite La logique anonyme de capture et de remplacement d’expressions régulières déclenche un débordement de tas, potentiel RCE ; il existe des rapports publics faisant état de tentatives d’attaque dans la nature
CVE-2026-9256	Stable 1.30.2 / Mainline 1.31.1, 22 mai	La capture d’expressions régulières et l’estimation de la longueur qui se chevauchent dans rewrite entraînent un débordement
CVE-2026-42055	Stable 1.30.3 / Mainline 1.31.2, 17 juin	HTTP/2 Configuration spécifique en amont ou gRPC, une condition d’en-tête de requête importante déclenche un débordement de tampon
CVE-2026-42530	Mainline 1.31.2, 17 juin	HTTP/3 Utilisation après libération ; marque officielle gamme concernée 1.31.0–1.31.1
CVE-2026-42533	Stable 1.30.4 / Mainline 1.31.3, 15 juillet	L’évaluation de la variable de capture map + regex provoque un débordement de tas et les correctifs suivants ont une corrélation de régression avec CVE-2026-93479 en octobre
CVE-2026-60005	Stable 1.30.4 / Mainline 1.31.3, 15 juillet	ngx_http_slice_module Fuite du contenu de la mémoire dans des conditions spécifiques de mise à jour des variables et du cache
CVE-2026-56434	Stable 1.30.4 / Mainline 1.31.3, 15 juillet	SSI est lié à UAF ; ce n’est pas la même cause root que la vulnérabilité de comptage AIO d’octobre
CVE-2026-90439	Stable 1.30.5 / Mainline 1.31.6, 15 septembre	Débordement de tas limité de la combinaison HTTP/3 + version spécifique de OpenSSL, se manifestant principalement par un crash/une corruption de mémoire limitée

D’autres vulnérabilités telles que NGINX Core, HTTP/2, charset et SMTP annoncées en 2026 devraient également faire l’objet d’une enquête selon les bulletins de sécurité officiels ; ce tableau se concentre intentionnellement sur les événements typiques les plus pertinents pour les déploiements actuels de proxy inverse destinés au public NGINX et qui ont des implications en matière de sécurité de la mémoire ou d’intégrité des requêtes. ce ne sont pas tous les CVE en 2026. Liste. S1

Pourquoi accorder une attention particulière à CVE-2026-42945

Il existe des bulletins de sécurité émanant d’agences gouvernementales qui enregistrent les activités d’exploitation dans la nature et les informations publiques sur le code d’exploitation pour cette vulnérabilité rewrite en mai. Par conséquent, pour les instances qui n’ont pas été corrigées depuis longtemps entre mai et aujourd’hui et qui ont des réécritures d’expressions régulières complexes ouvertes sur le réseau public, en plus de terminer la réparation, le crash anormal de Worker, les journaux d’accès et les modifications suspectes à ce moment-là doivent également être examinés. S23

« Une tentative d’attaque s’est produite » ne prouve pas automatiquement que l’attaquant a exécuté les commandes de manière fiable sur chaque cible ; lorsqu’une réponse à un incident est impliquée, les indicateurs de compromission et les plantages de processus doivent être étudiés séparément des véritables preuves d’élévation ou de persistance des privilèges.

Correction 7.2 pour les anciennes versions et les rétroportages de distribution

NGINX Différentes branches ont leurs propres cycles de support et différents délais d’introduction des vulnérabilités. Les cinq nouveaux correctifs ne peuvent pas être déployés sur toutes les premières arborescences sources sans examen.

scène	Stratégie recommandée
La version Release a annoncé des correctifs de sécurité complets	Utiliser les packages du fournisseur et documenter les versions complètes des packages ; éviter de remplacer par des binaires nus incompatibles en amont
Debian 12 et autres versions concernées qui ne sont pas encore couvertes par tous les CVE de ce lot	Soumettre des ordres de travail à risque, limiter l’exposition externe et vérifier le statut du fournisseur/ELTS ; migrer ou utiliser une chaîne de versions de maintenance vérifiable si nécessaire
Branches historiques qui ont mis fin au support en amont	Prioriser la migration vers les versions prises en charge ; si un rétroportage à court terme est nécessaire, les responsables évalueront les dépendances et la compatibilité des correctifs, et écriront des tests complets.
Livré avec une fourche NGINX (OpenResty, Tengine, passerelle personnalisée)	Déterminez d’abord si le chemin de code correspondant est inclus, puis utilisez la déclaration de sécurité du responsable du fork. Elle ne peut pas être directement équivalente à la version amont.
Les correctifs de sécurité entraînent des modifications dans les fonctionnalités de l’entreprise	Adopter des déploiements par étapes, la commutation du trafic entre les versions et l’adaptation de la configuration ; il n’est pas approprié de restaurer la version non corrigée du réseau public sans isolation.

7.3 Correction distincte pour njs, Ingress et NGINX Core

• njs : En plus du programme principal NGINX, vous devez également vérifier la version du module JavaScript NGINX lui-même. njs 1.0.2 corrige un problème d’épuisement de la mémoire d’analyse XML et d’incohérence de validation XML d’octobre 2026 avec les attributs de référence d’entité. Pour les déploiements associés à la vérification de signature XML à l’aide de nginx-saml, vous devez lire davantage les instructions officielles de njs pour les scénarios de plug-in. S20
• Contrôleur d’entrée F5 NGINX Plus / NGINX : De plus, le contrôleur et Gateway Fabric peuvent chacun avoir des bulletins de sécurité supplémentaires, des versions de packaging différentes et des vulnérabilités de politique uniques. La mise à niveau d’une couche ne signifie pas la mise à jour automatique d’une autre couche. S19
• Communauté Kubernetes ingress-nginx : les responsables de Kubernetes ont déjà annoncé que le contrôleur avait arrêté la maintenance en mars 2026 et que son entrepôt ne pouvait pas être confondu avec le contrôleur F5. Les entreprises concernées doivent planifier une migration en douceur et vérifier les annotations Ingress et les différences sémantiques Gateway API au lieu d’attendre une nouvelle version de sécurité. S21

8. Critères d’acceptation et inspections de suivi

Il est recommandé d’utiliser la liste suivante comme conditions d’acceptation des ordres de travail de modification :

Projet	Normes de qualification	Preuves pouvant être conservées
Couverture des actifs et du portail	Toutes les instances externes et connectées directement qui peuvent contourner CDN ont été inventoriées.	Nom de domaine, LB, IP, liste de pods/conteneurs
Source du package et étendue de la réparation	Utiliser des versions confirmées pour couvrir tous les CVE applicables	Avis de sécurité en amont, USN/DSA, version du package, résumé d’image
l’ancien processus se termine	Tous les anciens conteneurs master/worker/conteneurs ont été remplacés	PID/heure de début, statut de déploiement progressif, image en cours d’exécution
Audit de configuration	Les combinaisons à haut risque ont été éliminées ou couvertes par des correctifs, et les relations d’héritage ont été vérifiées	résumé rédigé et dossier d’audit de nginx -T
TLS/mTLS	Les certificats de confiance réussissent ; les certificats invalides ou manquants sont rejetés ; la reprise de session ne contourne pas l’authentification	Test d’autorisation négatif/positif, résultats de test contrôlés TLS
Corps de la demande HTTP/3	Activer le chemin corrigé ; le corps de la requête en amont et la limitation se comportent correctement	HTTP/3, téléchargement proxy, test de régression de limite de volume
SSI/AIO	La fonction répond aux exigences, Worker n’a pas d’abandon anormal	Surveillance de la régression commerciale, des crashs et des taux d’erreurs
Suivi de l’exploitation et de la maintenance	Aucune exception évidente 5xx, SIGSEGV, le processus se termine à plusieurs reprises	Indicateurs de service et journaux avant et après les modifications
Stratégie de restauration	Si une restauration est nécessaire, limitez d’abord l’exposition et préservez les limites de sécurité.	Ordres de modification, flux d’urgence et plans de quarantaine
cycle de vie ultérieur	Déterminez les abonnements aux bulletins de sécurité, la fréquence de mise à jour des conteneurs et les plans de migration des succursales	Grand livre de mise à niveau, personne responsable et date du prochain audit

8.1 Sur quoi devez-vous vous concentrer dans les journaux et l’état d’exécution ?

Résoudre les anomalies sur les serveurs qui ont été exposés pendant une longue période worker process exited on signal 、 SIGSEGV , les pics d’échec de demande, l’agrégation anormale d’accès à la source, la reprise de session/réussite d’authentification TLS inattendue et le comportement anormal du corps de la demande backend. Ces indicateurs ne peuvent être utilisés que comme indices d’enquête et ne constituent pas des preuves suffisantes pour prouver directement qu’une certaine CVE a été exploitée. ;L’absence de journaux pertinents ne prouve pas qu’il n’y a pas eu d’attaque.

8.2 Formulation recommandée pour la conclusion finale en matière de risque

Le procès-verbal de réception de l’environnement de production doit utiliser l’expression précise suivante :

L’entrée de service externe NGINX et la source du progiciel ont été identifiées. Toutes les instances applicables ont été mises à niveau vers la version de sécurité officielle en amont, ou le rétroportage confirmé par le fournisseur de la version a été effectué ; l’ancien Worker et les anciens conteneurs ont été remplacés. L’alias/réécriture/map, les configurations associées AIO/SSI, HTTP/3 et les configurations associées au ticket de session TLS/mTLS ont été auditées et ont réussi les tests de régression fonctionnelle, d’authentification et d’intégrité des demandes. Pour les instances qui n’ont pas encore terminé la mise à niveau, enregistrez en outre les zones d’exposition, les mesures de compensation, les personnes responsables et les délais d’exécution.

Si le correctif pour Debian 12 ou d’autres versions est encore incomplet, il n’est pas approprié de considérer l’intégralité du formulaire d’acceptation comme « complété » ; le CVE non résolu, s’il existe une configuration de déclenchement correspondante, l’état d’isolement et l’itinéraire de mise à niveau final doivent être clairement enregistrés.

---

Annexe : sources citées et liens

Description : Les numéros [Sx] dans le texte correspondent uniformément à cette section. Ce qui suit donne la priorité aux annonces de sécurité du projet en amont, aux engagements de code, aux annonces de versions des fournisseurs et aux informations des agences de sécurité nationale. La gravité des vulnérabilités citées est décrite selon les critères de notation de chaque organisme émetteur ; la date de vérification des données est le 27 octobre 2026.

S1 — Bulletin de sécurité officiel NGINX Open Source

• https://nginx.org/en/security_advisories.html

Contient les versions affectées en amont, les branches de correctifs et les niveaux de gravité officiels de cinq CVE d’octobre, et couvre également les vulnérabilités historiques jusqu’en 2026.

S2 — Enregistrement de la version officielle NGINX

• https://nginx.org/news.html
• https://nginx.org/en/CHANGES-1.30

Confirmez 1.30.6 / 1.31.7 de 2026-10-14, 1.31.8 de 2026-10-21 et les étapes critiques des versions de sécurité de mai à septembre.

S3 - Cyber Security Agency of Singapore : F5 NGINX Trois vulnérabilités critiques

• https://www.csa.gov.sg/alerts-and-advisories/alerts/al-2026-150/

Description des scores CVSS v4.0 9.2, des conditions de configuration requises et des recommandations d’atténuation provisoires pour CVE-2026-15176, CVE-2026-93479 et CVE-2026-97205.

S4 - NHS England : F5 NGINX Avis de risque élevé

• https://digital.nhs.uk/cyber-alerts/2026/cc-4872

Décrit l’impact DoS/RCE potentiel des problèmes de sécurité de la mémoire, ainsi que les contraintes telles que la désactivation ou le contournement de ASLR.

S5 — Engagement de source officielle : CVE-2026-15176

• https://github.com/nginx/nginx/commit/f8a23425bd6840c4c36b4264edf576ba3646156f

Correspond au contrôle d’état de alias et r->uri_changed dans ngx_http_map_uri_to_path().

S6 — Engagement de source officielle : CVE-2026-93479

• https://github.com/nginx/nginx/commit/6aa4b3fdd4fdc156153f2981eb4070690624447c

Correspondant à la longueur du script HTTP/Stream et à la logique d’allocation de tampon réservé.

S7 - Validation de source officielle : CVE-2026-97205

• https://github.com/nginx/nginx/commit/6adfc05ece48f92446383ec1f145446848694698

Correspond au seuil de comptage r->main->blocked NGX_HTTP_MAX_BLOCKED 250 et au repli du chemin asynchrone.

S8 — Engagement de source officielle : CVE-2026-95101

• https://github.com/nginx/nginx/commit/1c173a2d8767730e678c27446138d7ae5dd6fd64

Séparation d’état correspondant à la longueur restante de la trame inconnue HTTP/3 et à la longueur du corps de la demande DATA.

S9 — Engagement de source officielle : CVE-2026-97629

• https://github.com/nginx/nginx/commit/1916f26e6ca49296568633d309777e36527e5bb2

Correspond à tous les emplacements de clé lors de la rotation de synchronisation du ticket de session TLS.

S10 — F5 : Annonce du fournisseur CVE-2026-15176

• https://my.f5.com/manage/s/article/K000162416

Répertoriez les facteurs déclencheurs tels que alias, rewrite, $request_filename et les journaux d’accès.

S11 — F5 : Annonce du fournisseur CVE-2026-93479

• https://my.f5.com/manage/s/article/K000162607

Répertoriez la capture d’expression régulière de carte, le chemin root et les conditions d’évaluation des variables de journal.

S12 — Documentation officielle du module NGINX TLS/SSL

• https://nginx.org/en/docs/http/ngx_http_ssl_module.html

Description ssl_session_cache, ssl_session_tickets, ssl_session_ticket_key et authentification par certificat client et autres instructions.

S13 — Avis de sécurité: Ubuntu USN-8955-1 (2026-10-26)

• https://ubuntu.com/security/notices/USN-8955-1

Fournir la version fixe du progiciel complet et la portée de distribution de Ubuntu 22.04 / 24.04 / 26.04 / 26.10.

S14 — Avis de sécurité: Debian DSA-6575-1 (2026-10-21)

• https://lists.debian.org/debian-security-announce/2026/msg00490.html

Confirmez le package de correctifs de sécurité 1.26.3-3+deb13u10 pour Debian 13 / trixie et enregistrez l’association de rétroportage pour CVE-2026-93479.

S15 — Suivi des vulnérabilités: Debian Security Tracker: CVE-2026-15176

• https://security-tracker.debian.org/tracker/CVE-2026-15176

Utilisé pour vérifier l’état du correctif de distribution de Debian 12 / bookworm et Debian 13 / trixie. Cet état peut changer avec les futures mises à jour de sécurité.

S16 — Suivi des vulnérabilités: Debian Security Tracker: CVE-2026-95101

• https://security-tracker.debian.org/tracker/CVE-2026-95101

Confirmation supplémentaire de l’état de sécurité de la vulnérabilité HTTP/3 sur différentes branches Debian.

S17 — Avis de sécurité: Red Hat: CVE-2026-93479

• https://access.redhat.com/security/cve/cve-2026-93479

Compréhension supplémentaire de la corrélation entre la vulnérabilité de régression d’octobre et le correctif de juillet CVE-2026-42533.

S18 — Document officiel du module de proxy inverse NGINX

• https://nginx.org/en/docs/http/ngx_http_proxy_module.html
• https://nginx.org/en/docs/http/ngx_http_core_module.html

Interrogez la sémantique et les valeurs par défaut des configurations telles que proxy_request_buffering, client_max_body_size, alias, aio, etc.

S19 — Notes de version officielles de NGINX Plus

• https://docs.nginx.com/nginx/releases/

List Plus CR/LTS branches, versions, correctifs et rappels de compatibilité de mise à niveau.

S20 — NGINX JavaScript / njs Bulletin de sécurité officiel

• https://nginx.org/en/docs/njs/security.html
• https://nginx.org/en/docs/njs/changes.html

Contient le njs 1.0.2 d’octobre 2026 et les problèmes de validation XML et d’épuisement de la mémoire associés.

S21 — Kubernetes : Instructions officielles de retraite de la communauté ingress-nginx

• https://kubernetes.io/blog/2025/11/11/ingress-nginx-retirement/
• https://kubernetes.io/blog/2026/01/29/ingress-nginx-statement/

Notez que le projet a arrêté les nouvelles versions et correctifs de sécurité en mars 2026, et il est recommandé de migrer le contrôleur maintenu ou Gateway API.

S22 — Contrôle de service officiel NGINX et instructions de mise à niveau binaire en ligne

• https://nginx.org/en/docs/control.html

Distinguer les méthodes de rechargement de configuration, de redémarrage et de mise à niveau des fichiers exécutables en ligne pour l’acceptation du changement de processus.

S23 – Avis de sécurité du gouvernement : vulnérabilité de réécriture NGINX de mai 2026

• https://its.ny.gov/2026-051
• https://www.govcert.gov.hk/en/alerts_detail.php?id=1881

Fournir un historique des risques et des suggestions de mises à jour de sécurité pour CVE-2026-42945 ; les jugements liés à l’exploitation dans la nature doivent être basés sur l’annonce de l’agence à ce moment-là et sur d’autres preuves de l’incident.

S24 — F5 : annonces des fournisseurs CVE-2026-95101 et CVE-2026-97629

• https://my.f5.com/manage/s/article/K000162613
• https://my.f5.com/manage/s/article/K000162606

Couvre respectivement les risques d’injection de corps sur demande HTTP/3 et de rotation automatique des clés du ticket TLS.

S25 — F5 : Annonce du fournisseur CVE-2026-97205

• https://my.f5.com/manage/s/article/K000162608

Description Conditions de déclenchement SSI/AIO et risques potentiels de corruption de la mémoire.

Mise à jour de sécurité NGINX : contrôles de configuration, mises à niveau et vérification