nghttp2/nghttpx : une faille HTTP/1.1 peut faire tomber le proxy

L’avis de sécurité Ubuntu USN-8495-1 signale une vulnérabilité dans nghttp2, et plus précisément un impact exploitable sur nghttpx, le composant de reverse proxy de l’écosystème nghttp2. Le problème concerne le traitement de certaines requêtes HTTP/1.1 utilisant le mécanisme Upgrade, combiné à un en-tête Content-Length et à un corps de requête. Dans les déploiements exposant nghttpx en frontal, un attaquant distant peut provoquer un déni de service et interrompre le trafic applicatif transitant par le proxy.

Le point important, pour les équipes d’exploitation comme pour les RSSI, est qu’il ne s’agit pas d’un bug théorique limité à un usage marginal de HTTP/2. nghttpx est utilisé comme brique de terminaison, de reverse proxy ou de passerelle entre clients et applications. Lorsqu’un frontal de ce type tombe, l’impact dépasse largement le composant lui-même : indisponibilité des sites et API publiés, erreurs en chaîne côté supervision, saturation éventuelle des mécanismes de redémarrage, et dégradation de service pour l’ensemble des applications derrière le proxy.

L’avis Ubuntu ne présente pas cette faille comme une exécution de code ou une compromission de confidentialité, mais un DoS à distance sur un composant de bordure reste critique en production. Pour beaucoup d’environnements, notamment chez des hébergeurs ou sur des VM exposées chez OVHcloud, Scaleway ou o2switch, le reverse proxy constitue le point d’entrée principal. Une interruption de ce maillon suffit à rendre un service indisponible, même si les backends applicatifs restent intacts.

La source de référence est l’avis officiel Ubuntu USN-8495-1: nghttp2 vulnerability, qui indique qu’une mise à jour de sécurité corrige le problème dans les paquets Ubuntu concernés. Lorsque le score CVSS ou un identifiant CVE sont nécessaires à vos processus internes, il faut se référer directement à l’avis Ubuntu et aux métadonnées associées dans les dépôts de sécurité de la distribution, ainsi qu’aux références amont éventuellement mentionnées par l’éditeur. En l’absence d’un détail explicitement confirmé dans l’avis source fourni ici, il est préférable de ne pas extrapoler.

Versions affectées

Les systèmes concernés sont les déploiements utilisant les paquets nghttp2 et/ou nghttpx fournis par Ubuntu avant application du correctif publié dans l’avis USN-8495-1. L’information essentielle à retenir est donc la suivante : si votre instance Ubuntu exécute une version de nghttp2 issue des dépôts de la distribution et que les mises à jour de sécurité n’ont pas encore été appliquées, elle doit être considérée comme potentiellement vulnérable.

L’avis Ubuntu fournit la liste exacte des publications et des versions de paquets corrigées. Dans un contexte d’exploitation, il faut vérifier deux choses :

• la version installée du paquet nghttp2 sur l’hôte ;
• l’usage effectif de nghttpx comme reverse proxy ou frontal HTTP.

Sur Ubuntu, la vérification la plus simple consiste à interroger le gestionnaire de paquets :

Selon la manière dont le paquet est nommé sur votre version d’Ubuntu, il peut être utile de lister les paquets installés liés à nghttp2 :

Pour obtenir le détail des versions installées et candidates depuis les dépôts, vous pouvez également utiliser :

Dans les environnements où nghttpx a été installé comme composant distinct ou dépendance d’une chaîne d’exposition HTTP, il faut vérifier le service réellement lancé sur la machine :

Ou, si le service est supervisé autrement :

En pratique, les versions affectées sont donc les versions antérieures à la version corrigée publiée par Ubuntu pour chaque release prise en charge. La version corrigée exacte dépend de la branche Ubuntu utilisée. Comme l’avis USN-8495-1 est la source normative, il faut s’y référer pour la correspondance précise entre publication Ubuntu et numéro de version du paquet corrigé.

Ce point est particulièrement important dans les infrastructures mixtes :

• VM Ubuntu exposées directement sur Internet ;
• nœuds derrière un load balancer mais exécutant eux-mêmes nghttpx ;
• conteneurs bâtis à partir d’images Ubuntu non reconstruites depuis la publication de l’avis ;
• appliances internes ou images golden contenant un paquet figé avant correctif.

Autrement dit, le risque ne concerne pas seulement les serveurs administrés manuellement. Il touche aussi les pipelines d’images, les templates cloud et les déploiements automatisés qui continuent de reproduire une base vulnérable.

