CVE-2026-49975 : HTTP/2 Bomb expose 880 000 serveurs web

HTTP/2 Bomb : comment une faille de compression met 880 000 serveurs web sous menace de déni de service

Le 3 juin 2026, le chercheur en sécurité Quang Luong a procédé à la divulgation publique coordonnée de CVE-2026-49975, une vulnérabilité de déni de service à distance surnommée « HTTP/2 Bomb ». Notifiée aux éditeurs concernés le 27 mai 2026, la faille affecte les implémentations du protocole HTTP/2 dans cinq des serveurs et proxys web les plus répandus au monde : NGINX, Apache HTTPD via le module mod_http2, Microsoft IIS, Envoy et Cloudflare Pingora. Selon un scan Shodan réalisé le jour même de la divulgation, plus de 880 000 serveurs publics exposés sur Internet sont potentiellement vulnérables, couvrant des infrastructures allant des hébergeurs mutualisés aux grandes plateformes d'entreprise.

Ce qui rend CVE-2026-49975 particulièrement redoutable est son asymétrie radicale entre les ressources requises par l'attaquant et celles consommées par la cible. Dans les tests publiés par Quang Luong, un attaquant disposant d'une simple connexion résidentielle à 100 Mbit/s est capable d'épuiser la totalité de la mémoire RAM disponible — 32 Go dans les configurations de référence testées — d'un déploiement Envoy standard en environ dix secondes. Le serveur attaqué se retrouve alors incapable de traiter de nouvelles requêtes légitimes et cesse effectivement de fonctionner. Cette efficacité dépasse nettement celle de la majorité des attaques DDoS volumétriques classiques, qui nécessitent généralement l'accès à des botnets de grande envergure ou à des amplificateurs réseau pour atteindre un effet comparable.

Techniquement, CVE-2026-49975 combine deux mécanismes distincts qui, pris séparément, sont connus depuis près d'une décennie. Le premier repose sur la table de compression HPACK — le mécanisme de compression des en-têtes propre à HTTP/2. HPACK fonctionne en permettant aux clients et serveurs de maintenir une table partagée d'en-têtes précédemment envoyés, référençables par un simple index numérique plutôt que d'être retransmis intégralement à chaque requête. L'attaquant exploite cette mécanique en injectant une entrée d'en-tête de très grande taille (plusieurs kilooctets à mégaoctets) dans la table HPACK du serveur cible. Les requêtes malveillantes suivantes n'envoient ensuite que des références d'un seul octet pointant vers cette entrée, forçant le serveur à allouer et reconstruire en mémoire vive l'intégralité de l'en-tête original à chaque requête — un effet d'amplification mémoire potentiellement de plusieurs ordres de grandeur.

Le second mécanisme est une variante de l'attaque Slowloris, technique de déni de service applicatif documentée depuis 2009, consistant à maintenir un grand nombre de connexions HTTP ouvertes simultanément sans les fermer, épuisant progressivement le pool de connexions du serveur. Dans CVE-2026-49975, les connexions HTTP/2 malveillantes sont maintenues ouvertes suffisamment longtemps pour permettre à l'amplification HPACK d'atteindre un niveau d'allocation mémoire critique avant que les mécanismes de timeout du serveur ne parviennent à les fermer. La combinaison des deux techniques crée un effet synergique qui démultiplie l'impact : l'amplification HPACK fournit la puissance brute de consommation mémoire, tandis que la rétention Slowloris empêche le serveur de récupérer ses ressources à temps.

Quang Luong a indiqué dans son rapport de divulgation avoir utilisé l'outil d'assistance à la programmation Codex pour automatiser la phase d'exploration et de combinaison de techniques d'attaque existantes, ce qui lui a permis d'identifier cette composition plus rapidement qu'une approche manuelle traditionnelle. Cette information revêt une importance particulière : elle illustre concrètement comment les outils d'IA générative accélèrent la phase de recherche et de chaînage de vulnérabilités, une étape qui nécessitait jusqu'ici une expertise de haut niveau et des semaines de travail. La vulnérabilité est techniquement similaire à CVE-2026-33829 affectant l'outil Snipping Tool de Windows, utilisant le même primitif de fuite via un mécanisme d'amplification comparable.

Le bilan par éditeur au moment de la divulgation est préoccupant. NGINX a publié un correctif dans la version 1.29.8, disponible via les dépôts officiels nginx.org. L'équipe Apache a intégré le correctif dans la version 2.0.41 du module mod_http2 — le patch se situe dans le module spécifique et non dans le serveur Apache HTTPD principal, ce qui nécessite une mise à jour de paquet ciblée selon les distributions Linux. Sur Debian/Ubuntu, le paquet concerné est libapache2-mod-http2 ; sur RHEL/CentOS, il s'agit de mod_http2. Microsoft IIS, Envoy et Cloudflare Pingora ne disposaient d'aucun correctif au moment de la publication. Microsoft n'a pas communiqué de délai ; Envoy a ouvert un ticket de sécurité prioritaire dans son dépôt public GitHub ; Cloudflare a indiqué travailler activement sur un correctif pour Pingora sans préciser d'échéance.

