HTTP/2 Bomb (CVE-2026-49975) : la vulnérabilité de serveur web à l'échelle de l'industrie et pourquoi les clients LiteSpeed ne sont pas affectés

Le 2 juin 2026, la firme de cybersécurité Calif a publiquement divulgué CVE-2026-49975, une vulnérabilité de déni de service à distance qu'ils ont nommée HTTP/2 Bomb. La vulnérabilité affecte les configurations HTTP/2 par défaut de NGINX, Apache HTTPD, Microsoft IIS, Envoy et Cloudflare Pingora, soit collectivement les serveurs web qui alimentent la majeure partie de l'internet public. Un seul attaquant sur une connexion internet domestique ordinaire (100 Mbps) peut consommer environ 32 Go de mémoire serveur en 20 secondes, rendant un serveur web inaccessible jusqu'à son redémarrage. Environ 880 000 sites web prenant en charge HTTP/2 avec des configurations par défaut sur les serveurs affectés sont potentiellement exposés.

Notablement absents de la liste des systèmes affectés : LiteSpeed Web Server, OpenLiteSpeed et LiteSpeed Web ADC. LiteSpeed Technologies a confirmé le 5 juin que ses produits serveur ne sont pas vulnérables à HTTP/2 Bomb, car LiteSpeed ne partage aucun code avec Apache malgré sa compatibilité. Les clients Gotekky existants sur les anciens environnements partagés et revendeur utilisent LiteSpeed et étaient donc structurellement protégés. Les autres environnements existants ou gérés doivent être évalués selon le serveur web réellement déployé : Apache, NGINX ou LiteSpeed.

Le reste de ce guide explique ce qu'est techniquement HTTP/2 Bomb, pourquoi l'architecture de LiteSpeed l'évite, ce que la protection de Cloudflare ajoute pour les clients sur des sites desservis par Cloudflare et ce que les opérateurs de serveurs basés sur NGINX, Apache, IIS, Envoy ou Pingora doivent faire d'urgence.

Ce qu'est réellement HTTP/2 Bomb

HTTP/2 Bomb n'est pas une seule nouvelle vulnérabilité. C'est la combinaison de deux techniques de déni de service connues qui ont été publiquement documentées depuis près d'une décennie mais qui n'étaient pas auparavant connues pour se composer contre les serveurs web modernes. La combinaison a été découverte par l'agent Codex d'OpenAI qui lisait les bases de code des serveurs affectés et reconnaissait que les deux techniques se composent. La découverte est attribuée à Quang Luong de Calif, avec Jun Rong et Duc Phan validant l'attaque contre des plateformes de serveurs supplémentaires.

Les deux moitiés de l'attaque :

