HTTP/2

🗓️ Contexte Publié le 2 juin 2026 sur le blog Calif (blog.calif.io), cet article présente la divulgation publique d’un exploit de déni de service distant baptisé HTTP/2 Bomb, découvert par l’IA Codex de OpenAI. La découverte a été réalisée par Quang Luong, avec confirmation par Jun Rong et Duc Phan. 🎯 Nature de l’attaque L’exploit chaîne deux techniques connues depuis une décennie : HPACK Indexed Reference Bomb : insertion d’un header dans la table dynamique HPACK (RFC 7541), puis émission de milliers de références indexées d’un seul octet. Chaque octet sur le réseau provoque une allocation mémoire côté serveur allant de ~70 octets (nginx, IIS, Pingora) à ~4 000 octets (Apache httpd, Envoy). HTTP/2 Window Stall : annonce d’une fenêtre de contrôle de flux à zéro octet, empêchant le serveur de libérer la mémoire allouée, avec envoi de trames WINDOW_UPDATE d’un octet pour maintenir la connexion ouverte indéfiniment. La nouveauté réside dans la source de l’amplification : contrairement aux bombes classiques qui stockent une grande valeur, ici le header est quasi vide et l’amplification provient du bookkeeping par entrée alloué par le serveur, contournant les limites de taille de header décodé. ...

🗓️ Contexte Publié le 3 juin 2026 sur BleepingComputer, cet article présente une nouvelle technique d’attaque par déni de service (DoS) nommée HTTP/2 Bomb, découverte par l’agent logiciel Codex d’OpenAI sous la direction de chercheurs de la société de sécurité offensive Calif. 🔍 Mécanisme de l’attaque L’attaque combine deux méthodes DoS HTTP/2 préexistantes : Amplification HPACK : un en-tête est inséré dans la table dynamique HPACK et référencé répétitivement via une représentation indexée compacte d’un seul octet. Un octet envoyé par l’attaquant peut provoquer des milliers d’octets d’allocation mémoire côté serveur (ratio jusqu’à 5 700:1 pour Envoy, 4 000:1 pour Apache httpd). Blocage de libération mémoire via flow-control HTTP/2 (style Slowloris) : en annonçant une fenêtre de contrôle de flux à zéro octet, le serveur ne peut jamais finaliser la réponse et continue d’envoyer des trames WINDOW_UPDATE pour éviter les timeouts. La mémoire allouée n’est jamais libérée. Cette combinaison permet à une seule machine sur une connexion 100 Mbps d’épuiser des dizaines de gigaoctets de RAM en quelques secondes. ...

Le CERT Coordination Center (SEI/Carnegie Mellon) publie la Vulnerability Note VU#767506 (mise en ligne le 2025-08-13, révisée le 2025-08-14) décrivant « MadeYouReset » (CVE-2025-8671), une vulnérabilité affectant de nombreuses implémentations HTTP/2 et permettant des attaques par déni de service au moyen de frames de contrôle. Des CVE spécifiques à certains produits existent, comme CVE-2025-48989 pour Apache Tomcat. 🚨 La vulnérabilité repose sur un décalage entre la spécification HTTP/2 et l’architecture interne de nombreux serveurs : après qu’un flux est annulé (reset), des implémentations continuent à traiter la requête et à calculer la réponse sans l’envoyer. Un attaquant peut provoquer des resets de flux côté serveur à l’aide de frames malformées ou d’erreurs de contrôle de flux, créant un écart entre le comptage des flux HTTP/2 (qui les considère fermés) et le nombre réel de requêtes HTTP encore en traitement en backend. Résultat : un nombre non borné de requêtes peut être traité sur une seule connexion, menant à une surcharge CPU ou une épuisement mémoire et donc à un DoS/DDoS. La faille est similaire à CVE-2023-44487 (« Rapid Reset »), mais ici l’abus exploite des resets déclenchés côté serveur. ...

Source : Gal Bar Nahum’s Blog — Le 13 août 2025, le chercheur Gal Bar Nahum a dévoilé « MadeYouReset » (CVE‑2025‑8671), une vulnérabilité HTTP/2 de type déni de service qui exploite les mécanismes de contrôle de flux/erreurs du protocole pour contourner les limites de concurrence, en collaboration avec Prof. Anat Bremler‑Barr et Yaniv Harel (Université de Tel-Aviv), avec le soutien partiel d’Imperva. 🛑 Principe clé: MadeYouReset s’appuie sur l’idée de « Rapid Reset » (2023) mais avec un twist: au lieu que le client annule la requête, l’attaquant provoque des erreurs de flux afin que le serveur émette un RST_STREAM après le démarrage d’une requête valide. Comme les flux réinitialisés ne comptent plus dans MAX_CONCURRENT_STREAMS, le serveur poursuit souvent le travail backend (calcul de réponse) malgré la fermeture du flux côté HTTP/2, ce qui permet de créer un nombre non borné de travaux concurrents et d’induire un DoS. ...