HTTP/2 Bomb : une nouvelle attaque DoS menace NGINX, Apache, IIS, Envoy et Cloudflare Pingora
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 :
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 :
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
Écrit par
larevuegeek
Commentaires (0)