Des chercheurs en cybersécurité ont découvert une faille de déni de service à distance qui affecte les principaux serveurs web, notamment NGINX, Apache HTTPD, Microsoft IIS, Envoy et Cloudflare Pingora.

La vulnérabilité a été nommée HTTP/2 Bomb par Calif.

« Ce comportement vulnérable existe dans la configuration HTTP/2 par défaut de chaque serveur », a déclaré la société, ajoutant qu’il avait été découvert par OpenAI Codex en combinant deux techniques connues : une bombe de compression et une technique de blocage de type Slowloris .

« Cette bombe cible HPACK, le mécanisme de compression d’en-tête du protocole HTTP/2 : un octet transmis correspond à l’allocation d’un en-tête complet sur le serveur, et ce, des milliers de fois par requête », a ajouté Calif. « Le blocage consiste en une fenêtre de contrôle de flux de zéro octet qui empêche le serveur de libérer la moindre quantité de mémoire. »

HPACK est un algorithme de compression d’en-tête dédié à HTTP/2, utilisé pour compresser les métadonnées des requêtes et des réponses grâce au codage de Huffman, ce qui permet une réduction moyenne de 30 % de la taille des en-têtes. Il est également conçu pour résister aux attaques telles que CRIME (pour « Compression Ratio Info-leak Made Easy »), qui peuvent divulguer les cookies d’authentification contenus dans les en-têtes compressés.

Slowloris, en revanche, est un type d’attaque par déni de service (DoS) qui permet à un attaquant de saturer un serveur ciblé en ouvrant et en maintenant de nombreuses connexions HTTP simultanées entre l’attaquant et la cible. Il s’agit d’une attaque de la couche application.

La bombe HTTP/2 s’inspire de diverses approches connues comme la bombe HPACK (alias CVE-2016-6581 ), qui a été divulguée pour la première fois en 2016, ainsi que CVE-2025-53020 , une vulnérabilité d’épuisement de la mémoire dans l’implémentation HTTP/2 d’Apache httpd, et deux failles DoS dans le serveur HTTP Apache déclenchées via des trames CONTINUATION conçues ( CVE-2016-8740 ) et la famine des threads de travail ( CVE-2016-1546 ) dans une connexion HTTP/2.

« La nouveauté réside dans l’origine de l’amplification », explique Calif. « La bombe classique insère une valeur importante dans la table et y fait référence de manière répétée, ce qui a incité les serveurs à limiter la taille totale de l’en-tête décodé. Notre variante fonctionne à l’inverse : l’en-tête est quasiment vide, et l’amplification provient de la gestion des entrées que le serveur alloue autour de celui-ci. La limite de taille décodée n’est jamais atteinte car il n’y a presque rien à décoder. »

Dans un scénario d’attaque hypothétique, un ordinateur personnel connecté à un réseau de 100 Mbps peut rendre un serveur vulnérable inaccessible en quelques secondes. De plus, un seul client peut monopoliser 32 Go de mémoire serveur avec Apache HTTPD et Envoy en une vingtaine de secondes.

Pour contrer cette vulnérabilité, il est conseillé d’appliquer les mesures d’atténuation suivantes :

• NGINX – Mettez à jour vers la version 1.29.8 ou supérieure, qui ajoute la directive max_headers avec une valeur par défaut de 1000. Si la mise à jour n’est pas possible, il est recommandé de désactiver HTTP/2 avec la commande http2 off;.
• Apache HTTPD – Corrigé dans mod_http2 v2.0.41 . Si la mise à niveau n’est pas possible, il est recommandé de désactiver HTTP/2 en configurant les protocoles http/1.1.
• Microsoft IIS, Envoy et Cloudflare Pingora – Aucun correctif disponible à l’heure actuelle.

« Le problème fondamental réside dans le fait que la spécification réduit le risque lié à la mémoire à un simple facteur d’amplification, or ce facteur ne représente que la moitié du problème », a déclaré Calif. « Un amplificateur de 70:1 est inoffensif si la mémoire est libérée une fois la requête terminée. Cela devient une attaque car HTTP/2 permet au client de maintenir la connexion ouverte quasiment gratuitement, en bloquant chaque octet alloué aussi longtemps qu’il le souhaite. »