Article

HTTP/2 Bomb : une nouvelle attaque DoS menace NGINX, Apache, IIS, Envoy et Cloudflare Pingora

L
larevuegeek Auteur
5 juin 2026 3 vues

Une nouvelle technique d’attaque baptisée HTTP/2 Bomb vient d’être dévoilée par la société de sécurité Calif. Elle vise les configurations HTTP/2 par défaut de plusieurs serveurs web majeurs, dont NGINX, Apache httpd, Microsoft IIS, Envoy et Cloudflare Pingora. L’impact est sérieux : un attaquant distant pourrait provoquer un déni de service en saturant rapidement la mémoire du serveur.

Une faille qui exploite HTTP/2 et HPACK

HTTP/2 Bomb repose sur une combinaison de deux techniques déjà connues : une bombe de compression et une attaque de type Slowloris. La première cible HPACK, le mécanisme de compression des en-têtes utilisé par HTTP/2. La seconde consiste à maintenir les connexions ouvertes afin d’empêcher le serveur de libérer les ressources allouées.

Concrètement, l’attaque envoie des requêtes HTTP/2 conçues pour générer de nombreuses allocations mémoire côté serveur. Le piège vient du fait que l’amplification ne repose pas sur de gros en-têtes visibles, mais sur la mémoire utilisée par le serveur pour gérer chaque entrée. Les limites classiques sur la taille des en-têtes décodés peuvent donc ne pas suffire.

Un déni de service possible avec peu de bande passante

Le scénario décrit par les chercheurs est préoccupant : une seule machine disposant d’une connexion domestique pourrait rendre un serveur vulnérable indisponible en quelques secondes. Dans certains tests, un client unique pourrait immobiliser jusqu’à 32 Go de mémoire sur Apache httpd et Envoy en une vingtaine de secondes.

La vulnérabilité est suivie sous l’identifiant CVE-2026-49975. Elle est décrite comme un exploit de déni de service distant touchant plusieurs serveurs web majeurs dans leur configuration HTTP/2 par défaut.

Quels serveurs sont concernés ?

Les produits mentionnés comme affectés sont :

NGINX
Apache HTTP Server
Microsoft IIS
Envoy
Cloudflare Pingora

Pour NGINX, la recommandation est de passer en version 1.29.8 ou supérieure, qui introduit une directive max_headers avec une valeur par défaut de 1000. En l’absence de mise à jour, la désactivation de HTTP/2 peut servir de mesure temporaire.

Pour Apache httpd, le correctif est disponible dans mod_http2 v2.0.41. Si la mise à jour n’est pas immédiatement possible, désactiver HTTP/2 peut également limiter le risque.

Que doivent faire les administrateurs ?

La priorité est de vérifier si HTTP/2 est activé sur les serveurs exposés à Internet. Pour les environnements critiques, il est recommandé de :

appliquer les mises à jour disponibles ;
limiter le nombre d’en-têtes acceptés lorsque le serveur le permet ;
désactiver temporairement HTTP/2 si aucun correctif n’est disponible ;
surveiller les pics anormaux de mémoire et les connexions HTTP/2 maintenues ouvertes trop longtemps.

Pour IIS, Envoy et Cloudflare Pingora, les informations publiques indiquaient encore l’absence de correctif complet au moment des premières publications. Les administrateurs doivent donc suivre les avis officiels de leurs fournisseurs et appliquer les mitigations dès qu’elles sont disponibles.

Pourquoi cette faille est notable

HTTP/2 Bomb rappelle que les attaques DoS modernes ne reposent pas forcément sur un énorme volume de trafic. Ici, le danger vient plutôt d’un déséquilibre entre le coût très faible côté attaquant et la consommation mémoire importante côté serveur.

Le point le plus inquiétant est que l’attaque vise des comportements présents dans des configurations par défaut. Pour les hébergeurs, fournisseurs cloud, administrateurs système et équipes DevOps, cette faille mérite donc une attention rapide, même si elle ne permet pas l’exécution de code à distance.

Partager cet article

Partager
L

Écrit par

larevuegeek

Commentaires (0)

Connectez-vous pour laisser un commentaire.