Des chercheurs ont révélé une technique de déni de service HTTP/2 affectant les principaux serveurs web. La faille liée aux configurations du protocole a été découverte grâce à une analyse assistée par IA.
Les chercheurs en sécurité mettent en garde contre un problème lié à la configuration par défaut du protocole HTTP/2 utilisée par les principaux serveurs web. Celui-ci aurait échappé à plus d’une décennie de vérifications humaines avant d’être détectée lors d’une analyse assistée par Codex d’OpenAI. Selon le cabinet de conseil en sécurité Calif, cette vulnérabilité a rendu possible une attaque par déni de service (DoS) sur des serveurs web comme nginx, le serveur Http Apache, Microsoft IIS, Envoy et Pingora de Cloudflare.
Introduit en 2015 pour augmenter la vitesse du protocole HTTP, HTTP/2 permet plusieurs connexions simultanées. Il est progressivement remplacé par le HTTP/3, qui repose sur le dernier protocole de transport chiffré QUIC. Le problème mis au jour par Calif réside dans la manière dont les serveurs affectés gèrent la compression des en-têtes et le traitement des requêtes, ce qui permet à un attaquant de déclencher une consommation de mémoire disproportionnée. « L’attaque combinait deux techniques connues depuis une dizaine d’années : une bombe de compression et un blocage de type Slowloris », a déclaré Thai Duong, CEO de Calif, dans un article de blog où il qualifie cette technique de « HTTP/2 Bomb ». « Une recherche sur Shodan a révélé que plus de 880 000 sites web prennent en charge le HTTP/2 et exécutent l’un de ces serveurs, même si un nombre de ces sites utilisent un réseau de diffusion de contenu (CDN), ce qui peut ajouter une certaine complexité à l’attaque », a-t-il précisé.
Une fonctionnalité de compression exploitée
La faille, référencée CVE-2026-49975, concerne Hpack, le mécanisme de compression d’en-têtes intégré à HTTP/2. Calif a découvert que les attaquants peuvent exploiter la table d’en-têtes dynamique du protocole de manière à forcer les serveurs à allouer de manière répétée de la mémoire bien au-delà de ce qui serait normalement attendu compte tenu de la taille des requêtes entrantes. « Une quantité relativement faible de trafic contrôlé par l’attaquant peut déclencher des allocations de mémoire excessives sur le serveur cible », a expliqué M. Duong. « La bombe cible Hpack, le schéma de compression d’en-tête de HTTP/2 : un octet sur le réseau se transforme en une allocation d’en-tête complète sur le serveur, répétée des milliers de fois par requête », a-t-il ajouté. « Le blocage est une fenêtre de contrôle de flux de zéro octet qui empêche le serveur d’en libérer la moindre partie. »
Ce n’est pas la première fois que le HTTP/2 a été pointé du doigt dans des attaques par déni de service. En 2019, plusieurs vulnérabilités de déni de service HTTP/2 révélées par Netflix ont affecté de nombreuses implémentations de serveurs et ont nécessité des correctifs d’urgence à travers l’écosystème. En octobre 2023, il a été révélé que le protocole était vulnérable à des attaques DDoS de grande ampleur en raison de sa capacité de multiplexage de flux. Dans son article, M. Duong a rappelé comment, en 2012, il avait contribué à la découverte et à la correction d’une faille dans Hpack, alors exploitée par une autre attaque baptisée Crime. « J’étais trop obnubilé par la lutte contre Crime et j’ai laissé passer la bombe », a-t-il reconnu. Calif a signalé la faille à tous les projets concernés. nginx et Apache HTTP Server ont agi rapidement pour bloquer la voie d’attaque, tandis qu’Envoy a publié un correctif le 3 juin. Microsoft IIS et Pingora de Cloudflare n’avaient pas encore publié de correctifs au moment de la publication de cet article. Les administrateurs devront se procurer les versions corrigées de nginx (v1.29.8+) ou d’Apache (mod_http2 v2.0.41) via les canaux de mise à jour habituels utilisés pour ces produits. Envoy a publié des correctifs pour les versions 1.35.11, 1.36.7, 1.37.3 et 1.38.1. Pour les entreprises ne disposant pas de correctif, Calif a recommandé de désactiver HTTP/2 si possible, ou de « placer en frontale du serveur un élément imposant une limite stricte au nombre d’en-têtes par requête ».