HTTP/2 Bomb : DoS critique sur NGINX, Apache, IIS et Envoy

Une nouvelle famille d’attaques surnommée HTTP/2 Bomb vise plusieurs implémentations majeures du protocole HTTP/2 côté serveurs web, reverse proxies et passerelles d’API. Les produits explicitement cités dans les premières communications publiques incluent NGINX, Apache HTTP Server, Microsoft IIS, Envoy, HAProxy et, plus largement, d’autres piles HTTP/2 susceptibles de mal gérer certaines séquences de trames spécialement forgées. Le scénario est particulièrement préoccupant pour les environnements exposés sur Internet : l’attaque est menée à distance, sans authentification, et son objectif est le déni de service par saturation CPU, épuisement mémoire, contention sur les workers ou dégradation brutale de la capacité à traiter des requêtes légitimes.

À ce stade, l’enjeu principal n’est pas une compromission de données ni une exécution de code, mais une indisponibilité applicative potentiellement large, notamment sur les architectures où HTTP/2 est activé par défaut entre client et frontal web. Cela touche directement les sites e-commerce, API publiques, portails clients, applications SaaS et plateformes multi-tenant. Les hébergeurs et fournisseurs d’infrastructure courants du marché francophone, comme OVHcloud, Scaleway ou o2switch, peuvent être concernés indirectement dès lors que les clients s’appuient sur des images, appliances ou configurations activant HTTP/2 en frontal.

La source médiatique ayant popularisé l’alerte est The Hacker News, relayant une faiblesse transversale affectant plusieurs implémentations. La source technique à privilégier reste toutefois les advisories officielles des éditeurs et, lorsqu’il y en a, les bulletins des équipes de réponse comme CERT-FR. Au moment de la diffusion initiale, la situation est évolutive : selon les produits, les correctifs peuvent prendre la forme d’une mise à jour logicielle, d’un durcissement de paramètres de flux HTTP/2, d’un ajustement de limites de concurrence, ou d’une désactivation temporaire du protocole sur les surfaces les plus exposées.

Le score CVSS et l’attribution exacte des CVE peuvent varier selon l’implémentation concernée. Il ne s’agit pas toujours d’une seule CVE transversale unique, car chaque serveur ou proxy peut présenter une faiblesse distincte dans sa gestion des flux, de l’ordonnancement des trames, des fenêtres de contrôle, de la priorisation ou des mécanismes de buffering. En pratique, les équipes sécurité doivent traiter le sujet comme une campagne de durcissement HTTP/2 : identifier l’exposition, cartographier les composants, appliquer les versions corrigées lorsqu’elles sont disponibles, et déployer immédiatement des mitigations réseau et applicatives.

Source d’origine mentionnée publiquement : l’alerte relayée par The Hacker News sur une vulnérabilité de type “HTTP/2 Bomb” affectant plusieurs stacks web modernes. La validation opérationnelle doit s’appuyer sur les avis officiels des éditeurs concernés, ainsi que sur les bulletins de sécurité de chaque projet.

Versions affectées

Le point délicat avec HTTP/2 Bomb est qu’il s’agit d’un problème transversal au protocole et à ses implémentations, pas d’un bug monolithique limité à un seul binaire. Les versions vulnérables exactes dépendent donc de chaque éditeur. Au moment de l’analyse, il faut raisonner en trois niveaux : les produits explicitement cités, les versions intégrant une pile HTTP/2 exposée, et les versions corrigées publiées par chaque projet.

Produits explicitement signalés comme potentiellement affectés

NGINX avec support http_v2_module activé
Apache HTTP Server avec mod_http2
Microsoft IIS lorsque HTTP/2 est activé côté frontal
Envoy Proxy sur listeners ou routes exposés en HTTP/2
HAProxy avec terminaison ou transit HTTP/2
Potentiellement d’autres implémentations s’appuyant sur des bibliothèques HTTP/2 sensibles aux mêmes motifs de trames

Exposition réelle à vérifier côté infrastructure

Une instance n’est pas nécessairement vulnérable de manière exploitable uniquement parce que le logiciel est installé. Les cas à prioriser sont ceux où :

HTTP/2 est activé sur les interfaces publiques 443/tcp
Le frontal TLS termine les connexions ALPN avec annonce de h2
Le reverse proxy accepte des volumes élevés de flux concurrents par connexion
Les limites de requêtes, de buffering ou de streams sont permissives
Le composant est mutualisé entre plusieurs applications ou clients

Versions vulnérables et corrigées : méthode de validation

Comme les références exactes évoluent selon l’éditeur, la bonne pratique consiste à valider systématiquement :

