HTTP/3: Neue QPACK-Lücken können Server mit wenig Traffic lahmlegen

HTTP/3 soll Webseiten schneller und moderner machen. Eine neue Sicherheitsanalyse zeigt allerdings, dass genau die Header-Kompression des Protokolls bei mehreren Implementierungen zum Problem werden kann.

Forscher von FoxIO haben Schwachstellen in verschiedenen HTTP/3-Stacks gefunden, über die ein nicht angemeldeter Angreifer mit sehr wenig eingehendem Datenverkehr enorm viel Speicher auf dem Server belegen kann.

In manchen Fällen steigt der Speicherbedarf um das Tausendfache.

Im Extremfall reicht laut den Tests bereits eine einzelne Verbindung aus, um einen Server aus dem Tritt zu bringen.

Das Problem steckt in QPACK

HTTP/3 nutzt für HTTP-Header die Kompression QPACK.

Die Idee dahinter ist eigentlich sinnvoll.

Statt identische oder wiederkehrende Header immer vollständig zu übertragen, können sie über kompakte Referenzen dargestellt werden.

Das spart Bandbreite.

Problematisch wird es, wenn ein Server zwar die Größe der komprimierten Daten begrenzt, aber nicht sauber kontrolliert, wie groß diese Daten nach dem Entpacken werden.

Genau das war bei mehreren untersuchten HTTP/3-Implementierungen der Fall.

Kleine Anfrage, riesiger Speicherverbrauch

Ein Angreifer kann speziell präparierte komprimierte Header an einen HTTP/3-Server schicken.

Auf dem Netzwerk landen dabei vergleichsweise wenige Daten.

Der Server muss diese jedoch wieder in ihre vollständige Form bringen.

Wenn dabei keine sinnvolle Obergrenze für die entpackten Header existiert, kann eine kleine Datenmenge plötzlich zu hunderttausenden Header-Einträgen anwachsen.

Der Server hält diese anschließend im Speicher.

Das Ergebnis:

Ein Angreifer sendet wenig und der Server verbraucht sehr viel.

Genau diese Art von Verhältnis macht Denial-of-Service-Angriffe interessant.

Bis zu 4.000-fache Verstärkung

In den Tests von FoxIO unterscheidet sich die Stärke des Effekts deutlich je nach Implementierung.

Bei einer Angriffstechnik wird ein größerer Header zunächst einmal gespeichert.

Anschließend verweist der Angreifer tausende Male mit winzigen Referenzen auf genau diesen Header.

Der Server baut dabei jedes Mal wieder den kompletten Inhalt auf.

Bei Bun wurde dadurch laut den Forschern eine Verstärkung von ungefähr 4.000 zu 1 erreicht.

Bei lsquic lagen die gemessenen Werte ungefähr zwischen 600 und 1.800.

Das heißt vereinfacht:

Ein paar hundert Kilobyte eingehender Traffic können auf dem Server enorme Mengen Arbeitsspeicher beanspruchen.

Sieben von zehn getesteten HTTP/3-Stacks betroffen

FoxIO untersuchte insgesamt zehn HTTP/3-Implementierungen.

Bei sieben davon fanden die Forscher Probleme aus derselben grundlegenden Fehlerklasse.

Betroffen beziehungsweise zum Zeitpunkt der Veröffentlichung bereits behoben waren unter anderem:

• quic-go

• Cloudflare quiche

• lsquic

• Wireshark

Noch ungepatcht waren zum Zeitpunkt der Analyse:

• Bun

• die Rust-Bibliothek h3

• aioquic beziehungsweise mitmproxy

Damit betrifft das Thema nicht nur exotische Testsoftware.

Einige dieser Bibliotheken stecken unter bekannten Servern und Werkzeugen.

quic-go betrifft unter anderem Caddy und Traefik

Besonders relevant ist quic-go.

Die Go-Bibliothek wird unter anderem von:

• Caddy

• Traefik

• cloudflared

verwendet.

Die Schwachstelle wird dort als CVE-2025-64702 geführt.

Behoben ist sie ab:

quic-go 0.57.0

FoxIO konnte in Tests zeigen, dass ungefähr 1 MB komprimierte Header in rund 160.000 einzelne Header-Felder expandieren konnten.

Im konkreten Test belegte die Anfrage danach ungefähr 15 MB Arbeitsspeicher.

Das ist bereits deutlich mehr als ursprünglich übertragen wurde.

Das quic-go-Advisory selbst geht je nach Situation sogar von einer möglichen Verstärkung um ungefähr den Faktor 50 aus.

Cloudflare quiche ebenfalls betroffen

Auch Cloudflare quiche war betroffen.

Hier wird die Schwachstelle als:

CVE-2026-12523

geführt.

Die korrigierte Version lautet:

0.29.3

Betreiber beziehungsweise Softwareprojekte, die quiche einsetzen, sollten deshalb prüfen, welche Version tatsächlich eingebunden ist.

