Les attaques HTTP/2 Bomb ciblent depuis cette semaine les opérateurs télécoms et les organisations santé : un seul paquet HTTP/2 mal formé peut saturer un serveur web ou un load balancer en quelques secondes. Pour une PME-ETI qui expose une API, un site e-commerce ou un portail collaborateur derrière NGINX, Apache, HAProxy ou Cloudflare, l’exposition est réelle. Voici comment auditer puis durcir votre stack HTTP/2 avant le prochain coup de boutoir.
Comprendre les attaques HTTP/2 Bomb
La famille HTTP/2 Bomb exploite la nature multiplexée du protocole HTTP/2 : un client peut ouvrir des milliers de streams sur une seule connexion TCP, et chaque stream consomme de la mémoire et du CPU côté serveur. En envoyant des requêtes massivement compressées (HPACK bombs), des trames CONTINUATION sans fin, ou des resets en boucle (Rapid Reset, déjà vu en 2023-2024), un attaquant unique peut consommer la totalité des ressources d’un reverse proxy avec un débit réseau minimal.
Les variantes observées en juin 2026 ajoutent une couche de fragmentation des trames PRIORITY pour échapper aux WAF basés sur la signature, ce qui rend la détection par signature inefficace. Les opérateurs télécoms et les structures de soins sont les premières cibles parce que leurs portails sont historiquement sous-monitorés sur les couches L7.
Auditer son exposition HTTP/2 en PME-ETI
Avant de durcir, il faut savoir ce qui est exposé. Voici l’audit minimum à mener cette semaine :
- Lister les frontaux exposés : reverse proxies (NGINX, HAProxy, Traefik, Caddy), CDN (Cloudflare, Akamai, Fastly), API gateways (Kong, APISIX, AWS API Gateway). Tout ce qui termine HTTP/2 côté Internet est concerné.
- Vérifier les versions : NGINX < 1.27.x, Apache httpd < 2.4.62, HAProxy < 3.0, Caddy < 2.8 sont vulnérables sans backport. Pour HAProxy en particulier,
haproxy -vv | headdoit retourner une version récente. - Tester avec h2load : depuis une machine de test interne, lancer
h2load -n 10000 -c 100 -m 1000 https://votre-frontal/pour mesurer le comportement sous charge multiplexée — si la latence explose ou si le frontal redémarre, le risque est confirmé. - Lister les services internes en HTTP/2 : grpc internes, microservices, dashboards. Une attaque latérale après compromission initiale peut faire tomber tout le bus interne.
Durcir NGINX et Apache contre les attaques HTTP/2 Bomb
Le durcissement repose sur trois leviers : limiter les streams concurrents, plafonner les en-têtes compressés, et instaurer des timeouts agressifs.
NGINX (1.27.x et supérieur)
Dans le bloc http ou server du fichier de configuration NGINX :
http2_max_concurrent_streams 128;— limite le nombre de streams par connexion (défaut 128, à réduire à 64 si exposition publique sensible)http2_max_field_size 4k;— plafonne la taille d’un en-tête HPACK individuelhttp2_max_header_size 16k;— plafonne le total des en-têteskeepalive_timeout 30s;— réduit la durée d’une connexion idleclient_header_timeout 10s;etclient_body_timeout 10s;— coupe les clients lentslimit_req_zone $binary_remote_addr zone=h2:10m rate=50r/s;aveclimit_req zone=h2 burst=20 nodelay;— limite le débit par IP
Apache httpd (2.4.62 et supérieur)
Dans httpd.conf ou un fichier de configuration dédié :
H2MaxSessionStreams 100— limite les streams par sessionH2MaxHeaderListSize 16384— plafonne la liste des en-têtesH2StreamTimeout 30— timeout par streamTimeout 30— timeout général- Activer
mod_reqtimeoutavecRequestReadTimeout header=10-20,MinRate=500 body=10,MinRate=500
HAProxy (3.0 et supérieur)
tune.h2.max-concurrent-streams 100dans la sectionglobaltune.h2.header-table-size 4096timeout http-request 10settimeout client 30sdans lesdefaults- Ajouter une rate-limit par IP via
stick-table type ip size 100k expire 30s store http_req_rate(10s)
Détecter une attaque HTTP/2 Bomb en cours
La détection passe par l’observation de signaux faibles côté frontal : explosion du nombre de streams par connexion, ratio anormal de RST_STREAM, taille moyenne des trames PRIORITY supérieure à la normale. Les outils suivants permettent d’instrumenter rapidement :
- Wazuh avec un décodeur custom sur les logs NGINX/Apache, surveillance du compteur
$connection_requestset alerte si > 500 sur une seule connexion - Prometheus + nginx-prometheus-exporter : graph
nginx_http_requests_totalpar connexion, alerte sur dérivée brutale - Cloudflare Analytics ou équivalent CDN : activer la règle « HTTP/2 Stream Flood » dans le WAF managé, qui couvre désormais la variante 2026
- tcpdump + Wireshark en cas d’incident : filtre
http2.frame.type == 0x03pour isoler les RST_STREAM excessifs
Plan d’action 48h pour PME-ETI
- J+0 : inventaire des frontaux exposés (reverse proxies, CDN, API gateways) et de leur version exacte.
- J+1 : appliquer les patches NGINX/Apache/HAProxy listés ci-dessus, activer les directives de limitation des streams, redémarrer en heures creuses.
- J+2 : tester avec
h2loaddepuis une machine de pré-prod pour valider que les limites tiennent sous charge, brancher l’alerting Wazuh ou Prometheus, documenter le runbook incident.
Notre équipe a observé ces dernières semaines une augmentation des audits L7 demandés par les ETI suite à l’avis CISA BOD 26-04 sur la priorisation des vulnérabilités. La couche HTTP/2 est désormais un terrain de jeu d’attaque privilégié : notre tutoriel sur la CVE-2026-42945 NGINX et notre analyse de la directive CISA BOD 26-04 donnent le contexte stratégique pour cadrer ce chantier.
Conclusion : durcir HTTP/2, un chantier non négociable
Les attaques HTTP/2 Bomb ne sont pas une menace théorique : elles touchent en ce moment des télécoms et des organisations santé en production, avec un coût attaquant proche de zéro. Pour une PME-ETI, le durcissement des frontaux HTTP/2 est un investissement de quelques heures qui évite une indisponibilité de plusieurs jours. Patcher, plafonner les streams, instaurer des timeouts agressifs et brancher l’alerting — c’est le combo défensif minimum pour traverser l’été 2026 sans perdre votre portail public.