La version installée via nginx -v, apachectl -v, httpd -v, haproxy -vv ou la console d’administration IIS
La présence effective de HTTP/2 dans la configuration
Les bulletins de sécurité officiels du fournisseur ou du projet
Les paquets reconstruits par la distribution, parfois patchés sans changement majeur de version amont

Exemples de vérification :

nginx -V 2>&1 | grep -i http_v2
apachectl -M | grep http2
haproxy -vv | grep -i h2
curl -I --http2 https://votre-domaine.tld
openssl s_client -alpn h2 -connect votre-domaine.tld:443 </dev/null

Pour les distributions Linux, il faut également tenir compte des backports de sécurité. Un paquet nginx ou apache2 apparemment ancien peut être corrigé par le mainteneur de la distribution. Il faut donc consulter le changelog du paquet :

apt changelog nginx
apt changelog apache2
dnf updateinfo info nginx
dnf updateinfo info httpd

CVE et scoring

Le briefing éditorial impose de mentionner les CVE-ID et le CVSS si connus. Or, sur ce type de faiblesse transversale, plusieurs scénarios existent :

Une ou plusieurs CVE distinctes sont attribuées à chaque implémentation
Un advisory sans CVE unique décrit un ensemble de comportements dangereux et de mitigations
Les scores CVSS diffèrent selon la facilité d’exploitation, l’impact sur la disponibilité et les conditions réseau

En environnement de production, il faut donc documenter dans votre inventaire sécurité :

Le CVE-ID de chaque produit concerné dès publication officielle
Le CVSS v3.x ou v4.0 communiqué par l’éditeur
La date de publication du correctif
Le statut de déploiement sur chaque frontal

Si votre organisation fonctionne avec des exigences de conformité ou de gestion de vulnérabilités outillée, créez un ticket distinct par composant : NGINX, Apache, IIS, Envoy, HAProxy, CDN managé, ingress Kubernetes, appliance WAF. C’est indispensable car les délais de patch, les syntaxes de mitigation et les risques résiduels diffèrent fortement.

Vecteur d'attaque

Le cœur du problème repose sur une caractéristique bien connue des protocoles modernes : leur richesse fonctionnelle améliore la performance, mais augmente aussi la surface d’erreur d’implémentation. HTTP/2 introduit le multiplexage de flux, la compression d’en-têtes, la gestion de fenêtres de contrôle, la priorisation, les trames de contrôle et une logique d’état plus sophistiquée que HTTP/1.1. Une faiblesse dans l’orchestration de ces mécanismes peut permettre à un attaquant d’obtenir un effet asymétrique : peu de trafic émis côté attaquant, beaucoup de travail côté serveur.

Pourquoi HTTP/2 est structurellement plus délicat à défendre

Avec HTTP/1.1, la relation entre une requête et l’effort serveur est souvent plus intuitive. Avec HTTP/2, une seule connexion peut porter de nombreux flux simultanés, avec des séquences de trames parfois valides au niveau protocolaire mais coûteuses à traiter. Un attaquant peut exploiter :

La multiplication de streams concurrents sur une même connexion
Des trames fragmentées ou ordonnées de manière à maximiser le travail de réassemblage
Des headers volumineux ou compressés de façon pathologique
Des interactions coûteuses entre SETTINGS, WINDOW_UPDATE, RST_STREAM et HEADERS
Des séquences qui déclenchent des allocations mémoire, des réveils de workers ou des parcours de structures internes

Le terme “bomb” souligne précisément cette amplification asymétrique. L’attaquant n’a pas besoin d’un botnet massif si l’implémentation visée effectue un travail disproportionné pour chaque motif reçu. Quelques connexions bien construites peuvent suffire à faire grimper la charge CPU, à épuiser des buffers, à saturer les files internes ou à provoquer des erreurs en cascade sur les applications en amont.

Scénario d’attaque concret sur un reverse proxy exposé

Imaginons un frontal NGINX ou Envoy exposé sur Internet, terminant TLS et distribuant le trafic vers plusieurs applications internes. L’attaquant :

Ouvre un petit nombre de connexions TLS annonçant h2 via ALPN
Négocie HTTP/2 normalement pour éviter les mécanismes de blocage basés sur des signatures triviales
Envoie des trames forgées ou des séquences de flux destinées à maximiser le coût de traitement
Maintient les connexions ouvertes suffisamment longtemps pour monopoliser des ressources
Répète l’opération depuis plusieurs adresses ou via des relais cloud

Le résultat observable peut être l’un ou plusieurs des symptômes suivants :

