Un correctif du 15 juillet pour du code écrit en 2011
Le 15 juillet 2026, le projet nginx a publié les versions 1.30.4 et 1.31.3, et cette livraison a refermé un débordement de tas accessible dans toutes les versions jusqu'à la 0.9.6. Cette version date de 2011. La vulnérabilité est enregistrée sous CVE-2026-42533 et cotée 9,2 sur l'échelle CVSS version 4.0. F5 a publié l'avis K000162097 pour les clients NGINX Plus, corrigé dans 37.0.3.1.
La liste des déclarants est inhabituelle. Plus d'une douzaine de chercheurs ont signalé le même problème de façon indépendante, dont Mufeed VH de Winfunc Research, et le mainteneur de longue date Maxim Dounin a pris en charge la correction. Quand une faille est trouvée par autant de personnes en même temps, l'hypothèse raisonnable est qu'elle n'était pas difficile à trouver et que d'autres l'ont trouvée sans déposer de rapport.
Ce que votre configuration doit contenir pour être concernée
Le défaut réside dans le moteur de script, qui évalue les expressions de chaîne que nginx construit au moment de la requête. Cette évaluation se déroule en deux passes. La première mesure la taille nécessaire d'un tampon en utilisant l'état des captures à cet instant. La seconde écrit dans ce tampon avec des données de capture que la requête peut influencer. Lorsque les deux passes divergent, l'écriture dépasse l'espace réservé.
Le déclencheur est plus étroit que ne le laisse penser la plage de versions. Il faut une directive map fondée sur une expression régulière dont la variable de sortie est référencée dans une expression de chaîne après une capture issue d'une correspondance antérieure, les captures numérotées écrites dollar-un et dollar-deux. Si votre configuration ne contient aucune carte regex de cette forme, le numéro de version seul ne vous place pas dans l'ensemble touché. C'est le fait le plus utile de toute cette publication.
Sans authentification, mais pas encore armé
Là où le motif est présent, la requête qui le déclenche n'a besoin d'aucun identifiant. Une requête HTTP forgée depuis n'importe quel point d'internet suffit. Le résultat fiable est l'arrêt et le redémarrage d'un processus de travail, soit un déni de service devant la porte d'entrée de ce que le serveur publie. L'exécution de code à distance est le cas plus difficile, possible là où la randomisation de l'espace d'adressage est désactivée ou contournable, et le chercheur Stan Shaw soutient que la faille fournit elle-même le moyen de contourner cette protection.
Au 20 juillet, aucun code d'attaque public n'existe et la CVE ne figure pas au catalogue américain des vulnérabilités exploitées connues. C'est l'état actuel, non une prévision. Shaw a annoncé qu'il publierait une preuve de concept 21 jours après la sortie du correctif, ce qui la situe dans la première semaine d'août. Une faille critique non exploitée mais assortie d'une date publiée est un problème de planification différent d'une faille sans date.
Trois débordements dans un sous-système en deux mois
CVE-2026-42533 n'est pas une trouvaille isolée. C'est le troisième débordement de tas divulgué dans le code d'évaluation des expressions de nginx en environ deux mois, après CVE-2026-42945 en mai et CVE-2026-9256 peu après. Trois trouvailles dans un sous-système en un trimestre relèvent d'un schéma et non du hasard, et ce schéma indique que la conception à deux passes est passée au crible par des gens qui savent désormais où chercher.
La conséquence pour la planification est nette. Traiter ceci comme un simple changement de version et passer à autre chose donne une probabilité nettement non nulle de revenir ici dans le trimestre. Ce qui doit figurer sur la liste de surveillance, c'est le sous-système et non le numéro de CVE, et ce qui se réduit durablement, ce sont les formes de configuration qui l'atteignent.
La vérification avant d'appeler votre hébergeur
La plupart des publications critiques sur les serveurs web laissent un dirigeant dépendant d'autrui. Pas celle-ci, car le déclencheur est lisible dans un fichier que vous pouvez ouvrir. Demandez votre version de nginx, puis demandez si un bloc map de la configuration utilise une expression régulière et alimente une variable ensuite combinée dans une chaîne aux côtés de captures numérotées. Deux questions, une réponse, et vous savez si début août est une échéance ou une note.
Pour les entreprises relevant de la directive sur la sécurité des réseaux et des systèmes d'information dans l'Union européenne, et pour celles qui suivent les orientations équivalentes du Royaume-Uni, la documentation compte autant que le correctif. Consignez la version sur laquelle vous étiez, la date de vérification de la configuration et l'atténuation appliquée. Une autorité qui interrogera sur une faille critique publiée en juillet voudra la date de votre évaluation, pas seulement celle de la mise à jour finale.
À lire ensuite: Quatre agents de code sortis sans forcer la moindre barrière | ServiceNow a corrigé son cloud d'abord, vous 103 jours plus tard