Pour les serveurs non encore patchés, des mesures d'atténuation temporaires peuvent réduire significativement l'exposition. La limitation du nombre de connexions HTTP/2 simultanées par adresse IP source, la réduction agressive des timeouts d'inactivité des connexions HTTP/2, la limitation de la taille maximale des tables HPACK acceptées, et le déploiement d'un WAF capable de détecter les patterns anormaux de compression HPACK constituent les principales options disponibles. L'équipe Huntress a publié des indicateurs de compromission spécifiques permettant de détecter les tentatives d'exploitation dans les journaux de connexion.

La vulnérabilité s'inscrit dans une continuité inquiétante d'attaques exploitant les mécanismes fondamentaux de HTTP/2. En août 2023, CVE-2023-44487 — l'attaque HTTP/2 Rapid Reset — avait permis d'orchestrer les plus grands DDoS jamais enregistrés dans l'histoire d'Internet (jusqu'à 398 millions de requêtes par seconde selon Cloudflare, Google et AWS), en exploitant également des mécanismes intrinsèques au protocole. La récurrence de ces vulnérabilités critiques sur HTTP/2 invite à une réflexion plus large sur la robustesse du protocole face aux abus délibérés de ses fonctionnalités de compression HPACK et de multiplexage des flux.

Pourquoi CVE-2026-49975 dépasse la vulnérabilité de serveur individuel

HTTP/2 n'est pas une technologie de niche : selon les données de W3Techs au printemps 2026, le protocole est utilisé par plus de 65 % des sites web mondiaux, et cette proportion monte à plus de 90 % pour les grands services web ayant modernisé leur infrastructure depuis 2020. NGINX, avec une part de marché supérieure à 30 % des sites actifs, est massivement utilisé comme serveur frontal et reverse proxy dans des environnements de production critiques. L'impact potentiel d'une campagne d'exploitation massive est considérable : une attaque coordonnée pourrait simultanément mettre hors ligne des milliers de services web sans que les attaquants aient besoin d'investir dans des infrastructures d'attaque coûteuses.

L'asymétrie de l'exploit est particulièrement inquiétante dans une perspective de démocratisation des capacités de déni de service. Historiquement, mener une attaque DDoS efficace contre une cible bien défendue nécessitait l'accès à un botnet de grande taille ou à des amplificateurs réseau ouverts. CVE-2026-49975 abaisse dramatiquement ce seuil : un seul acteur disposant d'une connexion Internet standard peut saturer un serveur de production sans équipement spécial, sans botnet, sans infrastructure d'attaque particulière. Cela rend la vulnérabilité accessible à des acteurs aux ressources très limitées — concurrents déloyaux cherchant à perturber un service concurrent, activistes ciblant une organisation, extorqueurs pratiquant le DDoS-for-ransom — et pas seulement aux États et groupes criminels organisés.

L'utilisation de Codex pour accélérer la découverte de CVE-2026-49975 soulève des questions structurelles sur l'évolution du paysage de la recherche en sécurité. Les équipes de recherche défensive peuvent utiliser ces outils pour accélérer la découverte et la correction proactive de vulnérabilités. Mais des acteurs malveillants disposant des mêmes outils peuvent identifier et weaponiser des vulnérabilités similaires avant leur divulgation publique, réduisant voire annulant la fenêtre disponible pour les défenseurs. La recherche IA-assistée comprime le cycle de vie des vulnérabilités complexes, en réduisant le temps entre la conceptualisation d'une technique d'attaque et sa matérialisation en exploit opérationnel.

Du point de vue de la défense en profondeur, CVE-2026-49975 rappelle l'importance de ne pas traiter les composants d'infrastructure — serveurs web, reverse proxys, équilibreurs de charge — comme des boîtes noires immuables. Ces composants sont des logiciels actifs qui reçoivent régulièrement des mises à jour de sécurité critiques et doivent être intégrés dans les processus de patch management de la même manière que les applications métier. La fenêtre de sept jours entre la notification aux éditeurs (27 mai) et la divulgation publique (3 juin) illustre la pression croissante exercée sur les équipes de réponse aux vulnérabilités. Les organisations dont le délai moyen de déploiement des correctifs dépasse cette fenêtre pour les composants d'infrastructure exposés sur Internet doivent revoir leurs processus.

Ce qu'il faut retenir

• Mettre à jour NGINX vers la version 1.29.8 ou supérieure et le module Apache mod_http2 vers la version 2.0.41 ou supérieure est une priorité immédiate — vérifiez les paquets libapache2-mod-http2 (Debian/Ubuntu) et mod_http2 (RHEL/CentOS).
• Pour Microsoft IIS, Envoy et Cloudflare Pingora — sans correctif disponible — appliquer du rate limiting HTTP/2 par IP source, réduire les timeouts de connexion et envisager de désactiver temporairement HTTP/2 si le service peut fonctionner en HTTP/1.1 dans l'intervalle.
• La découverte de CVE-2026-49975 via un outil IA (Codex) est un signal d'alarme : le cycle de vie des vulnérabilités se comprime, et les équipes de sécurité doivent renforcer leurs processus de veille et de patch management pour les composants d'infrastructure exposés sur Internet.