Hausse rapide de l’utilisation CPU sur les workers frontaux
Augmentation du nombre de connexions actives sans hausse proportionnelle du trafic utile
Épuisement mémoire ou pression GC sur certaines plateformes
Latence croissante sur les requêtes légitimes
Réponses 502, 503 ou 504 en chaîne
Dégradation des sondes de santé et bascule involontaire des load balancers

Exemple de configuration exposée

Sur NGINX, une configuration simple et très répandue active HTTP/2 sans limites suffisamment strictes :

server {
    listen 443 ssl http2;
    server_name app.exemple.tld;

    ssl_certificate     /etc/ssl/certs/fullchain.pem;
    ssl_certificate_key /etc/ssl/private/privkey.pem;

    location / {
        proxy_pass http://backend_pool;
        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $remote_addr;
    }
}

Cette configuration n’est pas “vulnérable” par elle-même au sens strict, mais elle illustre un cas fréquent où HTTP/2 est activé par défaut sans garde-fous avancés. Si l’implémentation sous-jacente présente une faiblesse de gestion des flux, ce type de frontal devient une cible privilégiée.

Impact côté applicatif et métier

Le déni de service généré par HTTP/2 Bomb ne se limite pas au serveur web. Sur une architecture moderne, l’effet domino peut toucher :

Les pools PHP-FPM, Node.js, Java ou .NET derrière le reverse proxy
Les caches applicatifs et sessions centralisées
Les bases de données si les retries applicatifs s’emballent
Les mécanismes d’auto-scaling qui réagissent mal à une charge artificielle
Les systèmes de supervision, qui voient un trafic apparemment “normal” au niveau TLS

Pour un RSSI ou un responsable production, le risque est donc double : indisponibilité immédiate et coût opérationnel élevé lié aux redémarrages, à l’investigation et aux surconsommations d’infrastructure. Dans les environnements mutualisés, une seule surface exposée peut dégrader plusieurs applications d’un même cluster.

Comparaison avec des failles HTTP/2 antérieures

L’écosystème a déjà connu plusieurs vagues de vulnérabilités liées à HTTP/2, notamment des attaques par réinitialisation rapide de flux, des abus de priorisation ou des cas de mauvaise gestion des limites de concurrence. La leçon récurrente est la même : la conformité au protocole ne suffit pas toujours à garantir une robustesse opérationnelle. Une séquence de trames peut être techniquement recevable tout en étant extrêmement coûteuse pour l’implémentation.

HTTP/2 Bomb s’inscrit dans cette continuité. Par rapport à des DoS plus classiques basés sur le volume brut, l’attaque est souvent plus discrète et plus rentable pour l’attaquant. Elle rappelle également que les composants “invisibles” de la chaîne web — reverse proxies, ingress controllers, gateways de service mesh, CDN configurables — sont souvent plus exposés que l’application elle-même.

Impact

L’impact principal est un déni de service à distance sans authentification. Selon le produit et la configuration, l’attaquant peut provoquer :

Une saturation CPU sur les workers ou threads gérant HTTP/2
Une consommation mémoire anormale liée aux buffers, tables d’état ou files de flux
Une baisse drastique du débit utile et une augmentation de la latence
Une indisponibilité partielle ou totale de l’application exposée
Des redémarrages de services si des garde-fous système sont atteints

Dans les cas les plus sensibles, l’attaque peut déborder les seules frontières du serveur web :

Le frontal tombe en surcharge et coupe les connexions vers les backends
Les sondes de santé marquent les nœuds comme défaillants
Le trafic est reporté sur d’autres instances, qui tombent à leur tour
Le CDN ou le WAF en amont n’absorbe pas correctement le motif HTTP/2
Le plan de reprise automatique amplifie la panne au lieu de la contenir

Pour les services API, l’impact peut aussi être plus subtil : sans panne totale, les temps de réponse deviennent erratiques, les clients multiplient les retries, les files de messages grossissent et l’ensemble de la chaîne applicative se dégrade. Ce mode de défaillance est parfois plus difficile à diagnostiquer qu’un crash net.

Comment patcher

La remédiation prioritaire consiste à installer les versions corrigées publiées par chaque éditeur ou mainteneur de distribution. Comme il n’existe pas nécessairement un numéro de version unique commun à tous les produits, la démarche doit être pilotée composant par composant.

NGINX

Vérifiez la version et le dépôt utilisé :

nginx -v
nginx -V

Sur Debian et Ubuntu :

sudo apt update
sudo apt install --only-upgrade nginx
apt changelog nginx

