Une seule connexion suffit à épuiser la mémoire des serveurs HTTP/3 affectés par les failles QPACK

22 octobre 2026. Le cabinet FoxIO publie une classe de failles dans QPACK, le mécanisme de compression des en-têtes de HTTP/3, et livre un proof of concept fonctionnel. 22 octobre 2026. Les correctifs sont déjà sortis pour quic-go, quiche et lsquic, mais Bun, la bibliothèque Rust h3 et aioquic restent non corrigés. Aucune exploitation n’a encore été observée en conditions réelles. Pourquoi c’est important : un attaquant non authentifié peut faire tomber un serveur HTTP/3 avec une seule connexion, en envoyant quelques kilo-octets qui se transforment en centaines de milliers d’entrées conservées en mémoire.

QPACK compresse les en-têtes, et c’est là que ça casse

HTTP/3 abandonne TCP au profit d’UDP, et remplace la compression d’en-têtes HPACK de HTTP/2 par QPACK, défini dans la RFC 9204. Le principe reste le même : les champs d’en-tête qui se répètent — user-agent, cookie, les valeurs longues d’un appel d’API — voyagent une première fois en entier, puis sont référencés par un code court. C’est ce qui rend le protocole économe en bande passante sur le réseau.

Le contrat implicite est simple : un serveur doit plafonner la taille des en-têtes après décompression, pas seulement la taille du paquet reçu. FoxIO a constaté que sept des dix stacks HTTP/3 qu’il a testés appliquent le plafond au flux compressé qui arrive sur le fil, mais pas au résultat décompressé, ou l’appliquent trop tard. Une seule requête peut alors gonfler jusqu’à plusieurs centaines de milliers d’entrées d’en-tête que le serveur garde en mémoire.

La compression est plafonnée, pas la décompression

Le défaut tient à un déséquilibre d’amplification. FoxIO a mesuré, sur les réglages par défaut de chaque stack, ce que devient un lot compressé une fois déplié. Sur quic-go, 1 Mo compressé a produit environ 160 000 champs d’en-tête et laissé près de 15 Mo retenus dans la requête — environ 17 fois les octets envoyés ; l’avis de quic-go chiffre l’expansion possible à environ 50 fois.

Une seconde méthode pousse le ratio bien plus haut. L’attaquant stocke une seule entrée d’environ 4 Ko, puis la référence des milliers de fois avec des pointeurs d’un octet ; le serveur reconstruit l’entrée complète à chaque référence. FoxIO a mesuré environ 4 000 fois sur Bun, et entre 600 et 1 800 fois sur lsquic. Le résultat est un déni de service pur : pas de vol de données, pas d’exécution de code, mais une machine qui s’effondre sous sa propre mémoire.

L’attaque est d’autant plus simple à déclencher qu’elle n’exige aucun compte ni privilège. Comme HTTP/3 circule sur UDP, la requête atteint le serveur avant l’essentiel des filtrages réseau qui s’appliquent d’ordinaire à TCP. Le vecteur n’est pas un zero-day de la couche applicative : c’est le protocole lui-même qui récompense l’asymétrie entre ce qui est envoyé et ce qui est stocké.

Le tableau des stacks touchés

La portée est large parce que ces bibliothèques se cachent sous des logiciels très répandus. quic-go est la bibliothèque Go derrière Caddy, Traefik et cloudflared ; lsquic est celle de LiteSpeed, utilisée par LiteSpeed Web Server et OpenLiteSpeed ; le serveur HTTP/3 de Bun tourne, lui, sur lsquic.

FoxIO classe comme non affectés IIS, Envoy, ngtcp2/nghttp3 et la quiche de Google, chacun plafonnant les en-têtes décompressés pendant le décodage plutôt qu’après. C’est précisément ce contrôle-là qui manque aux stacks vulnérables.

Bun : le cas le plus grave

Bun cumule les problèmes. Son serveur HTTP/3, que la documentation qualifie d’« expérimental », s’appuie sur lsquic mais remplace la partie qui plafonne la mémoire des en-têtes par son propre code — un code qui vérifie chaque en-tête isolément, jamais le total cumulé. FoxIO a constaté qu’une fois les en-têtes dépassant 2 Go, un compteur interne déborde à zéro et le serveur entre dans une boucle dont il ne sort plus. Un seul flux d’environ 516 Ko sur le fil laisse le processus bloqué à 100 % de CPU, sans récupération possible, refusant toute nouvelle requête.

C’est l’absence de total cumulé qui rend le débordement atteignable : le plafond de 64 Ko de lsquic l’empêche normalement. Sur Bun, la seule mesure raisonnable en attendant un correctif est de ne pas exposer de serveur HTTP/3. Pour mitmproxy, coupez HTTP/3 avec --set http3=false ; pour la bibliothèque Rust h3, fixez une limite explicite via max_field_section_size.

Wireshark, un cas à part

Wireshark n’est pas un serveur qu’un attaquant joint sur le réseau : sa faille fait planter le dissecteur HTTP/3, la partie qui lit HTTP/3 dans une capture, lorsque l’outil déchiffre le trafic à l’aide d’un fichier de clés ou ouvre un fichier contenant les secrets de déchiffrement. Wireshark indique n’avoir connaissance d’aucune exploitation. L’impact est celui d’un outil d’analyse qui crashe, pas d’une surface d’attaque exposée — mais les analystes qui traitent des captures QUIC doivent tout de même monter en 4.6.2 ou 4.4.12.

Verdict

Si vous exposez un serveur HTTP/3, la première question n’est pas « suis-je vulnérable ? » mais « quel stack tourne en dessous ? ». Derrière Caddy, Traefik ou cloudflared, c’est quic-go : montez en 0.57.0. Derrière LiteSpeed ou OpenLiteSpeed, c’est lsquic : montez en 4.9.0. Si vous tournez sous Bun, désactivez le serveur HTTP/3 — c’est aujourd’hui le seul chemin sûr, le débordement à 2 Go rendant la panne irrécupérable. Si vous maintenez un service basé sur h3, fixez max_field_section_size, et sur mitmproxy, coupez HTTP/3 le temps que aioquic soit corrigé.

Au-delà du correctif immédiat, retenez la leçon structurelle : le passage à HTTP/3 a déplacé la surface d’attaque vers UDP et vers la décompression d’en-têtes. Ce n’est pas un incident isolé — FoxIO a commencé ce travail après les recherches de Gal Bar Nahum sur MadeYouReset, une technique de déni de service contre HTTP/2. La question de fond reste la même que celle que nous posions sur le filtrage BGP de Cloudflare : quand un protocole déplace la confiance du réseau vers l’application, c’est à l’application de faire le travail de plafonnement que le réseau ne fera plus.

Références

• The Hacker News — New QPACK Flaws Can Crash HTTP/3 Servers, Trigger Up to 4,000-Fold Memory Amplification
• FoxIO — Header Accordions: QPACK Amplification Attacks Against HTTP/3 Servers
• GitHub — quic-go advisory CVE-2025-64702
• GitHub — Cloudflare quiche advisory CVE-2026-12523
• Wireshark — wnpa-sec-2025-07