1. Vue d'ensemble

CVE-2026-49975 (« HTTP/2 Bomb ») est une vulnérabilité de déni de service distante et non authentifiée affectant le module mod_http2 du serveur HTTP Apache. Elle enchaîne deux faiblesses HTTP/2 connues de longue date :

1. Bombe de comptabilité HPACK — une petite requête HTTP/2 encodée en HPACK provoque la fusion de plusieurs fragments d'en-tête Cookie sans qu'ils soient comptabilisés par rapport à LimitRequestFields, forçant le serveur à allouer de la mémoire de manière répétée pour ses structures internes de comptabilité d'en-têtes.
2. Blocage de contrôle de flux (style Slowloris) — le client annonce une fenêtre de contrôle de flux proche de zéro, retardant la transmission de la réponse et maintenant le(s) flux concerné(s) ouvert(s), ce qui empêche la libération de la mémoire allouée.

Le résultat : un seul client sur une connexion modeste peut forcer une allocation mémoire importante et soutenue sur la cible aussi longtemps que le flux est maintenu ouvert. Cette implémentation prend en charge deux modes de charge utile et évolue linéairement avec la concurrence que vous configurez :

• mode nginx — plante un en-tête x-bomb vide dans la table dynamique HPACK et le référence de manière répétée (~70:1 d'amplification par référence).
• mode classic — plante à la place un en-tête cookie surdimensionné (~4000:1 d'amplification par référence).

Chaque connexion référence à nouveau l'en-tête planté des milliers de fois par flux (--headers, par défaut 5000), sur plusieurs flux par connexion (--streams, par défaut 10) et plusieurs connexions parallèles (--threads, par défaut 1). Si le serveur ferme une connexion, l'outil se reconnecte immédiatement et continue jusqu'à l'arrêt manuel — il s'agit d'une boucle de maintien continu, pas d'une sonde ponctuelle unique.

Identifiants associés pour d'autres piles affectées (non implémentés ni testés par ce dépôt) :

• Envoy → CVE-2026-47774
• Microsoft IIS, Cloudflare Pingora → suivis séparément, aucun CVE référencé ici

Portée complète de la classe de faiblesse sous-jacente, par souci d'exhaustivité — la technique « HTTP/2 Bomb » (bombe de compression HPACK + maintien de contrôle de flux) affecte plusieurs implémentations de serveurs au-delà d'Apache. Ce dépôt n'implémente et ne teste que le cas Apache ; le reste est inclus pour que les lecteurs comprennent la classe plus large, et non parce que ce PoC les exerce :

Références (sources primaires — vérifiez toutes les affirmations de manière indépendante) :

• Enregistrement CVE : https://www.cve.org/CVERecord?id=CVE-2026-49975
• Entrée NVD : https://nvd.nist.gov/vuln/detail/CVE-2026-49975
• Avis Apache / liste des vulnérabilités : https://httpd.apache.org/security/vulnerabilities_24.html
• Journal des modifications d'Apache 2.4.68 (référence du commit de correction) : https://dlcdn.apache.org/httpd/CHANGES_2.4.68
• Article de découverte original : https://blog.calif.io/p/codex-discovered-a-hidden-http2-bomb

2. Portée de ce dépôt

Ce dépôt contient :

• Un script PoC minimal qui reproduit le comportement de bombe HPACK en maintien seul contre une cible que vous êtes autorisé à tester.
• Ce README, documentant la vulnérabilité, la chronologie de divulgation et les conditions d'utilisation sûre.

Ce dépôt ne contient pas :

• D'automatisation pour scanner Internet à la recherche d'hôtes vulnérables.
• De logique d'inondation/maintien de DoS, de montée en charge de concurrence, ou de listes d'identifiants/cibles.
• De code ciblant par défaut un système actif spécifique. La cible doit être explicitement fournie par l'opérateur.

3. ⚖️ Avis juridique et éthique

Lisez ceci avant toute autre chose.

• Ce PoC est publié strictement à des fins éducatives et de recherche en sécurité défensive — pour aider les opérateurs à vérifier leur propre exposition et pour soutenir la trace publique d'une vulnérabilité déjà divulguée et déjà corrigée.
• Vous devez disposer d'une autorisation explicite et documentée du propriétaire du système avant d'exécuter ceci contre toute cible qui n'est pas votre propre infrastructure ou un système que vous êtes contractuellement/légalement autorisé à tester (par exemple, une mission de test d'intrusion signée, un périmètre de bug bounty, ou une permission écrite).
• Exécuter ce PoC contre des systèmes que vous ne possédez pas ou pour lesquels vous n'avez pas d'autorisation de test — y compris, mais sans s'y limiter, les agences gouvernementales, les forces de l'ordre, les infrastructures critiques, ou tout système de production tiers — sans permission est illégal dans la plupart des juridictions (en Indonésie, cela relève de l'UU ITE) et peut constituer une infraction pénale ailleurs.
• Le(s) auteur(s) de ce dépôt :
  • N'assument aucune responsabilité quant à l'usage abusif de ce code.
  • Ne cautionnent pas l'utilisation de ce PoC pour perturber, dégrader ou refuser le service à tout système sans autorisation.
  • Fournissent ce code tel quel, sans garantie d'aucune sorte.
• Si vous êtes un éditeur, une agence ou un opérateur de système qui a trouvé ce dépôt parce que votre système a été testé : voir Section 6 — Chronologie de divulgation pour savoir comment cela a été signalé et à qui.

En téléchargeant, clonant ou exécutant tout code de ce dépôt, vous acceptez d'être seul responsable de vous assurer que vous disposez de l'autorisation appropriée, et vous acceptez l'entière responsabilité légale de votre utilisation de celui-ci.

4. Méthode de reconnaissance

CVE-2026-49975 ne s'applique qu'à une cible qui satisfait les deux critères de la Section 1 — joignable via HTTP/2 et exécutant une version de mod_http2 vulnérable et dans la plage (2.4.17 ≤ version ≤ 2.4.67, configuration par défaut). Un simple curl -vkI contre le port HTTPS de la cible suffit pour vérifier les deux — aucun scanner ni option supplémentaire nécessaire :

Ce qu'il faut rechercher dans la sortie :

• ALPN: server accepted h2 — le serveur a négocié HTTP/2 pour cette connexion. C'est la condition préalable à CVE-2026-49975, puisque le bug réside dans mod_http2 ; un serveur qui n'a jamais accepté h2 ici n'est pas un candidat.
• L'en-tête de réponse Server (visible une fois que les en-têtes de réponse HEAD s'affichent, plus bas dans la sortie -v) — c'est ce qui confirme ou exclut la version réelle d'Apache/mod_http2 par rapport à la plage vulnérable de la Section 1. L'acceptation ALPN seule ne confirme pas la version — cela nécessite toujours l'en-tête Server ou une vérification de bannière équivalente.

Rien d'autre n'est utilisé pour la reconnaissance dans ce dépôt — pas de trafic d'exploitation actif, pas de scanners de vulnérabilités, pas de balayages de ports.

5. Prérequis

• Runtime : Go 1.26+ (module : cve202649975)
• Dépendances : golang.org/x/net v0.59.0 (résolu automatiquement via go build)
• Accès réseau : joignabilité TCP directe vers la cible autorisée sur le port spécifié (par défaut 443, TLS/h2 par défaut ; --no-ssl pour h2c en clair)
• Optionnel : proxychains4 — si le binaire est lancé sous proxychains4, il détecte le wrapper LD_PRELOAD, lit le même proxychains4.conf, et route ses propres connexions à travers ce proxy SOCKS5 (résolution DNS distante) — utile lorsqu'un périmètre de mission exige de tester depuis un chemin de sortie spécifique
• Permissions : autorisation écrite / lettre de mission pour la cible testée

6. Chronologie de divulgation

Chronologie publique de CVE-2026-49975 lui-même : signalé à Apache le 2026-05-26 ; correctif intégré en amont dans mod_h2 le 2026-05-27 ; fusionné dans la branche httpd 2.4.x le 2026-06-02 ; Apache HTTP Server 2.4.68 publié le 2026-06-08.

7. Utilisation

N'exécutez ceci que contre une cible que vous êtes explicitement autorisé à tester. Il n'y a pas de limite de durée intégrée ni de mode sûr — vous êtes responsable de la durée d'exécution et de la concurrence.

Compilation :

Exécution :

Exemple, test de laboratoire autorisé minimal :

Comportement à attendre :

• Affiche un résumé pré-vol (cible, mode, nombre de connexions/flux, mémoire côté serveur estimée) avant d'envoyer quoi que ce soit.
• Maintient les flux ouverts avec des gouttes de WINDOW_UPDATE de 1 octet et des pings périodiques ; se reconnecte automatiquement et répète si le serveur ferme la connexion.
• Ne s'arrête que lorsque vous envoyez Ctrl+C / SIGTERM — planifiez votre fenêtre de test en conséquence et surveillez la mémoire de la cible en temps réel.
• Recommandé : validez d'abord contre un environnement de préproduction/laboratoire avec des --streams/--headers faibles avant tout test de production autorisé, et ayez un plan de retour arrière/redémarrage pour le service cible prêt dans tous les cas.

7a. Estimation de la pression RAM

Formule approximative de la mémoire côté serveur pour les deux modes de cet outil (Apache mod_http2 uniquement — voir la Section 1 pour la correspondance entre nginx/classic et le ratio d'amplification) :

Augmentez threads/streams/headers et le nombre croît linéairement — c'est pourquoi un test de laboratoire autorisé doit commencer bas (voir Section 7) avant toute exécution en périmètre de production.

7b. Détails techniques

Ceci documente le mécanisme que ce PoC spécifique implémente contre Apache mod_http2 — cela ne s'étend pas aux autres implémentations de serveurs, qui sont hors périmètre pour ce dépôt (voir Section 2).

Amorce de la table dynamique HPACK (indexation incrémentale, ajoute une entrée à l'index 62) :

Référence indexée à cette entrée (1 octet chacune, répétée --headers fois) :

Séquence de trames HTTP/2 par connexion :

Le coût sur le réseau est faible et majoritairement fixe par flux (une poignée d'octets pour l'amorce + 1 octet par référence) ; c'est l'allocation côté serveur qui croît de manière disproportionnée — cet écart est la vulnérabilité.

7c. Exemple de sortie

Sortie d'une exécution de laboratoire autorisée, mode classic, 20 connexions × 30 flux/connexion, 5000 références HPACK/flux, routée via proxychains :

Chaque connexion rapporte indépendamment sa propre contribution RAM locale au fur et à mesure qu'elle ouvre des flux (~572 MB par connexion à ces réglages) ; le chiffre pré-vol Est. server RAM est l'agrégat sur les 20 connexions (~11,4 GB) une fois que chaque connexion est entièrement ouverte et maintenue.

domain.com ci-dessus est un espace réservé — remplacez-le par votre cible autorisée réelle lorsque vous documentez votre propre exécution, et masquez-le si la mission est confidentielle.

8. Remédiation

• Apache HTTP Server : mettre à niveau vers httpd 2.4.68 ou ultérieur (c'est la version contenant le correctif).
• Si la mise à jour immédiate n'est pas possible :
  • Définir LimitRequestFields de manière conservatrice et surveiller le comportement de fusion des en-têtes.
  • Envisager de désactiver HTTP/2 sur l'écouteur affecté jusqu'à la mise à jour.
  • Placer le service derrière un proxy inverse/WAF qui impose un plafond strict du nombre d'en-têtes.
• Retester après remédiation pour confirmer que le comportement de maintien-et-libération ne cause plus de croissance mémoire soutenue.

9. Crédits / Attribution

Découverte et divulgation originales de la vulnérabilité à Apache (sans lien avec ce dépôt ou son auteur) :

• Quang Luong, Calif.IO, en collaboration avec OpenAI Codex
• Signalé au Apache HTTP Server Project le 2026-05-26 ; ligne de crédit officielle publiée dans le journal des modifications 2.4.68

Ce dépôt (réimplémentation en Go, écrite et testée après la publication du correctif public) :

• Auteur : naheeju
• PoC indépendant construit à partir de la description publique de la vulnérabilité et du diff du correctif, à des fins de vérification/éducation contre des cibles autorisées. Non affilié à la découverte originale, à Calif.IO, ni à l'Apache Security Team.

Questions, corrections, ou préoccupations liées à la divulgation responsable concernant ce PoC spécifique : ouvrez une issue sur ce dépôt.

Licence : MIT (code de ce dépôt uniquement — voir LICENSE). Ne s'étend pas aux découvreurs originaux ni à l'Apache Software Foundation, et n'implique aucun aval de leur part.