Attaque sur des implémentations HTTP/2 entraînant l'épuisement de la mémoire disponible

Des informations ont été révélées sur la vulnérabilité « HTTP/2 Bomb », affectant diverses implémentations du protocole HTTP/2 et permettant de provoquer un déni de service en épuissant toute la mémoire disponible du processus. La présence du problème a été confirmée dans les serveurs HTTP nginx, Apache httpd (CVE-2026-49975), Microsoft IIS, Envoy (CVE-2026-47774) et Cloudflare Pingora dans leur configuration par défaut.

La vulnérabilité utilise une méthode similaire à celle d'une bombe ZIP, appliquée à la fonctionnalité de compression des en-têtes dans HTTP/2. L'idée est que la requête peut contenir des milliers d'en-têtes compressés, tels que « Cookie », sans données attachées, chacun d'eux étant représenté dans la requête par une référence d'un octet dans l'index HPACK, mais nécessite le serveur une allocation complète de mémoire pour l'ensemble de l'en-tête. Le niveau de consommation mémoire dans différents serveurs HTTP varie d'environ 70 octets pour chaque octet dans l'index pour nginx, IIS et Pingora, jusqu'à 4000 octets dans Apache httpd et 5700 dans Envoy. Lors d'une attaque depuis un ordinateur personnel ayant une connexion de 100 Mbps, il faut environ 10 secondes pour épuiser 32 Go de mémoire lors d'une attaque contre serveur Envoy 1.37.2, 18 secondes pour Apache httpd 2.4.67 et 45 secondes pour nginx 1.29.7.

Pour bloquer la vulnérabilité, la directive max_headers a été déplacée dans la version 1.29.8 de nginx du projet freenginx, qui par défaut autorise le traitement de plus de 1000 en-têtes. Dans Envoy, le correctif
a été inclus dans les versions 1.35.11 et 1.36.7, dans lesquelles sont mis en œuvre les limites mutable_max_request_headers_kb et max_headers_count. Dans Apache httpd, le correctif a été proposé dans la version du module mod_http2 2.0.41, qui n'a pas encore été intégrée dans les versions d'Apache httpd. Pour
Microsoft IIS et Cloudflare Pingora, des correctifs sont encore absents.
Comme solution de contournement pour la protection, il est possible de désactiver l'utilisation du protocole HTTP/2 et de définir une limite sur la quantité de mémoire disponible pour les processus.

Source : opennet.ru