⚠️ Divulgation responsable : Les informations techniques présentées dans cet article sont issues de la divulgation publique officielle de la société Calif (3 juin 2026) et des avis de sécurité des éditeurs concernés. Elles sont partagées dans un objectif purement défensif : permettre aux administrateurs systèmes d’évaluer leur exposition et d’appliquer les correctifs disponibles. Aucune information permettant de cibler des systèmes tiers n’est fournie.
Présentation de la vulnérabilité
Le 3 juin 2026, la société de recherche en sécurité Calif a divulgué publiquement CVE-2026-49975, surnommée HTTP/2 Bomb. Il s’agit d’une attaque de déni de service (DoS) à distance, sans authentification, capable d’épuiser 32 Go de mémoire serveur en moins de 10 secondes à partir d’une simple connexion résidentielle.
La vulnérabilité affecte la majorité des serveurs web modernes configurés avec HTTP/2 : nginx, Apache httpd, Microsoft IIS, Envoy et Cloudflare Pingora. Plus de 880 000 serveurs publics ont été confirmés exposés via un scan Shodan au moment de la divulgation.
Fiche technique
| CVE | CVE-2026-49975 |
| Alias | HTTP/2 Bomb / MADBug HTTP2 |
| Type | Déni de service (DoS) — Épuisement mémoire |
| Score CVSS v3 | 7.5 (Important) |
| Vecteur | Réseau / Aucune authentification requise / Aucune interaction utilisateur |
| Date de divulgation | 3 juin 2026 |
| PoC public | Disponible depuis le 3 juin 2026 |
| Découvert par | Calif (via modèle IA OpenAI Codex) |
Mécanisme d’attaque
L’attaque combine deux techniques bien connues mais jamais associées de cette façon dans le contexte HTTP/2 :
1. Bombe HPACK (compression table amplification)
HPACK (RFC 7541) est le schéma de compression des en-têtes HTTP/2. Chaque côté de la connexion maintient une table dynamique des en-têtes récemment vus. Un expéditeur peut insérer un en-tête une fois, puis y faire référence par son index — généralement un seul octet sur le fil.
L’attaquant exploite ce mécanisme en semant la table dynamique du serveur avec un en-tête volumineux, puis en envoyant des milliers de références indexées d’un seul octet. Chaque octet envoyé force le serveur à reconstruire en mémoire l’en-tête d’origine, générant des ratios d’amplification massifs :
| Serveur | Ratio d’amplification | Consommation mémoire |
|---|---|---|
| Envoy 1.37.2 | ~5 700 : 1 | 32 Go en ~10 secondes |
| Apache httpd 2.4.67 | ~4 000 : 1 | 32 Go en ~20 secondes |
| nginx 1.29.7 | ~70 : 1 | Significatif |
| Microsoft IIS (WS 2025) | ~68 : 1 | Significatif |
| Cloudflare Pingora | ~70 : 1 | Significatif |
2. Window Stall (maintien de connexion style Slowloris)
Pour ancrer l’allocation mémoire dans le temps, l’attaquant annonce une fenêtre de contrôle de flux à zéro octet, empêchant le serveur d’envoyer sa réponse et donc de libérer les ressources. Des frames WINDOW_UPDATE d’un seul octet sont ensuite envoyées en compte-gouttes pour réinitialiser les timers et maintenir la connexion indéfiniment ouverte.
La combinaison des deux techniques transforme une connexion légitime HTTP/2 en une arme capable de mettre hors service un serveur de production depuis n’importe quel accès internet résidentiel.
Produits et distributions impactés
Serveurs web — versions vulnérables et correctifs
| Produit | Version vulnérable | Correctif disponible | Action recommandée |
|---|---|---|---|
| nginx | ≤ 1.29.7 | ✅ 1.29.8+ (27 avril 2026) | Mettre à jour vers 1.29.8+ |
| Apache httpd | ≤ 2.4.67 (mod_http2) | ✅ mod_http2 v2.0.41+ (27 mai 2026) | Mettre à jour mod_http2 |
| Envoy | 1.37.2 et antérieures | ✅ Patch publié le 3 juin 2026 | Appliquer le patch Envoy |
| Microsoft IIS | Windows Server 2025 | ⏳ En cours d’évaluation | Désactiver HTTP/2 en attendant |
| Cloudflare Pingora | Non spécifié | ⏳ En cours d’évaluation | Suivre les avis Cloudflare |
Distributions Linux
L’impact sur les distributions dépend des versions de paquets embarquées et des cycles de backport :
- Rocky Linux 9 : nginx 1.26.3 inclus par défaut — vulnérable. Le correctif dépend d’un backport RHEL (Red Hat Enterprise Linux), dont Rocky est dérivé. Mitigation temporaire : désactiver HTTP/2.
- RHEL / AlmaLinux / CentOS Stream : même situation que Rocky Linux, le correctif suivra le cycle RHEL.
- SUSE Linux Enterprise Server 15 SP7, 16.0, 16.1 — patch en attente (statut « Pending » au 4 juin 2026).
- SUSE Linux Enterprise Desktop 15 SP7 — patch en attente.
- openSUSE Leap 16.0 — patch en attente.
- SUSE Linux Enterprise Server LTSS 12 SP5 → 15 SP6 (dont variantes SAP, Manager 4.3) — patch en attente.
- Ubuntu / Debian : non encore référencés dans les avis publiés au moment de la rédaction ; vérifier les DSA/USN à venir.
Vérifier son exposition
Pour savoir si votre serveur expose HTTP/2 :
# Tester si HTTP/2 est actif sur votre domaine
curl -sI --http2 https://votre-domaine.fr | grep -i "HTTP/"
# Via openssl (utile si curl ne supporte pas HTTP/2)
openssl s_client -connect votre-domaine.fr:443 -alpn h2 2>/dev/null | grep "ALPN"Si la réponse contient HTTP/2 200 ou ALPN protocol: h2, votre serveur est potentiellement exposé et doit être patché ou configuré en mitigation.
Mitigations et correctifs
nginx (correctif disponible)
# Mettre à jour nginx vers 1.29.8+
# Debian/Ubuntu
apt update && apt install nginx
# RHEL/Rocky (depuis le dépôt officiel nginx.org)
dnf upgrade nginx
# Vérifier la version installée
nginx -vLe correctif nginx 1.29.8 introduit la directive max_headers (défaut : 1000) qui limite la taille de la table HPACK dynamique. Si la mise à jour n’est pas possible immédiatement :
# Désactiver HTTP/2 dans nginx (mitigation temporaire)
# Dans votre bloc server {}
listen 443 ssl; # Retirer "http2" de cette ligne
# Recharger nginx
nginx -t && systemctl reload nginxApache httpd (correctif disponible)
# Mettre à jour mod_http2 vers v2.0.41+
# Debian/Ubuntu
apt update && apt install libapache2-mod-http2
# RHEL/Rocky
dnf upgrade mod_http2
# Vérifier la version du module
apachectl -M | grep http2Si la mise à jour n’est pas possible, désactiver HTTP/2 dans la configuration Apache :
# Dans httpd.conf ou votre VirtualHost
Protocols http/1.1
# Recharger Apache
apachectl configtest && systemctl reload apache2Mitigation universelle — Limiter la mémoire par worker
Quelle que soit la solution logicielle, une protection système efficace consiste à plafonner la mémoire allouable par worker via cgroups ou les limites de conteneur. En cas d’attaque, le processus déclenche un OOM-kill ciblé plutôt qu’un épuisement global de la RAM système :
# Exemple Docker Compose — limiter la mémoire du conteneur nginx
services:
nginx:
image: nginx:1.29.8
mem_limit: 2g # Le conteneur sera tué si dépassement
memswap_limit: 2g # Pas de swap — fail-fastTimeline de divulgation
- Avril 2026 : Divulgation privée à nginx — correctif développé.
- 27 avril 2026 : nginx publie la version 1.29.8 avec le correctif.
- 27 mai 2026 : Divulgation à Apache httpd — correctif publié le même jour (mod_http2 v2.0.41).
- 3 juin 2026 : Divulgation publique complète par Calif avec PoC — Envoy publie ses patches simultanément. CVE-2026-49975 assigné.
- 4 juin 2026 : 880 000+ serveurs confirmés exposés (Shodan). IIS, Pingora et distributions Linux en cours de traitement.
Conclusion
CVE-2026-49975 illustre comment deux techniques connues de longue date — la bombe de compression et le maintien de connexion à la Slowloris — peuvent être combinées pour créer une attaque dévastatrice sur l’infrastructure HTTP/2 mondiale. La rapidité d’exploitation (10 secondes pour 32 Go) et l’absence totale de prérequis (pas d’authentification, pas d’accès privilégié) en font une menace particulièrement sérieuse pour toute infrastructure exposée sur Internet.
Actions prioritaires : vérifier si HTTP/2 est actif, mettre à jour nginx (≥ 1.29.8) et/ou mod_http2 Apache (≥ 2.0.41), appliquer les patches Envoy, et ajouter des limites mémoire par conteneur/worker comme filet de sécurité systémique.