HTTP/2 Bomb, c’est le nom d’une nouvelle attaque capable de faire planter un serveur Web en moins d’une minute, le rendant inaccessible en saturant la mémoire vive de la machine cible. Découverte grâce à l’assistance de l’IA, cette faille affecte les serveurs les plus populaires comme NGINX, Apache, ou encore IIS.

L’alliance de deux techniques bien connues

Cette vulnérabilité identifiée dans le protocole HTTP/2 a été mise en lumière par les chercheurs en sécurité de chez Calif, qui mentionnent que cette découverte a été possible grâce à l’utilisation de l’agent Codex d’OpenAI. Cette nouvelle technique nommée HTTP/2 Bomb s’appuie sur deux méthodes de déni de service existantes :

• L’amplification de la compression HPACK
• La rétention de ressources de type Slowloris via le blocage du contrôle de flux HTTP/2.

Dans la pratique, l’attaquant abuse du mécanisme HPACK, utilisé par HTTP/2 pour compresser les en-têtes, en insérant un en-tête dans la table dynamique HPACK. L’attaque consiste à faire référence à cet en-tête de manière répétée, ce qui va engendrer l’allocation de milliers d’octets de mémoire côté serveur. Pour un octet initial, les ratios d’amplification au niveau du serveur Web sont ensuite énormes : 4 000:1 pour Apache httpd, par exemple.

Mais ceci n’est que la première phase de l’attaque. La seconde phase consiste à empêcher le serveur de libérer la mémoire une fois la requête terminée. En effet, le phénomène d’amplification est intéressant mais il ne suffit pas à lui seul, avec une requête, à saturer le serveur. Ainsi, l’attaquant annonce une fenêtre de contrôle de flux de zéro octet, ce qui empêche le serveur de libérer la mémoire une fois la requête terminée.

De plus, pour éviter les déconnexions de type timeout, le serveur envoie périodiquement de petites trames au lieu de transmettre la réponse globale. Résultat : les requêtes ne se terminent jamais et la mémoire allouée s’accumule indéfiniment.

Des serveurs web mis à genoux en quelques secondes

Cette attaque est redoutable pour deux raisons :

• Elle affecte les serveurs Web les plus utilisés au monde,
• Elle est réalisable avec peu de ressources puisqu’un ordinateur personnel avec une connexion de 100 Mbps peut suffire.

C’est d’ailleurs ce qui est mis en avant par les chercheurs de Calif : “Un ordinateur domestique disposant d’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 retenir 32 Go de mémoire de serveur en environ 20 secondes.”

Plusieurs tests ont été menés contre des solutions connues permettant de monter un serveur Web, en ciblant des configurations par défaut. En moins d’une minute, la RAM est saturée dans l’ensemble des scénarios.

Voici ces données présentées sous forme de tableau comparatif :

Comment se protéger face à HTTP/2 Bomb ?

L’utilisation d’un CDN, d’un reverse proxy ou d’un WAF peut permettre de se protéger de cette attaque. Ceci pour deux raisons : les requêtes sont filtrées (donc ici, il convient de limiter le nombre d’en-têtes acceptés) et les ressources plus importantes, ce qui permet d’atténuer ce type d’attaque. Le fait de ne pas utiliser HTTP/2 permet aussi de se protéger, mais HTTP/2 est la norme aujourd’hui.

En parallèle, il y a eu aussi une réaction des équipes de développement des différentes solutions :

• NGINX : le problème est résolu dans la version 1.29.8 grâce à l’ajout d’une directive .
• Apache httpd : le bug a été corrigé dans le module en version 2.0.41.
• Envoy : un patch de sécurité a été publié le 3 juin 2026.
• Microsoft IIS et Cloudflare Pingora : aucun correctif n’est disponible pour le moment.

“Nous avons signalé ce problème à Apache le 27 mai, et Stefan Eissing l’a corrigé le jour même en faisant en sorte que les en-têtes de cookies soient pris en compte dans le calcul de LimitRequestFields. Ce problème a reçu le numéro CVE-2026-49975.”, précisent les chercheurs dans leur rapport.

Enfin, sachez que le chercheur Quang Luong présentera d’ailleurs l’intégralité des détails techniques lors de la conférence Real World AI Security à la fin de ce mois. En attendant, ces scripts PoC sont disponibles sur ce dépôt GitHub.