nginx corrige un débordement de tas dans la poignée de main HTTP/3 de ses serveurs edge
Le 15 septembre 2026, nginx a publié les versions 1.31.6 et 1.30.5 pour colmater CVE-2026-90439, un débordement de tas dans le module HTTP/3 qui frappe les déploiements compilés contre OpenSSL 3.5.0 ou antérieur. Mettez à jour nginx et OpenSSL, puis désactivez HTTP/3 sur les bords qui n’en ont pas besoin.
15 septembre 2026. nginx livre les versions 1.31.6 (mainline) et 1.30.5 (stable), toutes deux porteuses d’un correctif de sécurité. 2 septembre. La 1.31.5 avait ouvert un chapitre fonctionnel inédit : API de contrôle, predicate locations et module JSON natif. 3.5.0. C’est le numéro d’OpenSSL au-delà duquel le déclencheur disparaît. Pourquoi c’est important : la faille vit dans HTTP/3, la partie la plus récente et la moins rodée de la surface d’un serveur edge — celle que beaucoup d’équipes exposent sur Internet sans même savoir qu’elle est active.
HTTP/3 est devenu une surface par défaut, pas un choix réfléchi
nginx est le reverse proxy et le serveur web le plus déployé de l’internet, et HTTP/3 y est arrivé relativement tard par rapport à d’autres implémentations. La conséquence est double. D’un côté, la base installée est immense : tout correctif y touche un nombre d’instances considérable. De l’autre, HTTP/3 repose sur QUIC, un transport bâti sur UDP et non sur TCP — un changement de modèle complet qui ne se résume pas à « du HTTP en plus rapide ».
Le point qui compte ici est opérationnel. Beaucoup d’administrateurs ont activé HTTP/3 en suivant une recette de déploiement — les directives listen 443 quic reuseport; et l’en-tête Alt-Svc — sans la revoir ensuite. Résultat : une surface réseau supplémentaire est ouverte sur des boîtiers qui, jusqu’alors, ne parlaient que TCP. C’est précisément sur cette surface que CVE-2026-90439 frappe.
Ce que fait précisément la faille
La vulnérabilité vit dans ngx_http_v3_module, le module qui implémente HTTP/3. D’après l’avis de sécurité, un débordement de tas limité (heap buffer overflow) peut se produire pendant la poignée de main TLS d’une connexion QUIC, lorsque deux conditions sont réunies : le serveur est compilé contre OpenSSL 3.5.0 ou une version antérieure, et certaines configurations particulières sont en place.
Trois propriétés rendent cette faille inhabituelle. D’abord, le déclencheur est non déterministe — l’éditeur écrit lui-même qu’il survient « d’une manière qui échappe au contrôle de l’attaquant ». Ensuite, l’impact est double : un redémarrage du processus worker (déni de service) et une corruption de données limitée. Enfin, le score CVSS 6.5 la classe « moyenne », mais ce chiffre masque l’essentiel : la corruption se produit dans le même worker qui traite les autres requêtes, et l’impact de disponibilité touche le bord entier, pas une seule connexion.
Le périmètre couvre nginx Plus et nginx Open Source. La correction a été intégrée aux deux branches simultanément — 1.31.6 pour la mainline et 1.30.5 pour la stable — et s’accompagne d’un durcissement distinct : l’extension de paramètres de transport QUIC reçue dans une connexion SSL est désormais toujours ignorée.
Pourquoi OpenSSL 3.5.0 est le vrai marqueur de risque
Le lien avec OpenSSL n’est pas anecdotique. La faille n’existe que si le binaire nginx a été lié contre une OpenSSL antérieure ou égale à 3.5.0. Cela veut dire qu’une mise à jour de nginx seule ne suffit pas toujours : un paquet reconstruit contre une OpenSSL obsolète peut rester vulnérable malgré une version nginx récente.
La vérification se fait en une commande, et elle est plus fiable que la seule lecture du numéro de version :
# Lister la version nginx et la version OpenSSL de compilation
nginx -V 2>&1 | tr ' ' '\n' | grep -E 'nginx/|OpenSSL'Tant que la ligne built with OpenSSL affiche 3.5.0 ou moins, le correctif applicatif n’est pas complet : il faut aussi mettre à jour la bibliothèque OpenSSL utilisée au link.
Désactiver HTTP/3, ou le garder sous contrôle
Pour un serveur edge qui n’a pas besoin de HTTP/3, la mesure la plus propre est la suppression pure et simple de la directive d’écoute QUIC :
server {
listen 443 ssl;
# listen 443 quic reuseport; # <- commenter/retirer désactive HTTP/3
server_name example.com;
}Pour les déploiements qui veulent conserver HTTP/3, la posture minimale est une mise à jour coordonnée de nginx et d’OpenSSL, puis une surveillance du taux de redémarrage des workers. Un worker qui crashe en boucle sur un bord QUIC exposé est le symptôme exact de ce que CVE-2026-90439 produit.
L’épisode illustre une tendance plus large. HTTP/3 est la première refonte majeure du transport web depuis des années, et son adoption a été largement tirée par la latence et les CDN plus que par un raisonnement de sécurité. Les failles de cette couche sont mécaniquement plus jeunes, moins documentées et moins couvertes par les outils de détection historiques — les IDS et les pare-feux qui parsent encore TCP ne voient pas toujours le trafic QUIC de la même façon. Le correctif du 15 septembre rappelle que cette surface neuve n’est pas encore entrée dans la routine de durcissement de la plupart des équipes. Le retrait d’ingress-nginx au profit du Gateway API dans Kubernetes, que nous avons couvert ici, déplace d’ailleurs une partie de cette responsabilité vers d’autres implémentations qu’il faudra suivre avec la même rigueur.
Verdict
CVE-2026-90439 n’est pas un CVSS 9.8 à la une, mais c’est un signal utile sur une surface que peu d’équipes surveillent réellement. Si vous exposez nginx sur Internet avec HTTP/3 actif, passez en 1.30.5+ ou 1.31.6+ et vérifiez la version d’OpenSSL liée — les deux, pas l’un ou l’autre. Si vous n’utilisez pas HTTP/3, retirez la directive listen … quic : vous supprimez le risque sans attendre le moindre correctif. Si vous gérez un parc de proxies, ajoutez le couple « version nginx + version OpenSSL de compilation » à votre inventaire de conformité, car c’est la combinaison, et non l’un des deux numéros isolément, qui détermine l’exposition.