Une seule connexion résidentielle. Pas de botnet, pas d'infrastructure coûteuse, pas de compétences hors du commun. C'est tout ce qu'il faut pour épuiser 32 gigaoctets de RAM en une dizaine de secondes sur un serveur Envoy exposé à Internet. La vulnérabilité CVE-2026-49975, divulguée le 2 juin 2026 et baptisée HTTP/2 Bomb, touche les serveurs web les plus déployés dans vos infrastructures : nginx, Apache httpd, Microsoft IIS, Envoy, Cloudflare Pingora. Si vous gérez des services exposés sur Internet dans une banque, une administration ou une grande entreprise, ce n'est pas une alerte de routine. C'est un problème opérationnel immédiat.
CVE-2026-49975 est une attaque par déni de service à distance. Elle ne cherche pas à exfiltrer des données ni à obtenir un accès persistant : elle vise à rendre votre service indisponible, rapidement et avec très peu de ressources du côté de l'attaquant. Ce déséquilibre entre le coût d'une attaque et son impact est précisément ce qui rend cette vulnérabilité particulièrement préoccupante pour les équipes sécurité chargées de maintenir des SLA stricts.
Le mécanisme repose sur deux techniques combinées, chacune connue isolément, mais dont l'association crée un effet dévastateur. Comprendre ce mécanisme en détail, c'est comprendre pourquoi les atténuations de surface ne suffisent pas.
HTTP/2 intègre un mécanisme de compression des en-têtes appelé HPACK. Son principe est simple : plutôt que de renvoyer un en-tête complet à chaque requête, le client et le serveur maintiennent chacun une table de compression. Une fois qu'un en-tête a été envoyé, les échanges suivants peuvent y faire référence par un simple index numérique, économisant ainsi de la bande passante. C'est une excellente idée sur le papier. C'est aussi le vecteur principal de cette attaque.
L'attaquant commence par injecter une entrée très volumineuse dans la table de compression HPACK côté serveur. Cette entrée peut représenter un en-tête HTTP particulièrement long, soigneusement construit pour maximiser la taille en mémoire une fois reconstitué. Une fois cette entrée en place, l'attaquant envoie des milliers de requêtes contenant chacune des milliers de références d'un seul octet vers cette entrée. Un octet sur le réseau. Des kilooctets, voire des mégaoctets, en mémoire serveur. À chaque requête, le serveur doit reconstruire l'en-tête complet à partir de sa table de compression — et cette reconstruction coûte cher en RAM.
Selon les mesures publiées par CyberInsider, le ratio d'amplification atteint environ 5 700:1 sur Envoy 1.37.2. Pour chaque octet envoyé par l'attaquant, le serveur alloue l'équivalent de 5 700 octets en mémoire. Avec Apache httpd 2.4.67, le ratio est d'environ 4 000:1. Ces chiffres ne sont pas théoriques : ils correspondent aux mesures de saturation observées sur des machines disposant de 32 Go de RAM.
Votre surface d'attaque exposée prend ici une dimension concrète : chaque endpoint HTTP/2 accessible depuis Internet est un point d'entrée potentiel pour cette amplification. Et la plupart des configurations par défaut n'imposent aucune limite sur la taille ou le nombre de références HPACK par connexion.
L'amplification HPACK seule serait déjà problématique. Mais ce qui transforme cette vulnérabilité en arme réellement efficace, c'est la seconde technique : le maintien artificiel des connexions. L'analogie avec Slowloris — l'attaque DoS historique contre HTTP/1.1 qui consistait à envoyer des requêtes très lentement pour monopoliser les threads du serveur , est ici particulièrement pertinente.
Dans CVE-2026-49975, l'attaquant maintient ses connexions HTTP/2 délibérément ouvertes. Tant qu'une connexion reste active, le serveur ne peut pas libérer la mémoire allouée pour reconstruire les en-têtes compressés de cette session. La mémoire s'accumule donc sans jamais être restituée au système. Ce n'est pas un débordement de tampon classique, ce n'est pas une fuite mémoire au sens traditionnel du terme : c'est une consommation intentionnellement dirigée et soutenue.
La combinaison est redoutable : l'amplification HPACK remplit la mémoire à grande vitesse, et le maintien des connexions empêche tout mécanisme de récupération naturelle. Le serveur est pris entre deux étaux. Sur Envoy 1.37.2, la saturation de 32 Go de RAM s'opère en environ 10 secondes. Sur Apache httpd 2.4.67, il faut environ 18 secondes. Sur nginx 1.29.7, dont l'implémentation HPACK est moins exposée avec un ratio de seulement 70:1, il faut tout de même environ 45 secondes pour saturer la même quantité de mémoire. Ces durées sont trop courtes pour qu'une intervention humaine soit possible sans automatisation de la détection et de la réponse.
Les données de performance publiées suite à la divulgation de CVE-2026-49975 permettent de comparer précisément l'exposition selon votre stack. Ce n'est pas une hiérarchie qualitative : tous les serveurs concernés sont vulnérables. Mais les délais avant saturation varient significativement, et ils conditionnent votre fenêtre de réaction.
Envoy 1.37.2 présente le ratio d'amplification le plus élevé mesuré : 5 700:1. Avec une machine équipée de 32 Go de RAM, la saturation complète est atteinte en environ 10 secondes depuis une simple connexion résidentielle standard. C'est le scénario le plus défavorable parmi ceux documentés. Envoy est massivement utilisé comme proxy de service dans les architectures de type service mesh , Kubernetes, Istio, Consul Connect , ce qui signifie que ce n'est pas uniquement le frontal HTTP qui est exposé, mais potentiellement l'ensemble du maillage interne.
Apache httpd 2.4.67 affiche un ratio de 4 000:1 pour un épuisement de 32 Go en environ 18 secondes. Apache reste l'un des serveurs web les plus déployés dans les administrations publiques françaises et les grandes entreprises industrielles de la région EMEA. La combinaison de ce ratio élevé et de cette prévalence en fait une cible prioritaire. CybersecurityNews détaille la nature du correctif apporté dans mod_http2 v2.0.41, qui modifie le comptage des fragments de cookies dans les limites des champs de requête , une indication claire que le vecteur d'attaque passe précisément par ce mécanisme.
nginx 1.29.7 présente un profil différent. Son ratio d'amplification est mesuré à environ 70:1, soit deux ordres de grandeur en dessous d'Envoy. La saturation de 32 Go prend environ 45 secondes. Ce délai supplémentaire peut sembler rassurant, mais 45 secondes restent insuffisantes pour une intervention manuelle dans la grande majorité des architectures de production. nginx est souvent déployé comme reverse proxy devant des applications critiques, ce qui en fait un point de choix pour un attaquant cherchant à couper l'accès à un service bancaire ou gouvernemental.
Microsoft IIS sur Windows Server 2025 affiche un ratio d'amplification d'environ 68:1, légèrement inférieur à nginx. La particularité ici est la capacité mémoire de référence utilisée dans les tests : 64 Go, soit le double des autres serveurs testés. L'épuisement complet de cette mémoire est atteint en environ 45 secondes. IIS est le serveur de choix dans de nombreuses organisations du secteur public et bancaire en Europe qui ont standardisé sur l'écosystème Microsoft. Or, à la date de divulgation du 2 juin 2026, aucun correctif n'était disponible pour IIS.
Cloudflare Pingora est dans la même situation : vulnérable, sans correctif disponible à la date de divulgation. Pingora est le proxy HTTP de nouvelle génération développé en interne par Cloudflare pour remplacer nginx dans son infrastructure. Son exposition est structurellement différente de celle d'un serveur d'origine classique, car Pingora opère dans un réseau de distribution massif. Imperva confirme de son côté que ses clients bénéficient d'une protection contre CVE-2026-49975 au niveau de sa couche WAF et DDoS. Ce type de protection périmétrique peut atténuer le risque sur les serveurs d'origine, à condition que toutes les connexions HTTP/2 transitent effectivement par cette couche , ce qui n'est pas toujours garanti.
Chiffrer l'exposition d'une vulnérabilité permet de contextualiser l'urgence. Les données disponibles sur CVE-2026-49975 donnent une image claire : cette faille n'est pas un problème de niche.
Une analyse Shodan réalisée dans le cadre de la divulgation a identifié plus de 880 000 hôtes exposés sur Internet supportant HTTP/2 avec une configuration par défaut de l'un des serveurs affectés , nginx, Apache httpd, IIS, Envoy ou Pingora. Ce nombre représente les instances directement accessibles depuis Internet avec les paramètres par défaut, c'est-à-dire sans restriction explicite sur la gestion des tables de compression HPACK.
Un point mérite attention : beaucoup de ces 880 000 hôtes sont placés derrière des CDN. Cela réduit leur exposition directe, mais ne l'élimine pas. Si un attaquant parvient à établir des connexions HTTP/2 directement vers le serveur d'origine , via une IP résolue par DNS, une adresse exposée dans un certificat TLS, ou simplement un endpoint non masqué , la protection CDN n'intervient pas. C'est un schéma d'attaque fréquent que les équipes de threat intelligence documentent régulièrement dans le cadre de la veille sur les cybermenaces ciblant les infrastructures exposées.
Pour les organisations bancaires et gouvernementales de la zone EMEA, qui hébergent souvent des instances internes d'Envoy ou d'Apache non protégées par un CDN externe, le risque d'exploitation directe est particulièrement concret.
CVE-2026-49975 a été découvert par Quang Luong, chercheur au cabinet Calif. La validation sur d'autres plateformes serveur a été conduite avec Jun Rong et Duc Phan. La divulgation publique a eu lieu le 2 juin 2026. L'analyse technique approfondie, incluant des règles de détection au format Sigma, est disponible via SOCPrime, ce qui facilite l'intégration dans les SIEM et plateformes de détection existantes.
La rapidité de la divulgation et la disponibilité immédiate de règles de détection sont des signaux positifs. Mais ils signifient aussi que les attaquants ont accès aux mêmes informations techniques dès la publication , ce qui réduit la fenêtre entre divulgation et exploitation active.
La situation en matière de patches est hétérogène. Deux éditeurs ont livré des correctifs dès la divulgation. Trois ne l'ont pas fait. Cette asymétrie conditionne directement votre stratégie de réponse.
nginx a publié la version 1.29.8, qui introduit une nouvelle directive max_headers permettant de limiter le nombre d'en-têtes HTTP/2 traités par connexion. C'est un contrôle direct sur le vecteur d'amplification HPACK : en plafonnant le nombre de références acceptées, le serveur empêche l'accumulation mémoire décrite dans le mécanisme de l'attaque. La mise à jour depuis 1.29.7 vers 1.29.8 est la première action à effectuer si nginx est dans votre stack.
Apache httpd a corrigé la vulnérabilité dans mod_http2 version 2.0.41. Le correctif modifie la façon dont les fragments de cookies sont comptabilisés dans les limites imposées aux champs de requête. Techniquement, cela ferme le vecteur principal par lequel l'amplification HPACK atteignait les ratios de 4 000:1 mesurés sur la version 2.4.67. Si vous exploitez Apache httpd avec le module HTTP/2 activé, la mise à jour de mod_http2 est impérative, indépendamment de la version d'Apache elle-même.
À la date de divulgation du 2 juin 2026, Microsoft IIS, Envoy et Cloudflare Pingora ne disposaient d'aucun correctif. Pour IIS, cela concerne tous les déploiements Windows Server 2025 avec HTTP/2 activé , une configuration de plus en plus courante depuis que Microsoft a fait de HTTP/2 un défaut dans les versions récentes d'IIS. Pour Envoy, l'absence de patch est particulièrement préoccupante compte tenu du ratio d'amplification de 5 700:1 et de la prévalence d'Envoy dans les architectures cloud-native.
En l'absence de correctif, les mesures d'atténuation disponibles passent par la configuration : désactivation d'HTTP/2 sur les endpoints exposés si votre application le permet, limitation du débit de connexion au niveau réseau, implémentation de règles WAF ciblant les patterns de référencement HPACK anormaux. Ces mesures réduisent la surface d'exposition, mais n'éliminent pas la vulnérabilité fondamentale.
La priorité immédiate est l'inventaire. Vous avez besoin de savoir exactement quels serveurs exposés à Internet font tourner nginx, Apache httpd avec mod_http2, IIS, Envoy ou Pingora, dans quelles versions, et avec HTTP/2 activé. Cet inventaire doit couvrir non seulement vos frontaux web publics, mais aussi vos API gateways, vos reverse proxies internes et vos instances de service mesh. Dans les architectures complexes de type microservices, Envoy peut être présent dans des dizaines de composants sans avoir fait l'objet d'une mise à jour centralisée.
Pour nginx, la mise à jour vers 1.29.8 est simple et documentée. Faites-la cette semaine. Pour Apache httpd, mettez à jour mod_http2 vers la version 2.0.41. Vérifiez que votre distribution Linux ou votre système de gestion de packages ne verrouille pas une version antérieure du module indépendamment de la version d'Apache. Sur les environnements Red Hat Enterprise Linux ou Debian LTS, les backports de sécurité fonctionnent différemment , assurez-vous que le correctif mod_http2 est bien intégré dans votre canal de mise à jour.
Pour IIS et Envoy, en l'absence de patch, la décision se résume à une question de tolérance au risque. Si vous pouvez désactiver HTTP/2 sans impact fonctionnel majeur sur vos services , et pour beaucoup d'applications internes, HTTP/1.1 reste parfaitement suffisant , c'est la mesure la plus directe. Si HTTP/2 est fonctionnellement requis, documentez l'exposition résiduelle, activez une surveillance des connexions anormalement longues avec un volume élevé d'en-têtes, et assurez-vous que votre couche de protection périmétrique (WAF, CDN, DDoS mitigation) voit bien le trafic HTTP/2 destination de vos serveurs d'origine.
Communiquez à votre RSSI et à vos équipes d'exploitation les délais de saturation concrets : 10 secondes pour Envoy, 18 secondes pour Apache, 45 secondes pour nginx et IIS. Ces chiffres changent la conversation sur l'urgence du patching. Une fenêtre de 45 secondes ne permet pas une intervention manuelle dans un centre de supervision classique , elle exige une réponse automatisée préconfigurée.
La détection de CVE-2026-49975 repose sur l'identification de patterns de connexion HTTP/2 anormaux. Les indicateurs les plus fiables sont le volume inhabituel de références HPACK par connexion et la durée anormalement longue des connexions HTTP/2 combinée à une croissance rapide de la consommation mémoire du processus serveur.
Au niveau réseau, une connexion HTTP/2 légitime génère des patterns de références d'en-têtes prévisibles. L'attaque HTTP/2 Bomb produit un volume de références d'index très élevé pour un volume de données transmises très faible , c'est ce déséquilibre entre octets reçus et mémoire allouée qui constitue la signature comportementale principale. Si votre SIEM ingère les logs HTTP/2 au niveau des connexions, une règle de détection sur ce ratio est actionnable immédiatement.
Des SOCPrime a publié des règles Sigma spécifiques pour CVE-2026-49975 couvrant les principaux serveurs affectés. Ces règles sont compatibles avec les principaux SIEM du marché (Splunk, Microsoft Sentinel, Elastic, QRadar). Leur intégration ne demande pas de développement personnalisé , c'est de la configuration standard.
Côté infrastructure, la surveillance de la consommation mémoire des processus nginx, Apache et Envoy avec des seuils d'alerte agressifs est indispensable. Une augmentation de la RAM de plus de 20 à 30 % en moins d'une minute sur un processus serveur HTTP/2 doit déclencher une alerte immédiate, pas un email asynchrone. Intégrez ces métriques dans votre système de monitoring avec des alertes PagerDuty ou équivalent si ce n'est pas déjà fait.
Sur les indicateurs de compromission plus larges, il est utile de rappeler que la détection d'une tentative d'exploitation ne se limite pas à la couche applicative. Comprendre ce que sont les indicateurs de compromission et comment les corréler entre vos sources de logs reste fondamental pour distinguer une tentative ciblée d'un scan opportuniste.
Enfin, si vous utilisez Imperva pour la protection applicative, la protection contre CVE-2026-49975 est confirmée par l'éditeur. Vérifiez néanmoins que la couverture s'applique bien à tous vos endpoints HTTP/2, y compris ceux qui ne sont pas explicitement listés dans votre configuration WAF.
Ce type de menace illustre un problème structurel : les informations critiques sur une campagne active circulent d'abord dans des canaux fermés, forums clandestins et groupes Telegram privés, avant d'atteindre les équipes de sécurité par les canaux habituels. Le temps perdu dans cet écart est souvent celui où l'exploitation est la plus active.
Defendis surveille ces sources en continu. Votre équipe reçoit des signaux d'alerte pertinents avant que l'incident ne devienne public, avec le contexte nécessaire pour agir : nature de la menace, infrastructure associée, secteurs ciblés. Sans que vos analystes aient à patrouiller eux-mêmes dans des espaces qu'ils ne devraient pas avoir à fréquenter.
Pour les serveurs disposant d'un correctif , nginx 1.29.8 et Apache httpd avec mod_http2 2.0.41 , la désactivation d'HTTP/2 n'est pas nécessaire si vous appliquez le patch rapidement. Pour IIS et Envoy, où aucun correctif n'est disponible, la désactivation d'HTTP/2 est la mesure d'atténuation la plus directe et la plus efficace si votre application peut fonctionner en HTTP/1.1. L'impact fonctionnel est généralement faible sur des applications internes ou des API non optimisées spécifiquement pour HTTP/2. Sur les services publics à fort trafic, évaluez l'impact sur les performances avant de basculer.
Partiellement. Un CDN qui termine les connexions HTTP/2 côté client et communique avec votre serveur d'origine en HTTP/1.1 protège effectivement votre serveur d'origine contre l'attaque. Mais si votre serveur d'origine est accessible directement via HTTP/2 , ce qui est fréquent lorsque l'IP d'origine est exposée ou résolvable , le CDN n'offre aucune protection sur ce vecteur. Vérifiez que votre serveur d'origine est réellement inaccessible hors du CDN avant de considérer cette protection comme suffisante. Par ailleurs, Cloudflare Pingora est lui-même listé parmi les serveurs vulnérables sans correctif disponible à la date de divulgation.
Pour nginx, exécutez nginx -v depuis le serveur. Si la version retournée est inférieure à 1.29.8, le serveur est vulnérable si HTTP/2 est activé. Pour Apache httpd, la version de mod_http2 s'affiche avec apachectl -M ou dans les en-têtes de réponse si la directive ServerTokens n'est pas restreinte. Si mod_http2 est en version antérieure à 2.0.41, le correctif n'est pas appliqué. Sur les distributions Linux avec gestion de packages, vérifiez l'état avec votre gestionnaire de paquets (dpkg -l libapache2-mod-http2 sur Debian/Ubuntu, rpm -qi mod_http2 sur RHEL/CentOS) en gardant à l'esprit que les versions backportées peuvent avoir des numéros différents de l'upstream.
Oui, selon les données disponibles. Les mesures de saturation documentées par CyberInsider ont été obtenues à partir d'une seule connexion résidentielle standard, sans infrastructure d'attaque distribuée. Les ratios d'amplification , 5 700:1 pour Envoy, 4 000:1 pour Apache , sont suffisamment élevés pour qu'une connexion à débit modeste produise une consommation mémoire colossale côté serveur. C'est précisément ce déséquilibre asymétrique qui distingue CVE-2026-49975 des attaques DDoS volumétriques classiques qui nécessitent une large capacité de bande passante côté attaquant.
Non. CVE-2026-49975 est exploitable sans authentification préalable. L'attaquant n'a besoin que d'établir une connexion HTTP/2 avec le serveur cible, ce qui est possible sur n'importe quel endpoint HTTP/2 accessible publiquement. Cette absence de prérequis d'authentification explique pourquoi l'analyse Shodan identifie 880 000 hôtes comme directement exposés : tout serveur qui accepte des connexions HTTP/2 depuis Internet sans restriction réseau préalable est potentiellement attaquable par n'importe quel acteur disposant d'une connexion Internet standard.