Vecteur d'attaque

Le vecteur décrit par Ubuntu repose sur des requêtes HTTP/1.1 de type Upgrade, accompagnées d’un en-tête Content-Length et d’un corps de requête. Cette combinaison est importante, car elle sort du cas d’usage le plus simple d’un reverse proxy recevant des requêtes HTTP classiques sans transition de protocole.

Techniquement, le mécanisme Upgrade en HTTP/1.1 permet à un client de demander un changement de protocole sur la connexion existante. Dans l’écosystème web moderne, ce mécanisme est connu notamment pour certains scénarios de transition ou de négociation, même si tous les frontaux ne l’utilisent pas de la même manière. Lorsqu’un composant comme nghttpx traite ce type de requête, il doit gérer proprement plusieurs états :

• l’analyse de la ligne de requête et des en-têtes ;
• la présence d’un Content-Length déclarant une taille de corps ;
• la réception effective du corps ;
• la bascule ou non vers le protocole demandé par Upgrade ;
• la coordination entre la couche de parsing HTTP/1.1 et la logique de proxy.

Une erreur dans cette séquence peut conduire à un état inattendu du processus, à une consommation anormale de ressources, à une fermeture brutale ou à un blocage de service. L’avis Ubuntu résume cela en un impact de type déni de service à distance. Pour les défenseurs, cela signifie qu’un attaquant n’a pas besoin d’un accès authentifié ni d’un positionnement interne : il lui suffit d’atteindre le frontal vulnérable et de lui envoyer des requêtes construites selon ce schéma.

Un exemple minimal de requête illustrant les éléments mentionnés dans l’avis ressemble à ceci :

Ce bloc n’est pas un PoC d’exploitation validé, mais une illustration des composants protocolaires cités par la source : une requête HTTP/1.1, un en-tête Upgrade, un en-tête Content-Length et un corps. Le point clé n’est pas la ressource demandée, mais la manière dont le proxy gère l’ensemble de la transaction.

Dans un scénario concret, un attaquant peut automatiser l’envoi répété de telles requêtes contre une IP publique ou un nom de domaine exposant nghttpx. Si le bug provoque la terminaison du processus, les symptômes visibles peuvent être immédiats :

• erreurs 502, 503 ou absence totale de réponse côté clients ;
• redémarrages successifs du service si un superviseur tente de le relancer ;
• pics d’erreurs dans les sondes de disponibilité ;
• dégradation de l’ensemble des applications publiées derrière le frontal.

Dans un cluster ou une architecture redondée, l’impact dépend de la topologie. Si plusieurs nœuds vulnérables sont exposés derrière un répartiteur de charge, un attaquant peut viser successivement chaque instance. Si le frontal est unique, le service peut devenir indisponible dès la première interruption. Même avec redondance, un DoS applicatif ciblé sur le proxy peut dégrader fortement la capacité globale si les nœuds sont homogènes et vulnérables.

Il faut aussi souligner un point souvent sous-estimé : une faille de disponibilité sur un reverse proxy n’est pas seulement un problème de confort opérationnel. Pour une API métier, un portail client, une interface d’administration ou un service B2B, l’indisponibilité peut avoir des conséquences contractuelles, financières ou de sécurité. Une coupure de frontal peut empêcher l’accès aux mécanismes d’authentification, bloquer les flux entrants légitimes, perturber les tâches automatisées et compliquer la réponse à incident.

Impact

L’impact confirmé par l’avis Ubuntu est un déni de service à distance sur nghttpx. Il faut bien distinguer ce que cela signifie et ce que cela ne signifie pas.

• Ce qui est confirmé : un attaquant distant peut faire tomber le proxy ou perturber son fonctionnement via des requêtes HTTP/1.1 Upgrade particulières.
• Ce qui n’est pas affirmé ici : aucune exécution de code, aucune élévation de privilèges, aucune fuite de données n’est indiquée dans le résumé fourni par la source Ubuntu.

Pour autant, un DoS sur un composant de bordure reste un incident sérieux. Dans beaucoup de piles web, nghttpx occupe l’une des fonctions suivantes :

• terminaison TLS ;
• reverse proxy vers des applications HTTP ;
• passerelle entre clients HTTP/2 et services backend ;
• point de contrôle des en-têtes, du routage ou des politiques de connexion.