Sur RHEL, AlmaLinux, Rocky Linux, Oracle Linux :

sudo dnf upgrade nginx
dnf updateinfo info nginx

Rechargez ensuite la configuration :

sudo nginx -t
sudo systemctl reload nginx

Version cible : la première version explicitement annoncée comme corrigée par l’éditeur ou le mainteneur de votre distribution. Si vous utilisez l’image officielle Docker, reconstruisez l’image à partir du tag corrigé et redéployez.

Apache HTTP Server

Vérifiez l’activation de mod_http2 :

apachectl -M | grep http2
apachectl -v

Sur Debian et Ubuntu :

sudo apt update
sudo apt install --only-upgrade apache2
apt changelog apache2

Sur distributions de type RHEL :

sudo dnf upgrade httpd
dnf updateinfo info httpd

Redémarrage ou reload :

sudo apachectl configtest
sudo systemctl reload apache2
# ou
sudo systemctl reload httpd

Version cible : version intégrant le correctif sur mod_http2 ou sur la pile utilisée, telle qu’indiquée dans l’advisory officiel Apache ou par la distribution.

Microsoft IIS

Pour IIS, la remédiation passe généralement par Windows Update ou par l’application d’un correctif cumulatif de sécurité correspondant à la version de Windows Server. Vérifiez :

La version de Windows Server
La présence de HTTP/2 activé côté HTTP.sys / IIS
Les KB de sécurité publiées par Microsoft

Exemple PowerShell pour déclencher les mises à jour selon vos processus internes :

Get-HotFix
Get-WindowsFeature Web-Server
iisreset /status

Version cible : dernier correctif cumulatif Microsoft documentant la correction ou la mitigation du comportement HTTP/2 concerné.

Envoy Proxy

Vérifiez la version :

envoy --version

Si vous utilisez des images conteneurisées :

docker pull envoyproxy/envoy:<tag_corrige>
kubectl set image deployment/mon-envoy envoy=envoyproxy/envoy:<tag_corrige>

En environnement Kubernetes, il faut aussi vérifier les composants qui embarquent Envoy indirectement, notamment certains ingress controllers ou meshes de services. Version cible : tag ou release explicitement corrigé par le projet ou l’éditeur de la distribution managée.

HAProxy

Vérifiez la version et les options compilées :

haproxy -vv

Sur Debian et Ubuntu :

sudo apt update
sudo apt install --only-upgrade haproxy
apt changelog haproxy

Sur distributions de type RHEL :

sudo dnf upgrade haproxy
dnf updateinfo info haproxy

Rechargez le service :

sudo haproxy -c -f /etc/haproxy/haproxy.cfg
sudo systemctl reload haproxy

Version cible : première version corrigée publiée par HAProxy Technologies ou par votre distribution.

Points de contrôle après patch

Tester la négociation ALPN h2
Valider les temps de réponse sous charge normale
Surveiller CPU, mémoire, nombre de connexions et erreurs 5xx
Vérifier que les limitations de streams et de buffers sont bien appliquées
Contrôler les appliances managées ou CDN en frontal, qui peuvent nécessiter une action distincte

Mitigation

Si le correctif n’est pas encore disponible ou ne peut pas être déployé immédiatement, il faut réduire la surface d’attaque sans attendre. Les mitigations les plus efficaces sont celles qui abaissent le coût de traitement par connexion et limitent les comportements atypiques au plus près d’Internet.

Désactiver temporairement HTTP/2 sur les surfaces les plus exposées

C’est la mesure la plus brutale, mais aussi la plus fiable lorsque le risque de disponibilité prime. Sur NGINX, retirez http2 de la directive listen :

server {
    listen 443 ssl;
    server_name app.exemple.tld;
    ...
}

Puis rechargez :

sudo nginx -t
sudo systemctl reload nginx

Sur Apache, désactivez le module ou retirez h2 de la négociation :

sudo a2dismod http2
sudo systemctl reload apache2

Cette mesure doit être arbitrée avec les équipes performance : le retour à HTTP/1.1 peut augmenter le nombre de connexions côté clients, mais il réduit fortement l’exposition à la faiblesse protocolaire en cours.

Réduire les limites de concurrence HTTP/2

Selon le produit, abaissez :

Le nombre maximal de streams concurrents par connexion
La taille maximale des en-têtes
Les fenêtres de contrôle et buffers
Le temps de vie des connexions inactives
Le nombre de requêtes autorisées par connexion persistante

Exemple de durcissement conceptuel sur NGINX :