Gerade bei Bibliotheken wird ein Update nämlich gerne indirekt über die eigentliche Anwendung ausgeliefert.

lsquic wurde bereits im Juli korrigiert

Auch die HTTP/3-Implementierung lsquic von LiteSpeed war betroffen.

Sie wird unter anderem von:

• LiteSpeed Web Server

• OpenLiteSpeed

eingesetzt.

Die entsprechende Korrektur erschien bereits am 16. Juli 2026 mit:

lsquic 4.9.0

Der Fix begrenzt unter anderem, wie viele entpackte Header-Sätze ein Server pro Stream gleichzeitig im Speicher halten darf.

Standardmäßig ist das nur noch einer.

Damit lässt sich der Verstärkungseffekt deutlich begrenzen.

Bun ist besonders interessant

Besonders unangenehm sieht die Situation bei Bun aus.

Buns HTTP/3-Server basiert zwar auf lsquic, ersetzt aber Teile der Speicherbegrenzung durch eigenen Code.

Und genau dort entsteht ein zusätzliches Problem.

Die Implementierung prüft offenbar die Größe einzelner Header, führt aber keine korrekte Begrenzung über die Gesamtsumme durch.

Das ermöglicht deutlich größere Speicherwerte.

Laut FoxIO kann der Zähler ab ungefähr 2 GB entpackter Header-Daten sogar überlaufen und auf null zurückspringen.

Danach kann der Server in einer Schleife hängen bleiben.

Rund 516 KB können Bun festsetzen

FoxIO beschreibt einen besonders eindrucksvollen Test.

Eine einzige Verbindung mit ungefähr 516 KB übertragenen Daten konnte dazu führen, dass der Bun-Server dauerhaft bei 100 Prozent CPU-Auslastung hängen blieb.

Neue Anfragen wurden anschließend nicht mehr sauber verarbeitet.

Der Prozess erholte sich nicht von selbst.

Das ist aus meiner Sicht eines der besten Beispiele dafür, warum solche Kompressionsprobleme nicht einfach als „ein bisschen mehr RAM-Verbrauch“ abgetan werden sollten.

Wenn eine halbe Megabyte Daten einen Server dauerhaft blockieren können, ist das praktisch relevant.

Bun war zum Zeitpunkt der Veröffentlichung noch ungepatcht

Für Bun stand zum Zeitpunkt der Veröffentlichung noch keine korrigierte Version zur Verfügung.

Die Empfehlung von FoxIO ist deshalb deutlich:

HTTP/3 bei Bun vorerst nicht öffentlich exponieren.

Bun selbst bezeichnet den HTTP/3-Server laut Dokumentation ohnehin noch als experimentell.

Wer ihn produktiv erreichbar gemacht hat, sollte die Situation deshalb besonders genau prüfen.

Auch mitmproxy und h3 benötigen Workarounds

Bei aioquic beziehungsweise mitmproxy war ebenfalls noch kein finaler Patch verfügbar.

Als vorläufige Maßnahme empfiehlt FoxIO, HTTP/3 in mitmproxy abzuschalten.

Für die Rust-Bibliothek h3 gibt es ebenfalls noch keine fertige Korrektur.

Dort lässt sich das Risiko zumindest reduzieren, indem eine sinnvolle Obergrenze für die maximale Header-Größe gesetzt wird.

Ganz grundsätzlich gilt aber auch hier:

Ein echter Patch ist besser als ein Workaround.

Nicht jede HTTP/3-Implementierung ist betroffen

Die gute Nachricht:

Das Problem betrifft nicht automatisch jeden HTTP/3-Server.

FoxIO nennt mehrere Implementierungen, die in den Tests nicht anfällig waren.

Dazu gehören:

• IIS

• Envoy

• ngtcp2/nghttp3

• Googles quiche

Der Unterschied liegt vor allem darin, wann die Größe der Header begrenzt wird.

Diese Implementierungen kontrollieren die entpackte Größe bereits während der Verarbeitung.

Damit kann ein Angreifer den Speicher nicht erst unbegrenzt anwachsen lassen.

Warum HTTP/3 hier besonders interessant ist

HTTP/3 läuft über QUIC und damit über UDP.

Das unterscheidet es von HTTP/1.1 und HTTP/2, die normalerweise auf TCP aufsetzen.

Dadurch funktionieren manche klassische Filter- und Verbindungsmechanismen anders.

Ein Angreifer benötigt außerdem keinen Account.

Es reicht, den HTTP/3-Endpunkt des Servers erreichen zu können.

Für öffentlich erreichbare Webserver ist das natürlich keine ungewöhnliche Voraussetzung.

Keine Hinweise auf Datendiebstahl oder Codeausführung

Wichtig ist die Einordnung:

Die beschriebenen Schwachstellen ermöglichen nach aktuellem Kenntnisstand keine Codeausführung und keinen direkten Datendiebstahl.

Es geht um Denial of Service.