Si ce composant devient indisponible, les applications en aval peuvent être parfaitement saines tout en devenant inaccessibles. C’est la raison pour laquelle les failles DoS sur les briques de frontal doivent être traitées avec le même sérieux qu’un défaut sur un load balancer, un WAF ou un proxy TLS.

Plusieurs scénarios d’impact sont plausibles en production :

Interruption frontale d’un site ou d’une API

Le cas le plus direct est l’arrêt du processus nghttpx ou son incapacité à continuer à traiter les connexions. Les utilisateurs obtiennent alors des erreurs de connexion, des réponses d’erreur de passerelle, ou des timeouts.

Instabilité sous redémarrage automatique

Avec systemd ou un autre superviseur, un service qui tombe peut être relancé automatiquement. Cela limite la durée de chaque interruption, mais peut produire un état instable si l’attaquant continue d’envoyer les requêtes malveillantes. Les journaux montrent alors une alternance de démarrages et d’arrêts, parfois accompagnée d’une hausse de charge liée au cycle de redémarrage.

Effet de cascade sur la supervision et l’exploitation

Un frontal qui flappe perturbe les métriques, déclenche des alertes répétées et peut masquer d’autres événements. Les équipes NOC/SRE perdent en visibilité au moment même où l’incident nécessite une analyse rapide. Dans des environnements très automatisés, des mécanismes de remédiation peuvent même aggraver la situation en recyclant inutilement des instances saines mais non patchées.

Dégradation multi-tenant

Si un même nghttpx publie plusieurs applications ou plusieurs vhosts, une seule faille sur ce point d’entrée affecte potentiellement l’ensemble du portefeuille de services hébergés sur l’instance. C’est un enjeu classique chez les prestataires, dans les plateformes mutualisées ou sur les nœuds d’entrée de clusters internes.

Cette vulnérabilité rappelle une réalité opérationnelle : les composants orientés protocole, souvent perçus comme de simples “tuyaux”, sont en fait des actifs critiques. Leur surface d’attaque est exposée en permanence à des entrées non fiables. Une faiblesse de parsing ou de gestion d’état dans un proxy peut donc avoir un effet disproportionné par rapport à la simplicité apparente du bug.

Comment patcher

Le correctif est disponible via les mises à jour de sécurité Ubuntu publiées dans l’avis USN-8495-1. La remédiation prioritaire consiste à mettre à jour les paquets concernés depuis les dépôts de sécurité officiels Ubuntu, puis à redémarrer le service utilisant nghttpx si nécessaire.

Sur un hôte Ubuntu standard, la séquence de mise à jour est la suivante :

Selon le packaging exact de votre release Ubuntu, il peut être nécessaire de mettre à jour l’ensemble des paquets liés à nghttp2 plutôt qu’un nom unique. Pour identifier les paquets disponibles et leurs versions candidates :

Si votre politique d’exploitation préfère appliquer toutes les mises à jour de sécurité disponibles d’un coup :

Dans les environnements automatisés ou de type image immuable, il faut reconstruire l’image à partir d’une base Ubuntu intégrant déjà l’avis de sécurité, puis redéployer les instances. Sur un conteneur ou une image CI/CD, une simple mise à jour ponctuelle sur un nœud vivant ne suffit pas si le pipeline continue de produire des artefacts à partir d’une couche vulnérable.

Pour vérifier qu’une version corrigée a bien été installée :

Il faut comparer la version installée à la version corrigée indiquée pour votre release Ubuntu dans l’avis USN-8495-1. C’est cette correspondance, et non une version générique trouvée ailleurs, qui fait foi dans un environnement supporté par Ubuntu.

Après mise à jour, plusieurs contrôles opérationnels sont recommandés :

• vérifier l’état du service nghttpx ;
• contrôler les journaux système et applicatifs ;
• tester les endpoints exposés en HTTP et HTTPS ;
• surveiller les métriques de disponibilité et de redémarrage pendant quelques heures.

Exemples de commandes utiles :

Dans un environnement à haute disponibilité, le patch doit idéalement être déployé par rotation : retirer un nœud du pool, mettre à jour, redémarrer, vérifier, puis réintégrer avant de traiter le suivant. Cette approche réduit le risque d’interruption globale et permet de confirmer le comportement corrigé sur une instance avant généralisation.

Pour les équipes ayant des obligations de conformité ou de gestion de vulnérabilités, il est utile d’enregistrer dans le ticket de remédiation :