http {
    keepalive_timeout 15s;
    client_header_timeout 10s;
    client_body_timeout 10s;
    send_timeout 10s;

    server {
        listen 443 ssl http2;
        http2_max_concurrent_streams 32;
        large_client_header_buffers 4 8k;
    }
}

La disponibilité exacte des directives dépend de la version installée. Il faut consulter la documentation de votre build.

Mettre des limites côté WAF, load balancer et anti-DDoS

Si vous utilisez un CDN, un WAF managé ou un load balancer avancé, activez les mécanismes de :

Rate limiting par IP, ASN, empreinte TLS ou comportement de session
Détection des connexions HTTP/2 anormalement durables ou trop denses
Blocage des clients qui ouvrent beaucoup de streams sans débit utile correspondant
Challenge ou tarpit sur les sources suspectes

Dans un contexte français, les clients hébergés chez OVHcloud, Scaleway ou sur des VPS mutualisés chez o2switch doivent vérifier ce qui est filtré en amont par l’hébergeur et ce qui reste à leur charge sur le frontal applicatif. Les protections réseau génériques ne comprennent pas toujours les subtilités d’HTTP/2 au niveau applicatif.

Détection et IoC

Les indicateurs de compromission au sens classique sont ici des indicateurs d’abus. Les équipes SOC et exploitation doivent rechercher :

Un pic de connexions TLS négociant h2 sans hausse équivalente du trafic métier
Des adresses IP générant beaucoup de sessions longues avec peu de réponses utiles
Une forte hausse des erreurs 503, 502, 504 ou des resets côté backend
Des workers saturés CPU alors que la bande passante reste modérée
Des motifs de trames HTTP/2 atypiques dans les journaux détaillés ou captures réseau

Exemples de commandes utiles :

ss -tan | grep ':443' | awk '{print $1}' | sort | uniq -c
journalctl -u nginx --since "1 hour ago"
grep ' 5[0-9][0-9] ' /var/log/nginx/access.log | tail -n 100
tcpdump -i any port 443 -w /tmp/http2-bomb.pcap

Sur les plateformes observables, surveillez particulièrement :

upstream_response_time
request_time
Nombre de connexions actives par worker
Taux de reset de flux
Erreurs de parsing ou de framing HTTP/2

Si votre stack le permet, activez temporairement des logs plus verbeux sur le sous-système HTTP/2, en veillant à ne pas aggraver la charge par une journalisation excessive. En environnement réglementé, conservez les captures et journaux pour corrélation, notamment si vous devez partager des éléments avec un CERT sectoriel ou avec CERT-FR en cas d’incident significatif.

Segmentation et architecture

Au-delà du patch immédiat, HTTP/2 Bomb rappelle l’importance d’une architecture de défense en profondeur :

Éviter qu’un seul frontal mutualisé expose toutes les applications critiques
Isoler les APIs publiques des consoles d’administration
Appliquer des limites spécifiques par virtual host ou par route sensible
Prévoir un mode dégradé permettant de couper HTTP/2 rapidement
Tester régulièrement les réactions de l’infrastructure à des charges protocolaires anormales

Les environnements Kubernetes méritent une attention particulière. Un ingress controller vulnérable peut devenir le point unique de défaillance de dizaines de services. Il faut donc valider non seulement l’image de l’ingress, mais aussi le service mesh, le cloud load balancer et les sidecars éventuels.

Source officielle et suivi

La communication initiale relayée par The Hacker News doit être complétée par les advisories officiels de chaque projet : sécurité NGINX, bulletins Apache HTTP Server, documentation Microsoft pour IIS et HTTP.sys, notes de version Envoy, bulletins HAProxy, ainsi que les avis des distributions Linux. C’est à ce niveau que seront confirmés les CVE-ID, les versions corrigées et les éventuels contournements supportés.

Pour les organisations françaises, il est également pertinent de surveiller les publications de CERT-FR si la campagne prend de l’ampleur ou si des indicateurs de détection consolidés sont diffusés. Les équipes en charge du MCO doivent intégrer ce sujet dans leur veille sécurité “serveurs web et reverse proxies”, au même titre que les vulnérabilités de bibliothèques TLS, de modules de réécriture ou d’authentification fédérée.

En pratique, la bonne réponse est simple : inventorier les frontaux HTTP/2, appliquer les mises à jour officielles dès disponibilité, réduire les limites de flux, et désactiver temporairement HTTP/2 là où l’exposition Internet est forte et la criticité métier élevée. Pour renforcer durablement ce type de surface, un passage par les guides de durcissement et de réduction de surface d’attaque reste utile, notamment via la catégorie /categorie/pratiques de FailleWeb.

Serveurs

Retour aux actualités