Une nouvelle attaque par déni de service, appelée Bombe HTTP/2, peut être lancée depuis un seul ordinateur pour paralyser des serveurs web en quelques secondes.
Cette technique fonctionne sur les configurations par défaut du protocole HTTP/2 des principaux serveurs web, comme NGINX, Apache HTTP Server, Microsoft IIS, Envoy et Cloudflare Pingora.
Des chercheurs de l’entreprise de sécurité offensive Calif ont découvert cette attaque. Ils ont utilisé l’agent logiciel Codex d’OpenAI pour combiner deux méthodes de déni de service HTTP/2 connues. La première exploite l’amplification de la compression HPACK. La seconde retient des ressources comme le ferait une attaque Slowloris, mais en bloquant le contrôle de flux HTTP/2.
Lorsqu’elles sont combinées, un seul client sur une connexion de 100 Mbps peut saturer des dizaines de gigaoctets de mémoire vive en quelques secondes. L’attaque force le serveur à allouer de la mémoire, puis elle l’empêche de la libérer.
Les chercheurs affirment qu’un ordinateur personnel sur une connexion de 100 Mbps peut rendre un serveur vulnérable inaccessible en quelques secondes. Contre Apache httpd et Envoy, un seul client peut consommer et conserver 32 Go de mémoire serveur en à peu près 20 secondes.
L’attaque Bombe HTTP/2 abuse du mécanisme HPACK que le protocole HTTP/2 utilise pour la compression des en-têtes. L’attaquant insère un en-tête dans la table dynamique HPACK, puis il y fait référence de façon répétée grâce à une représentation indexée compacte qui peut ne faire qu’un octet.
Un octet envoyé par l’attaquant peut alors entraîner l’allocation de milliers d’octets de mémoire côté serveur. Les ratios les plus élevés ont été observés sur Envoy et Apache httpd, avec respectivement 5 700 pour 1 et 4 000 pour 1.
La seconde partie de l’attaque consiste à empêcher la libération de la mémoire une fois la requête terminée. Pour y parvenir, l’attaquant annonce une fenêtre de contrôle de flux de zéro octet. Le serveur ne peut pas envoyer de réponse, alors il envoie périodiquement de minuscules trames WINDOW_UPDATE pour éviter les dépassements de délai.
Dans ce scénario, les requêtes ne sont jamais complètement terminées, et la mémoire allouée continue de croître sans être libérée.
Les chercheurs de Calif précisent que cette approche contourne les défenses existantes, comme les limites sur la taille totale des en-têtes décodés. Les valeurs d’en-tête utilisées dans l’attaque sont minuscules, et l’amplification provient de la comptabilité interne par en-tête et des allocations de mémoire.
Lors de leurs tests contre quatre serveurs web majeurs, les chercheurs ont obtenu les résultats suivants :
- Envoy 1.37.2 a épuisé 32 Go de RAM en environ 10 secondes.
- Apache httpd 2.4.67 a épuisé 32 Go de RAM en ~18 secondes.
- nginx 1.29.7 a épuisé 32 Go de RAM en ~45 secondes.
- IIS (Windows Server 2025) a épuisé 64 Go de RAM en ~45 secondes.
Les détails techniques complets de l’attaque Bombe HTTP/2 seront révélés lors de la conférence Real World AI Security plus tard ce mois-ci, dans une présentation du chercheur Quang Luong.
Cependant, des preuves de concept pour cette nouvelle méthode d’attaque ont déjà été publiées.
Source : Calif
Impact et correctifs
Les chercheurs de Calif soulignent que, bien qu’aucune des deux parties de leur attaque ne soit particulièrement nouvelle, leur combinaison a un impact significatif.
Ils notent que les spécifications de l’algorithme HPACK se concentrent sur les risques d’amplification de la mémoire, mais qu’elles n’abordent pas ce qui se passe quand un attaquant conserve la mémoire allouée indéfiniment via le contrôle de flux HTTP/2.
Pourtant, tous les serveurs web ne sont pas vulnérables à la Bombe HTTP/2. Des correctifs ont déjà été publiés pour certaines plateformes. De plus, certaines configurations de serveur personnalisées peuvent offrir une protection indirecte contre l’attaque.
Par exemple, les systèmes qui fonctionnent derrière des CDN ou des proxies inverses n’exposent pas le point de terminaison HTTP/2 vulnérable, ce qui les rend plus difficiles à cibler. Certains déploiements peuvent aussi avoir des limites personnalisées sur le nombre d’en-têtes, des pare-feux applicatifs, des proxies inverses, ou le protocole HTTP/2 désactivé.
Le problème a été corrigé dans nginx version 1.29.8, qui a ajouté une directive ‘max_headers’, et sur Apache httpd mod_http2 2.0.41, où le problème s’est vu attribuer l’identifiant CVE-2026-49975.
Au moment de la rédaction, aucun correctif n’est disponible pour IIS, Envoy ou Pingora. Pour ces serveurs web, il est recommandé de désactiver HTTP/2 si c’est possible, et de placer un proxy ou un pare-feu qui impose des limites strictes sur le nombre d’en-têtes.