• la référence source USN-8495-1 ;
• les hôtes ou images concernés ;
• la version installée avant correctif ;
• la version corrigée déployée ;
• la date de redémarrage du service ;
• les preuves de validation post-patch.

Mitigation

Lorsque le patch ne peut pas être appliqué immédiatement, la réduction de surface doit viser le vecteur précis mentionné par l’avis : des requêtes HTTP/1.1 utilisant Upgrade, avec Content-Length et un corps. Aucune mitigation ne remplace le correctif, mais plusieurs mesures peuvent réduire l’exposition temporairement.

Filtrer ou restreindre les usages de Upgrade en amont

Si nghttpx est placé derrière un autre frontal, un CDN, un WAF ou un load balancer applicatif, il peut être possible de bloquer ou de journaliser les requêtes contenant l’en-tête Upgrade lorsque ce mécanisme n’est pas nécessaire au service rendu.

Le principe défensif est simple : si votre application n’a aucun besoin légitime de négociation via Upgrade sur ce point d’entrée, refuser ces requêtes réduit immédiatement la surface d’attaque. Cette mesure doit toutefois être validée fonctionnellement, car certains usages spécifiques ou intermédiaires réseau peuvent dépendre de comportements particuliers.

Sur un frontal intermédiaire capable de filtrer les en-têtes HTTP, il faut envisager des règles du type :

• bloquer les requêtes contenant Connection: Upgrade vers les services qui n’en ont pas l’usage ;
• bloquer les combinaisons Upgrade + Content-Length sur les routes non concernées ;
• journaliser ces requêtes pour identifier d’éventuels scans ou tentatives répétées.

La syntaxe exacte dépend du produit utilisé en amont. Comme l’avis source est Ubuntu et non un guide de configuration d’un WAF particulier, il faut adapter ces règles à votre pile réelle sans improviser de configuration en production.

Limiter l’exposition réseau

Si nghttpx n’a pas vocation à être accessible directement depuis Internet, la mitigation la plus efficace est souvent de réduire l’accès réseau :

• restriction par ACL ou groupe de sécurité ;
• exposition uniquement derrière un composant frontal mieux maîtrisé ;
• limitation à certains réseaux partenaires ou internes ;
• désactivation des interfaces d’écoute inutiles.

Sur des infrastructures cloud, cette étape passe par la revue des règles de sécurité attachées aux VM ou aux load balancers. Une instance Ubuntu exposée publiquement chez OVHcloud ou Scaleway avec un port applicatif ouvert “par défaut” peut se retrouver atteignable bien au-delà du besoin métier réel.

Activer des mécanismes de limitation et de résilience

Les protections de type rate limiting ne corrigent pas la vulnérabilité, mais elles peuvent ralentir une exploitation opportuniste ou rendre plus coûteux un bombardement automatisé. Selon l’architecture, cela peut inclure :

• limitation du nombre de connexions par source ;
• seuils de requêtes par seconde sur le frontal amont ;
• timeouts stricts sur les connexions incomplètes ;
• surveillance des erreurs et redémarrages anormaux.

Il faut toutefois rester lucide : si une seule requête correctement formée suffit à faire tomber le service, la limitation de débit n’empêche pas l’exploitation ciblée. Elle reste utile surtout contre les scans massifs et les tentatives répétées.

Renforcer le redémarrage supervisé sans s’y fier comme remède

Vérifier la politique de redémarrage de systemd peut améliorer la disponibilité pendant la fenêtre de risque :

Des options comme Restart=on-failure peuvent aider à remettre le service en ligne après un crash, mais elles ne doivent pas être considérées comme une correction. Si la requête malveillante reste possible, l’attaquant peut simplement reproduire l’arrêt. Cette mesure relève de la continuité de service, pas de la suppression de la cause.

Détection

La détection doit s’appuyer sur deux axes : les traces réseau/applicatives et les symptômes système. Le vecteur étant relativement spécifique, il est pertinent de rechercher les requêtes HTTP/1.1 comportant simultanément certains en-têtes.

Indicateurs de compromission ou d’exploitation

Dans le cas présent, il s’agit plutôt d’IoC d’activité malveillante ou de tentative d’exploitation que d’indicateurs de compromission persistante. Les éléments suivants méritent une investigation :

• présence répétée d’en-têtes Connection: Upgrade dans les logs d’accès ;
• présence d’un en-tête Upgrade sur des endpoints qui n’en ont pas l’usage normal ;
• requêtes HTTP/1.1 contenant à la fois Upgrade, Content-Length et un corps ;
• redémarrages inattendus du service nghttpx corrélés à ces requêtes ;
• pics d’erreurs 502, 503 ou de timeouts côté frontal.