• HPACK Bomb (à l'origine CVE-2016-6581, par Cory Benfield) : HPACK est le schéma de compression d'en-têtes de HTTP/2. Par conception, un octet sur le fil peut devenir une allocation d'en-tête complète sur le serveur. Un attaquant envoie des en-têtes compressés spécialement conçus où chaque octet s'étend en une entrée d'en-tête complète. Quelques centaines d'octets de trafic réseau peuvent déclencher des milliers d'allocations d'en-têtes sur le serveur, consommant des mégaoctets de mémoire par requête.
• Maintien de contrôle de flux de style Slowloris : HTTP/2 a une fenêtre de contrôle de flux par flux que le récepteur peut ouvrir ou fermer. Un attaquant maintient la fenêtre de contrôle de flux du serveur à zéro, ce qui signifie que le serveur ne peut pas envoyer de données de réponse et ne peut donc pas libérer la mémoire associée à la requête. La requête reste ouverte indéfiniment. La mémoire s'accumule et n'est jamais libérée.

Combinées : l'attaquant ouvre de nombreux flux HTTP/2, chacun transportant une bombe de compression HPACK qui alloue des milliers d'entrées d'en-tête sur le serveur. L'attaquant maintient la fenêtre de contrôle de flux à zéro sur chaque flux, empêchant le serveur de compléter ou de libérer aucun d'eux. La consommation de mémoire croît linéairement avec le nombre de flux ouverts multiplié par la taille de chaque bombe HPACK, et une connexion à 100 Mbps peut soutenir suffisamment de flux d'attaque simultanés pour épuiser 32 Go de mémoire en 20 secondes.

La partie astucieuse de l'attaque est ce que coûte à l'attaquant chaque moitié. HPACK Bomb seul est trivialement bloqué par les limites de nombre d'en-têtes (que la plupart des serveurs appliquent par défaut). Slowloris seul est trivialement bloqué par les délais de connexion ou de requête. La combinaison déjoue les deux défenses parce que chaque moitié se cache dans le comportement d'apparence légitime de l'autre : la bombe HPACK reste sous les limites d'en-têtes par flux car des milliers de flux sont utilisés en parallèle, et le maintien Slowloris ressemble à un contrôle de flux normal que le serveur est obligé d'honorer.

Pourquoi LiteSpeed n'est pas vulnérable

La vulnérabilité HTTP/2 Bomb réside dans les implémentations HTTP/2 par défaut de NGINX, mod_http2 d'Apache HTTPD, Microsoft IIS, Envoy et Cloudflare Pingora. Ces cinq produits partagent la propriété que leur décodeur HPACK alloue de la mémoire par en-tête de manière empressée et que leur implémentation de contrôle de flux ne limite pas la mémoire totale détenue par les flux en état bloqué.

LiteSpeed Web Server est un remplacement direct d'Apache, ce qui signifie qu'il accepte la même syntaxe de configuration et sert les mêmes charges de travail, mais il ne partage aucun code source avec Apache. L'implémentation HTTP/2 de LiteSpeed est écrite indépendamment et n'exhibe pas la même combinaison d'allocation HPACK empressée plus rétention de mémoire de contrôle de flux non bornée. La même propriété de base de code indépendante s'applique à OpenLiteSpeed (la variante open source) et LiteSpeed Web ADC (le contrôleur de livraison d'applications).

LiteSpeed Technologies a confirmé le 5 juin 2026 que leurs produits serveur ne sont effectivement pas vulnérables aux attaques HTTP/2 Bomb. Le qualificatif « effectivement » reflète la prudence d'ingénierie : la compagnie s'est engagée à une revue supplémentaire des cas limites, mais aucun chemin d'exploitation contre LiteSpeed n'a été démontré, et les raisons architecturales pour lesquelles LiteSpeed évite la vulnérabilité sont structurelles plutôt qu'incidentes.

C'est la deuxième fois ces dernières années que les clients LiteSpeed ont été incidemment protégés d'une vulnérabilité à l'échelle de l'industrie en raison de l'indépendance architecturale par rapport à Apache. Le schéma reflète une vérité plus large sur la diversité des serveurs web : quand la plupart d'internet exécute la même poignée de bases de code de serveur HTTP, une vulnérabilité dans l'une de ces bases de code a un très grand rayon d'effet. Utiliser un serveur moins courant avec une base de code indépendante est une forme de défense en profondeur qui n'apparaît pas dans les journaux de correctifs mais qui paie quand des événements à l'échelle de l'industrie comme HTTP/2 Bomb arrivent.

Cloudflare ajoute une deuxième couche de protection

Pour les sites qui se trouvent derrière la périphérie de Cloudflare (ce qui inclut une portion significative des sites clients hébergés par Gotekky), Cloudflare a confirmé le 3 juin 2026 que leur architecture existante et leurs systèmes d'atténuation DDoS détectent et atténuent automatiquement les attaques HTTP/2 Bomb. Les serveurs de périphérie de Cloudflare terminent la connexion HTTP/2 avant qu'elle n'atteigne l'origine, donc même si un serveur d'origine était vulnérable, le schéma d'attaque serait bloqué à la périphérie de Cloudflare plutôt que d'atteindre le backend.

Cela compte pour deux raisons. Premièrement, les sites desservis par Cloudflare obtiennent une protection peu importe le serveur web d'origine qu'ils exécutent. Un client sur une configuration d'hébergement desservie par Cloudflare avec NGINX, Apache, IIS ou tout autre serveur d'origine affecté est encore protégé car la périphérie de Cloudflare filtre l'attaque. Deuxièmement, cela signifie que les clients Gotekky sur des sites desservis par Cloudflare bénéficient de deux couches indépendantes de protection : l'immunité structurelle de LiteSpeed à l'origine et l'atténuation de Cloudflare à la périphérie. L'une ou l'autre couche seule est suffisante. Les deux ensemble constituent une défense en profondeur conservatrice.

Ce que les clients Gotekky doivent savoir selon le serveur web déployé

La distinction pertinente est le logiciel qui termine réellement HTTP/2, et non le nom commercial du forfait :

• Anciens environnements partagés et revendeur utilisant LiteSpeed : structurellement non vulnérables selon l’avis. Aucune action n’était requise pour ce problème précis.
• Environnements gérés utilisant LiteSpeed : structurellement non vulnérables selon l’avis.
• Environnements gérés utilisant Apache ou NGINX : examen et version corrigée ou mesure d’atténuation applicables.
• Environnements autogérés : l’exploitant devait identifier le serveur web et appliquer les directives du fournisseur.

Si vous ne savez pas quel serveur web fonctionne dans un environnement, vérifiez depuis la ligne de commande en tant que root :

# LiteSpeed fonctionne-t-il ?
ls /usr/local/lsws/bin/lshttpd 2>/dev/null && echo "LiteSpeed installé"
ps aux | grep -E "(lshttpd|litespeed)" | grep -v grep | head -3

# Ou vérifiez ce qui écoute sur le port 443
ss -tlnp | grep -E ':80|:443'

Si lshttpd apparaît, l’environnement utilise LiteSpeed. Si vous voyez httpd, apache2 ou nginx, suivez les directives pour serveurs affectés et vérifiez la version ainsi que la configuration installées.

Pour les environnements gérés pris en charge par Gotekky, les correctifs et mesures d’atténuation sont traités selon la portée de gestion documentée. Les exploitants d’environnements autogérés doivent appliquer eux-mêmes les directives du fournisseur.

Les sites desservis par Cloudflare obtiennent une deuxième couche de protection, peu importe le serveur web d’origine. Cette protection ne remplace pas la correction de l’origine, puisque Cloudflare peut être contourné si l’adresse IP d’origine est découverte, mais elle constitue une mesure intérimaire utile.

Si vous exploitez des serveurs NGINX, Apache, IIS, Envoy ou Pingora, faites ceci aujourd'hui

Le statut des correctifs et atténuations varie selon le serveur. Au 9 juin 2026 :

NGINX

Corrigé dans NGINX 1.29.8, publié en avril 2026. Le correctif ajoute une nouvelle directive max_headers qui par défaut est à 1000 et limite le nombre d'en-têtes qu'une seule requête peut déclarer. Mettez à niveau avec le gestionnaire de paquets de votre distribution. Si vous ne pouvez pas mettre à niveau immédiatement, désactivez HTTP/2 dans votre configuration NGINX :

server {
    listen 443 ssl;
    # retirer ou commenter :
    # http2 on;
}

Désactiver HTTP/2 a des implications de performance pour les clients sur HTTPS mais élimine entièrement la surface d'attaque. C'est une atténuation temporaire viable pendant que vous planifiez la mise à niveau de NGINX.

Apache HTTPD avec mod_http2

Corrigé dans mod_http2 v2.0.41, publié à la fin mai 2026 par le mainteneur Stefan Eissing. Le correctif compte les fragments d'en-tête de cookie contre la directive existante LimitRequestFields, ce qui empêche la bombe HPACK de gonfler les allocations d'en-têtes au-delà de la limite configurée. Le correctif est disponible depuis les versions autonomes de mod_http2 et dans le tronc httpd d'Apache. Mettez à niveau via le gestionnaire de paquets de votre distribution ou recompilez depuis la source.

Si vous ne pouvez pas mettre à niveau immédiatement, vous pouvez désactiver mod_http2 dans votre configuration Apache pour forcer le repli sur HTTP/1.1 :

LoadModule http2_module modules/mod_http2.so
# Soit commenter entièrement la ligne LoadModule,
# soit retirer « h2 » de la directive Protocols :
Protocols h2 h2c http/1.1
# devient :
Protocols http/1.1

Microsoft IIS

Aucun correctif disponible au moment de la rédaction. Microsoft a été notifié par l'équipe de recherche Calif. Pour les administrateurs d'hébergement Windows, les atténuations intermédiaires recommandées sont : désactiver HTTP/2 dans la configuration IIS (paramètres du pool d'applications, paramètres avancés, Enable HTTP/2 réglé sur false), placer un WAF ou proxy inverse compatible avec le protocole HTTP/2 devant IIS qui applique des limites de nombre d'en-têtes, ou déplacer la terminaison HTTP/2 vers une périphérie de style Cloudflare.

Envoy

Correctifs initiaux publiés le 3 juin 2026. Calif valide le correctif et peut émettre des conseils supplémentaires si des lacunes restantes sont identifiées. Si vous exploitez Envoy dans le cadre d'un déploiement de maillage de services ou de passerelle d'API, mettez à niveau vers la dernière version corrigée et surveillez le blog Calif pour des conseils de suivi.

Cloudflare Pingora

Cloudflare a confirmé le 3 juin que leur atténuation DDoS de périphérie gère automatiquement les attaques HTTP/2 Bomb contre les sites protégés par Cloudflare. Aucune action client n'est requise pour les sites derrière Cloudflare. Si vous exploitez votre propre déploiement Pingora en dehors de la périphérie de Cloudflare (Cloudflare a ouvert le code source de Pingora, et certaines organisations l'exécutent indépendamment), aucun correctif n'est encore disponible et les conseils sur les serveurs affectés s'appliquent.

Ce que cela signifie pour l'industrie de l'hébergement au sens large

HTTP/2 Bomb est opérationnellement significative pour deux raisons qui vont au-delà de la vulnérabilité immédiate. Premièrement, l'attaque a été découverte par un assistant IA (Codex d'OpenAI) lisant le code source public des serveurs affectés et reconnaissant que deux techniques indépendamment documentées vieilles de dix ans se composent en une nouvelle attaque. Les chercheurs Calif notent que les deux moitiés de l'attaque ont été publiques pendant dix ans, mais qu'aucun humain ne les avait précédemment assemblées contre ces serveurs spécifiques. C'est maintenant la deuxième vulnérabilité majeure de classe serveur web en 2026 qui a été découverte par IA (après les divulgations Copy Fail et Dirty Frag du noyau Linux en avril et mai). Le schéma est établi : la revue de code assistée par IA est maintenant véritablement efficace pour trouver des vulnérabilités que les chercheurs humains ont manquées et la cadence de découverte pour les vulnérabilités à fort impact s'accélère en conséquence.

Deuxièmement, la vulnérabilité met en évidence la valeur de la diversité des serveurs web. Quand 80 % et plus du web public fonctionne sur une petite poignée de bases de code de serveurs HTTP, une vulnérabilité structurelle dans n'importe laquelle d'entre elles affecte une part énorme du trafic internet. Les 880 000 sites affectés estimés par Calif sont probablement conservateurs car ils ne comptent que les sites avec des configurations par défaut détectables. La population exposée réelle est plus grande. Les opérateurs qui ont choisi LiteSpeed (ou d'autres serveurs moins courants avec des bases de code indépendantes) sont protégés de cette attaque spécifique par chance architecturale, mais ils bénéficient aussi plus généralement de la propriété de défense en profondeur d'exécuter une pile non par défaut.

Pour les hébergeurs canadiens assujettis à la LPRPDE, à la Loi 25 au Québec et à d’autres cadres réglementaires, le risque de monoculture dans le choix du serveur web est une préoccupation opérationnelle réelle. L’utilisation historique de LiteSpeed par Gotekky sur les anciennes plateformes partagées et revendeur, ainsi que dans certains environnements gérés, précède HTTP/2 Bomb de plusieurs années. La protection obtenue dans cet incident illustre la valeur de la diversité architecturale, tandis que les environnements Apache et NGINX affectés rappellent l’importance des correctifs rapides et d’une analyse d’exposition documentée.

Le backlog complet de sécurité de l'infrastructure d'hébergement du printemps 2026 s'étend maintenant sur : le contournement d'authentification cPanel CVE-2026-41940, trois publications de sécurité d'urgence cPanel supplémentaires jusqu'en mai, le contournement d'autorisation WHMCS CVE-2026-29204, deux vulnérabilités activement exploitées du plugin LiteSpeed User-End cPanel (qui sont distinctes de LiteSpeed Web Server et affectent les serveurs cPanel exécutant ce plugin), quatre vulnérabilités distinctes d'escalade de privilèges du noyau Linux et maintenant HTTP/2 Bomb. Gotekky maintient des guides séparés pour chaque divulgation importante. Le schéma combiné reflète un environnement dans lequel le déploiement continu de correctifs et la diversité architecturale sont des attentes de base plutôt qu'un durcissement optionnel.