Betroffen sind sieben von zehn Stacks, die FoxIO untersucht hat. Ursache ist jeweils die Stelle, an der die Größe der Header begrenzt wird: Vorgesehen ist eine Obergrenze für die entpackten Header. Die verwundbaren Implementierungen begrenzen aber nur das komprimierte Paket, das über die Leitung kommt, oder setzen die Grenze zu spät an. So kann eine einzelne Anfrage zu Hunderttausenden Header-Einträgen anwachsen, die der Server im Speicher hält.

Die Reichweite ist groß, weil diese Bibliotheken unter verbreiteter Software liegen: quic-go ist die Go-Bibliothek hinter Caddy, Traefik und cloudflared; lsquic stammt von LiteSpeed und steckt im LiteSpeed Web Server sowie in OpenLiteSpeed; Buns HTTP/3-Server setzt ebenfalls auf lsquic. Ein Konto oder besondere Rechte braucht der Angreifer nicht, und da HTTP/3 über UDP läuft, erreicht die Anfrage den Server, bevor ein Großteil der üblichen Filterung greift.

Die Auswirkungen beschränken sich auf Denial of Service. Hinweise auf Datendiebstahl oder Codeausführung gibt es nicht, ebenso keine öffentlichen Meldungen über Angriffe in freier Wildbahn.

Korrekturen liegen vor für quic-go, Cloudflare quiche, lsquic und Wireshark. Zum Zeitpunkt der Offenlegung noch ohne Patch waren Bun, die Rust-Bibliothek h3 und aioquic. Als nicht betroffen führt FoxIO IIS, Envoy, ngtcp2/nghttp3 und Googles quiche auf – jeweils, weil sie die entpackten Header bereits während des Dekodierens begrenzen und nicht erst danach.

Wie stark der Verstärkungseffekt ausfällt, hängt vom Stack ab. In FoxIOs eigenen Tests gegen Standardeinstellungen entpackte sich bei quic-go ein 1 MB großes komprimiertes Paket zu rund 160.000 Header-Feldern und hinterließ etwa 15 MB in der Anfrage – etwa das 17-Fache der gesendeten Bytes. Das Advisory von quic-go selbst beziffert die mögliche Ausdehnung auf rund das 50-Fache.

Deutlich höhere Werte erreicht eine zweite Methode: Der Angreifer legt einen Eintrag von etwa 4 KB ab und verweist anschließend tausendfach mit Ein-Byte-Referenzen darauf, woraufhin der Server den vollständigen Eintrag bei jeder Referenz neu aufbaut. FoxIO maß dabei rund das 4000-Fache bei Bun und das 600- bis 1800-Fache bei lsquic.

Den schwersten Fall stellt Bun dar. Der HTTP/3-Server, den Buns Dokumentation als experimentell bezeichnet, nutzt lsquic, ersetzt aber den Teil, der den Header-Speicher begrenzt, durch eigenen Code. Dieser prüft jeden einzelnen Header, nie jedoch die laufende Summe. Überschreiten die entpackten Header 2 GB, läuft ein Größenzähler in diesem Code auf null über, und der Server gerät in eine Endlosschleife. Nach Angaben von FoxIO genügt ein einzelner Stream mit rund 516 KB auf der Leitung, um den Server dauerhaft bei 100 Prozent CPU-Auslastung festzusetzen, ohne Erholung und ohne dass neue Anfragen noch durchkommen. Erst die fehlende laufende Summe macht den Überlauf erreichbar; lsquics eigene Grenze von 64 KB verhindert ihn.

Wireshark liegt anders als die Serverfehler. Dort stürzt der HTTP/3-Dissector ab, also der Teil, der HTTP/3 aus einem Mitschnitt ausliest – und zwar wenn Wireshark Verkehr mithilfe einer Key-Log-Datei entschlüsselt oder eine Aufzeichnung öffnet, die Entschlüsselungsgeheimnisse enthält. Ein über das Netz erreichbarer Server ist das nicht. Wireshark erklärte, man habe „keine Kenntnis von Exploits für dieses Problem".

Betreibern empfiehlt FoxIO, auf die korrigierten Versionen zu aktualisieren. Für Stacks ohne Fix nennt die Firma Übergangsmaßnahmen:

  • Bun: keinen HTTP/3-Server nach außen anbieten
  • mitmproxy: HTTP/3 per –set http3=false abschalten
  • h3 (Rust): über max_field_section_size eine sinnvolle Grenze setzen

Die lsquic-Korrektur vom 16. Juli 2026 begrenzt, wie viele entpackte Header-Sätze ein Server pro Stream hält – standardmäßig einen. Ausgangspunkt der Untersuchung war laut FoxIO die Forschung von Gal Bar Nahum zu „MadeYouReset", einer Denial-of-Service-Technik gegen HTTP/2, aus der sich die Frage ergab, ob die Header-Komprimierung von HTTP/3 eine ähnliche Schwäche aufweist.