# HTTP/2 Bomb: une attaque DoS à qualifier sur nginx, Apache, Envoy, IIS et Pingora > HTTP/2 Bomb: point opérationnel sur cette attaque DoS HTTP/2 par amplification HPACK, versions touchées, correctifs et mitigations. - URL canonique : [https://forgetaboutit.fr/blog/http2-bomb-deni-service-hpack-http2/](https://forgetaboutit.fr/blog/http2-bomb-deni-service-hpack-http2/) - Publication : 2026-06-08T11:00:00.000Z - Catégorie : Sécurité - Sujets : HTTP/2, HTTP/2 Bomb, HPACK, Déni de service, nginx, Apache, Envoy, Patch management Dans le cadre de notre **veille sécurité**, nous signalons **HTTP/2 Bomb**, une attaque de déni de service publiée par **Calif** début juin 2026. Le sujet mérite une qualification rapide pour les infrastructures qui exposent du **HTTP/2** sur Internet: reverse proxies, fronts TLS, API gateways, CDN internes, ingress Kubernetes, load balancers applicatifs et serveurs web publics. L'attaque ne cherche pas à exécuter du code. Elle vise plus simple et souvent plus efficace: **faire consommer beaucoup de mémoire au serveur avec très peu de trafic côté attaquant**, puis garder cette mémoire occupée suffisamment longtemps pour rendre le service lent, instable ou indisponible. Les implémentations citées par Calif sont notamment: - **nginx**; - **Apache httpd** avec `mod_http2`; - **Microsoft IIS**; - **Envoy**; - **Cloudflare Pingora**. ## Pourquoi HTTP/2 Bomb est sérieuse HTTP/2 Bomb combine deux idées déjà connues, mais dangereuses lorsqu'elles sont chaînées. La première est une amplification liée à **HPACK**, le mécanisme de compression des en-têtes HTTP/2. Un client peut insérer un en-tête dans une table dynamique, puis le référencer de nombreuses fois avec très peu d'octets sur le réseau. Côté serveur, chaque référence peut provoquer de nouvelles allocations mémoire. La seconde est un blocage de fenêtre HTTP/2, dans l'esprit des attaques lentes de type Slowloris. Le client annonce une fenêtre de flux à zéro pour empêcher le serveur d'envoyer normalement sa réponse. Résultat: les structures associées à la requête peuvent rester en mémoire au lieu d'être libérées rapidement. Dit simplement: **l'amplification crée la mémoire consommée, le blocage de fenêtre la garde vivante**. C'est ce chaînage qui change la lecture opérationnelle. Une limite sur la taille totale des en-têtes décodés ne suffit pas toujours si le problème vient du **nombre** d'en-têtes ou du coût interne de chaque entrée. À l'inverse, une amplification modérée peut devenir destructrice si l'attaquant peut maintenir les flux ouverts à très faible coût. ## Ce que l'attaque exploite concrètement HTTP/2 repose sur des mécanismes légitimes: - HPACK réduit le volume des en-têtes répétés; - le multiplexage permet plusieurs flux dans une même connexion; - le contrôle de flux évite qu'un émetteur sature un récepteur; - les cookies HTTP/2 peuvent être découpés en plusieurs champs. Le problème apparaît quand ces mécanismes se composent mal dans certaines implémentations. Selon Calif, l'attaquant peut: 1. créer une entrée HPACK dynamique; 2. envoyer des milliers de références compactes vers cette entrée; 3. provoquer côté serveur des allocations répétées par flux; 4. annoncer une fenêtre de réponse à zéro; 5. envoyer périodiquement de minuscules `WINDOW_UPDATE` pour maintenir les flux; 6. conserver la pression mémoire sans envoyer un volume réseau proportionnel. Les démonstrations publiées donnent des ordres de grandeur très parlants: nginx et IIS sont annoncés autour de quelques dizaines de fois d'amplification, tandis qu'Apache httpd et Envoy montent beaucoup plus haut dans les scénarios testés. Le point important n'est pas seulement le ratio. C'est la capacité à **tenir** la mémoire en place. Dans un cas réel, l'objectif d'un attaquant n'est pas forcément de tuer immédiatement un worker. Un OOM peut parfois redémarrer proprement. Le scénario plus pénible consiste à maintenir la machine proche de la saturation mémoire, déclencher du swap, ralentir tous les autres traitements et dégrader progressivement la disponibilité. ## Produits et correctifs au 8 juin 2026 L'état évolue vite. Au moment de publier cet article, le **8 juin 2026**, voici la lecture opérationnelle à retenir.
Composant Risque cité Action prioritaire
nginx Bomb HPACK avec en-têtes très nombreux et blocage de fenêtre. Mettre à jour vers nginx 1.29.8 ou version corrigée fournie par votre distribution. La directive max_headers est ajoutée avec une valeur par défaut de 1000.
Apache httpd / mod_http2 Amplification via fragments Cookie et comptage insuffisant contre LimitRequestFields. Suivre les paquets de votre distribution ou passer à mod_http2 2.0.41 quand applicable. La faille est suivie sous CVE-2026-49975.
Envoy Consommation mémoire via cookies, amplification HPACK et durée de vie prolongée des flux. Appliquer les versions corrigées annoncées par l'avis Envoy: 1.35.11, 1.36.7, 1.37.3 ou 1.38.1. La faille est suivie sous CVE-2026-47774.
Cloudflare Pingora Options HTTP/2 par défaut trop permissives dans certains cas. Vérifier l'usage de Pingora et viser la version 0.8.1 ou ultérieure, citée dans l'échange public du projet comme contenant le correctif.
Microsoft IIS Variante HTTP/2 Bomb citée par Calif. Suivre les bulletins Microsoft, réduire l'exposition HTTP/2 si possible et placer des protections amont lorsque c'est pertinent.
Comme toujours, les versions upstream ne racontent pas toute l'histoire. Les distributions backportent souvent les correctifs sans changer le numéro de version principal. Il faut donc suivre les avis de sécurité de votre distribution ou de votre éditeur, pas seulement comparer une chaîne de version. ## Êtes-vous concerné ? La première question est simple: **où terminez-vous du HTTP/2 ?** Les points à regarder en priorité: - reverse proxies Internet; - serveurs nginx ou Apache exposés directement; - ingress Kubernetes; - proxies Envoy ou gateways API; - appliances ou images Docker qui embarquent leur propre serveur HTTP/2; - fronts TLS qui négocient `h2` via ALPN; - CDN privés ou couches de protection maison. Vous pouvez vérifier la négociation HTTP/2 avec un test TLS côté client: ```bash openssl s_client -alpn h2 -connect exemple.com:443 /dev/null | grep -i 'ALPN protocol' ``` Si la sortie annonce `h2`, le service accepte HTTP/2 sur cette terminaison. Ce n'est pas une preuve de vulnérabilité, mais c'est un bon point de départ pour l'inventaire. Avec `curl`, selon les options compilées dans votre version: ```bash curl --http2 -I https://exemple.com/ ``` Sur un serveur nginx: ```bash nginx -V 2>&1 nginx -T | grep -nE 'listen .*http2|http2|large_client_header_buffers|max_headers' ``` Sur Apache httpd: ```bash apachectl -M | grep -i http2 apachectl -t -D DUMP_VHOSTS ``` L'objectif n'est pas de reproduire le PoC. L'objectif est d'identifier les terminaisons HTTP/2 réellement exposées, leur rôle, leur version corrigée ou non, et leur capacité à être patchées ou temporairement basculées en HTTP/1.1. ## Mesures immédiates La réponse saine est courte: **patcher les terminaisons HTTP/2 exposées**. Mais dans l'exploitation réelle, il faut parfois tenir compte d'une fenêtre de maintenance, d'un CDN, d'un équilibreur, d'une image applicative figée ou d'un éditeur tiers. Dans ce cas, la priorité est de réduire le risque sans casser inutilement la production. ### Mettre à jour les composants concernés Pour nginx, Apache httpd, Envoy et Pingora, vérifiez les bulletins de votre distribution ou les versions upstream corrigées. Ne vous limitez pas à l'hôte principal: les conteneurs, images de base, appliances, ingress et environnements de staging exposés comptent aussi. Après mise à jour, redémarrez ou rechargez réellement le service concerné, puis vérifiez le processus actif. Un paquet corrigé installé mais un worker ancien encore en mémoire ne protège pas grand-chose. ### Désactiver HTTP/2 si le patch doit attendre Si vous ne pouvez pas patcher immédiatement et que l'impact fonctionnel est acceptable, désactiver HTTP/2 sur la terminaison exposée reste une mitigation directe. Pour Apache httpd, la mitigation courante consiste à forcer HTTP/1.1 sur le virtual host concerné: ```apache Protocols http/1.1 ``` Pour nginx, selon la branche et la configuration, la désactivation peut passer par la configuration HTTP/2 disponible dans votre version. Les bulletins Red Hat citent notamment: ```nginx http2 off; ``` Sur des configurations plus anciennes, HTTP/2 peut aussi être activé via le paramètre `http2` de la directive `listen`. La bonne commande dépend donc de votre version et doit être validée avec `nginx -t` avant rechargement. ### Imposer des limites en amont HTTP/2 Bomb rappelle qu'il ne faut pas seulement limiter la taille totale des en-têtes. Il faut aussi limiter: - le nombre d'en-têtes par requête; - le nombre de fragments `Cookie`; - la taille décodée réelle après HPACK; - le nombre de flux concurrents; - la durée de vie d'un flux bloqué; - la mémoire disponible par worker, service ou conteneur. Cette dernière limite n'est pas un correctif, mais elle améliore le mode de défaillance. Un worker OOM-killé et redémarré rapidement est souvent préférable à une machine entière qui part en swap et dégrade tous les services voisins. ## Ce que cette faille dit de l'exploitation moderne HTTP/2 Bomb n'est pas seulement une alerte de version. C'est un bon exemple de vulnérabilité de composition. Chaque mécanisme pris isolément a une raison d'exister: - compresser les en-têtes pour réduire la bande passante; - multiplexer les requêtes; - contrôler le flux; - tolérer certains formats de cookies; - laisser les implémentations choisir leurs limites. Mais une infrastructure ne tombe pas toujours parce qu'une seule brique est "cassée". Elle tombe parfois parce que plusieurs comportements raisonnables, placés ensemble, créent une asymétrie exploitable. C'est la même logique que nous rappelions dans notre article sur [l'IA et la cybersécurité](/blog/ia-cybersecurite-remede-accelerateur-crise/): la découverte, la compréhension et l'industrialisation des chaînes d'exploitation s'accélèrent. Ici, Calif indique que l'attaque a été découverte avec l'aide de Codex en combinant deux techniques connues depuis des années. Pour les équipes d'exploitation, la conséquence est très concrète: une veille sécurité efficace ne peut pas se limiter aux CVE avec un score élevé. Elle doit aussi regarder les protocoles, les configurations par défaut, les composants exposés et les capacités de mitigation rapide. ## Notre lecture opérationnelle HTTP/2 Bomb concerne une couche très exposée: le frontal web. Même si l'impact est un déni de service, il peut être critique pour un SaaS, un e-commerce, une API publique ou un réseau de franchises qui dépend d'applications centralisées. Le bon réflexe n'est ni la panique, ni l'attente passive. Il faut qualifier: - où HTTP/2 est activé; - quels composants terminent réellement les connexions `h2`; - quelles versions sont en production; - quels correctifs sont disponibles dans les canaux utilisés; - si une désactivation temporaire de HTTP/2 est acceptable; - quelles limites existent sur les en-têtes, les flux et la mémoire; - quels services métier seraient touchés par une indisponibilité du frontal. C'est exactement le rôle d'une [veille CVE quotidienne](/blog/suivi-cve-pourquoi-quotidien/) intégrée à l'infogérance: transformer une publication technique en décisions concrètes, contextualisées, vérifiées et traçables. Le sujet rejoint aussi nos alertes précédentes sur [Nginx Rift](/blog/faille-nginx-rift-cve-2026-42945/) et sur la [protection anti-DDoS avec Cloudflare et WAF](/blog/protection-anti-ddos-cloudflare-waf/): les couches frontales ne sont pas de simples tuyaux. Ce sont des composants critiques, exposés, qui doivent être versionnés, durcis, surveillés et testés. ## Conclusion **HTTP/2 Bomb** est une attaque de déni de service sérieuse parce qu'elle vise des configurations HTTP/2 courantes et transforme un faible volume de trafic en pression mémoire durable. Le bon réflexe: - inventorier les terminaisons HTTP/2 exposées; - patcher nginx, Apache httpd, Envoy, Pingora ou les paquets de distribution concernés; - suivre les bulletins Microsoft pour IIS; - désactiver HTTP/2 temporairement si le patch doit attendre et si le métier l'accepte; - imposer des limites strictes sur les en-têtes, les cookies, les flux et la mémoire; - surveiller les croissances mémoire anormales, les OOM et les resets HTTP/2. Si vous avez besoin d'aide pour qualifier vos fronts web, organiser les mises à jour ou mettre en place des mesures de réduction du risque, nous pouvons vous accompagner dans le cadre de notre [infogérance](/infogerance/). - [Découvrir notre offre d'infogérance](/infogerance/) - [Nous contacter](/contact/) - [Prendre rendez-vous](https://koalendar.com/e/faboutit) ## Sources - Calif - Codex Discovered a Hidden HTTP/2 Bomb - Calif - dépôt GitHub HTTP/2 Bomb, write-ups et PoC défensifs - Red Hat - RHSB-2026-007 HTTP/2 HPACK Denial of Service - Envoy - GHSA-22m2-hvr2-xqc8 / CVE-2026-47774 - nginx - commit ajoutant la directive max_headers - Apache httpd - mise à jour mod_http2 2.0.41 - Cloudflare Pingora - discussion publique autour des options HTTP/2 sûres par défaut ## FAQ: HTTP/2 Bomb ### Qu'est-ce que HTTP/2 Bomb ? HTTP/2 Bomb est une attaque de déni de service à distance qui combine une amplification HPACK, le mécanisme de compression des en-têtes HTTP/2, et un blocage de fenêtre de flux pour maintenir la mémoire allouée côté serveur. ### Quels serveurs sont concernés par HTTP/2 Bomb ? Les recherches publiées par Calif citent nginx, Apache httpd, Microsoft IIS, Envoy et Cloudflare Pingora. L'exposition exacte dépend de la version, de la configuration HTTP/2 et des correctifs disponibles. ### HTTP/2 Bomb permet-elle une exécution de code ? Non. L'impact décrit est un déni de service par consommation mémoire. Le risque principal est l'indisponibilité du frontal HTTP/2 ou du reverse proxy. ### Quelles versions corrigent HTTP/2 Bomb ? Au 8 juin 2026, nginx 1.29.8 ajoute une limite `max_headers`, Apache `mod_http2` 2.0.41 corrige le comptage des cookies, Envoy annonce des versions corrigées 1.35.11, 1.36.7, 1.37.3 et 1.38.1, et Pingora indique une correction en 0.8.1. ### Que faire si l'on ne peut pas patcher immédiatement ? La mitigation la plus directe est de désactiver HTTP/2 sur les terminaisons exposées quand c'est acceptable, ou de placer en amont un composant capable d'imposer des limites strictes sur le nombre et la taille des en-têtes.