Selon votre niveau de journalisation, il peut être utile de rechercher les chaînes suivantes :

Exemples de recherches côté système :

Si les logs d’accès du frontal sont centralisés, une corrélation par adresse source, fréquence et présence des en-têtes cités est recommandée. Une source unique envoyant à répétition des requêtes avec Upgrade vers un service qui ne l’utilise jamais est un signal faible mais utile. Une corrélation temporelle avec des chutes de service renforce fortement la suspicion.

Symptômes système à surveiller

• arrêts ou redémarrages du processus nghttpx ;
• augmentation du nombre d’unités systemd relancées ;
• dégradation soudaine de disponibilité sur les sondes externes ;
• hausse des erreurs de passerelle sur les applications en aval.

Sur les plateformes de supervision, il est pertinent de mettre en place temporairement des alertes spécifiques sur :

• le nombre de redémarrages du service ;
• les taux de réponse non 2xx/3xx du frontal ;
• la perte de connectivité sur les ports exposés par nghttpx.

Validation après remédiation

Une fois le correctif appliqué, il faut conserver une surveillance ciblée pendant un cycle d’exploitation raisonnable. L’objectif n’est pas seulement de vérifier la mise à jour, mais aussi de confirmer l’absence d’instabilité résiduelle et de détecter d’éventuelles tentatives d’exploitation toujours présentes sur Internet.

Dans les environnements à forte exposition, il n’est pas rare qu’un scan automatisé continue après patch. Si les requêtes suspectes persistent mais que le service reste stable, cela constitue un bon indicateur de remédiation effective, tout en rappelant l’utilité d’un filtrage complémentaire en amont.

Perspective écosystème

Cette vulnérabilité illustre un sujet récurrent dans la sécurité des infrastructures web : les composants de traduction ou de terminaison protocolaire concentrent une complexité importante. Entre HTTP/1.1, HTTP/2, la gestion de Upgrade, les corps de requêtes, les en-têtes persistants et les états de connexion, la robustesse d’un proxy dépend d’un grand nombre de cas limites.

Le fait qu’une faille soit déclenchée via HTTP/1.1 dans un composant associé à HTTP/2 n’a donc rien d’anecdotique. Au contraire, c’est typique des briques qui font l’interface entre plusieurs versions de protocole ou plusieurs modes de traitement. Plus un composant accepte de variations d’entrée, plus la discipline de patching et de réduction de surface devient importante.

Pour les organisations françaises, cette affaire s’inscrit aussi dans une logique de gouvernance technique :

• tenir un inventaire précis des reverse proxies réellement exposés ;
• différencier les paquets installés des services effectivement actifs ;
• suivre les avis éditeur et distribution, y compris Ubuntu et, selon les cas, les relais du CERT-FR lorsqu’un sujet a une portée plus large ;
• éviter les images figées trop longtemps sans reconstruction.

Beaucoup d’incidents de disponibilité ne viennent pas d’une absence totale de patch, mais d’un patch appliqué sur les serveurs “visibles” tandis que des nœuds moins évidents restent vulnérables : instance de secours, environnement de préproduction exposé, image d’autoscaling, nœud d’administration ou frontal secondaire. Une alerte comme USN-8495-1 doit donc déclencher non seulement une mise à jour, mais aussi une vérification d’alignement de l’ensemble du parc.

La source officielle à citer pour cette vulnérabilité reste l’avis Ubuntu USN-8495-1: nghttp2 vulnerability. C’est le document de référence pour les paquets Ubuntu concernés, les versions corrigées par release et les instructions de mise à jour via les dépôts de sécurité. Dans les processus de veille, il est judicieux de relier cet avis aux inventaires internes de services exposés afin d’identifier rapidement si nghttpx est utilisé comme frontal sur des applications critiques.

En pratique, la priorité est claire : mettre à jour immédiatement les paquets Ubuntu concernés, redémarrer les services exposant nghttpx, puis vérifier les journaux et la disponibilité. Si la mise à jour doit être planifiée, réduisez sans attendre la surface d’attaque en filtrant les usages non nécessaires de Upgrade et en limitant l’exposition réseau. Pour aller plus loin sur le durcissement des frontaux, des proxys et des services web exposés, voir aussi les recommandations de la catégorie /categorie/pratiques.