Das Ziel besteht darin, einen Dienst durch übermäßigen Speicherverbrauch oder CPU-Auslastung unbrauchbar zu machen.

Bislang sind laut Bericht auch keine öffentlich bekannten Angriffe in freier Wildbahn dokumentiert.

Trotzdem sollte man das Problem nicht ignorieren.

DoS-Schwachstellen können gerade bei öffentlich erreichbaren Diensten ziemlich lästig werden.

Auch Wireshark war betroffen

Wireshark spielt in dieser Geschichte eine etwas andere Rolle.

Dort betrifft das Problem nicht einen HTTP/3-Server.

Stattdessen kann der HTTP/3-Dissector abstürzen, wenn Wireshark verschlüsselten HTTP/3-Verkehr analysiert und dabei entsprechende Schlüssel oder bereits entschlüsselbare Capture-Daten verwendet.

Die Sicherheitslücke wird als:

CVE-2025-13945

geführt.

Behoben wurde sie in:

• Wireshark 4.6.2

• Wireshark 4.4.12

Wireshark selbst gibt an, keine bekannten Exploits für diese Schwachstelle zu kennen.

Welche Versionen sollten Administratoren prüfen?

Die wichtigsten bekannten Updates lassen sich derzeit so zusammenfassen:

Wer Software wie Caddy, Traefik oder OpenLiteSpeed nutzt, sollte zusätzlich prüfen, welche Bibliotheksversion dort tatsächlich enthalten ist.

Warum das Thema künftig wichtiger wird

HTTP/3 ist längst keine reine Zukunftstechnologie mehr.

Immer mehr Webseiten, CDNs und Reverse Proxys unterstützen das Protokoll.

Damit werden auch Fehler in QUIC- und HTTP/3-Implementierungen zunehmend attraktiver für Sicherheitsforscher.

Interessant ist außerdem, dass die Untersuchungen ursprünglich aus der Forschung zu ähnlichen Problemen bei HTTP/2 entstanden sind.

Nach den sogenannten MadeYouReset-Angriffen stellte sich offenbar die naheliegende Frage:

Gibt es bei HTTP/3 vergleichbare Möglichkeiten?

Die Antwort lautet offenbar: ja.

Nur an einer anderen Stelle.

Mein Eindruck

Ich finde diese Schwachstellen vor allem deshalb interessant, weil sie zeigen, wie gefährlich kleine Logikfehler bei Kompression werden können.

Auf den ersten Blick klingt QPACK ziemlich harmlos.

Header werden verkleinert, Bandbreite wird gespart und Webseiten laden effizienter.

Wenn die Software aber nur kontrolliert, wie klein das Paket auf der Leitung ist, und nicht, wie groß es nach dem Entpacken wird, entsteht plötzlich ein wunderbarer Verstärker für Angreifer.

Und ein Verstärker mit Faktor 4.000 ist schon eine ziemlich ordentliche Hausnummer.

Für Administratoren ist die Konsequenz trotzdem erfreulich simpel:

Version prüfen und vorhandene Updates installieren.

Fazit

Neue Schwachstellen in verschiedenen HTTP/3-Implementierungen ermöglichen Denial-of-Service-Angriffe über QPACK-komprimierte Header.

Angreifer benötigen dafür weder einen Account noch besondere Zugriffsrechte.

Durch speziell aufgebaute Header kann eine kleine Menge eingehender Daten auf dem Server einen erheblich größeren Speicherverbrauch auslösen.

In Tests wurden je nach Implementierung Verstärkungsfaktoren von mehreren hundert bis ungefähr 4.000 beobachtet.

Für quic-go, Cloudflare quiche, lsquic und Wireshark stehen bereits Korrekturen bereit.

Bun, h3 und aioquic waren zum Zeitpunkt der Veröffentlichung noch nicht vollständig gepatcht.

Wer HTTP/3 produktiv einsetzt, sollte deshalb prüfen, welche Implementierung und Version tatsächlich unter dem eigenen Webserver arbeitet.

HTTP/3 muss wegen dieser Lücken nicht abgeschaltet werden – ungepatchte HTTP/3-Stacks sollte man aber auch nicht einfach vergessen.

Quellen

The Hacker News:
New QPACK Flaws Can Crash HTTP/3 Servers, Trigger Up to 4,000-Fold Memory Amplification
https://thehackernews.com/2026/10/new-qpack-flaws-can-crash-http3-servers.html

FoxIO – technische Analyse:
https://foxio.io/blog/header-accordions-qpack-amplification-attacks-against-http-3-servers

quic-go Security Advisory:
https://github.com/quic-go/quic-go/security/advisories/GHSA-g754-hx8w-x2g6

Cloudflare quiche Security Advisory:
https://github.com/cloudflare/quiche/security/advisories/GHSA-4fgf-9xrr-88gf

lsquic Releases:
https://github.com/litespeedtech/lsquic/releases

Wireshark Security Advisory:
https://www.wireshark.org/security/wnpa-sec-2025-07.html