#Homelab · 4 Min. Lesezeit · Tim Rinkel

SPEICHER-BOMBE! Ein winziger HTTP/3-Request bläht sich 4.000-fach auf — Caddy und Traefik sind im Spiel

SPEICHER-BOMBE! Ein winziger HTTP/3-Request bläht sich 4.000-fach auf — Caddy und Traefik sind im Spiel

Ein paar Kilobyte gehen über die Leitung, ein Vielfaches davon landet im Arbeitsspeicher deines Servers. Das Sicherheitsunternehmen FoxIO hat bei 7 von 10 getesteten HTTP/3-Implementierungen dieselbe Schwäche gefunden. Der Bericht von The Hacker News stammt vom 22. Oktober 2026, die Forscher haben funktionierenden Proof-of-Concept-Code veröffentlicht.

WAS IST QPACK?

QPACK ist das Verfahren zur Header-Kompression in HTTP/3. Es spart Bandbreite, indem es wiederkehrende Header kurz referenziert. Genau das wird zum Hebel: Betroffene Stacks begrenzen die komprimierte Eingabe, aber nicht die entpackten Header — oder zu spät. Eine einzige Anfrage kann so zu Hunderttausenden Header-Einträgen anwachsen.

DIE ZAHLEN

  • quic-go: 1 MB komprimierte Daten werden zu etwa 160.000 Header-Feldern und rund 15 MB Arbeitsspeicher, grob das 17-Fache. Der quic-go-Hinweis nennt bis zu 50-fach.
  • Wiederholte Verweise: Ein Angreifer legt einen Eintrag von rund 4 KB ab und verweist tausendfach mit Ein-Byte-Referenzen darauf. Das erreicht etwa 4.000-fach bei Bun und 600- bis 1.800-fach bei lsquic.
  • Bun im schlimmsten Fall: Bei mehr als 2 GB entpackter Header läuft ein Zähler über und steht auf null. Der Server dreht dann endlos. Ein Stream von rund 516 KB reicht laut Bericht, um ihn dauerhaft auf 100 % CPU festzunageln. Bun markiert den HTTP/3-Server in der Doku als experimentell.

Die Folgen sind Dienstverweigerung. Hinweise auf Datendiebstahl oder Codeausführung gibt es nicht, und bekannte Angriffe in freier Wildbahn ebenfalls nicht. Ein Account ist für den Angriff nicht nötig.

WER BETROFFEN IST — UND WER NICHT

Stack Status Fix
quic-go gefixt 0.57.0 (CVE-2025-64702)
Cloudflare quiche gefixt 0.29.3 (CVE-2026-12523)
lsquic gefixt 4.9.0 (keine CVE)
Wireshark gefixt 4.6.2 / 4.4.12 (CVE-2025-13945)
Bun, h3 (hyperium), aioquic/mitmproxy ungepatcht —

Nicht betroffen sind laut FoxIO IIS, Envoy, ngtcp2/nghttp3 und Googles quiche, weil sie die entpackten Header schon beim Dekodieren begrenzen. Zu nginx macht der Bericht keine Angabe.

WAS DAS FÜR DEIN HOMELAB HEISST

Die meisten dürften die Schwäche nicht direkt, sondern über Software darunter haben:

  • quic-go steckt in Caddy, Traefik und cloudflared.
  • lsquic steckt in LiteSpeed Web Server und OpenLiteSpeed sowie im HTTP/3-Server von Bun.

Die Fixes für quic-go und lsquic liegen vor. Ob dein Caddy- oder Traefik-Release sie schon enthält, musst du in den jeweiligen Release-Notes nachsehen — der Bericht nennt das nicht.

SO SCHÜTZT DU DICH

  1. Updaten: Reverse-Proxys und Web-Server auf die aktuelle Version bringen und im Changelog nach quic-go oder lsquic suchen.
  2. Bun: HTTP/3-Server nicht ins Netz stellen.
  3. mitmproxy: HTTP/3 mit --set http3=false abschalten.
  4. Rust-h3: Mit max_field_section_size ein vernünftiges Limit setzen.
  5. Zur Not: HTTP/3 am Proxy vorübergehend deaktivieren. Browser fallen automatisch auf HTTP/2 zurück.

FAZIT: Unscheinbar, aber breit

Ein Totalausfall durch eine einzelne Anfrage ist kein Weltuntergang, aber lästig — besonders für Selbsthoster, die ihre Dienste ohne Vorfilter ins Netz stellen. Der Fall zeigt: Wer Kompression erlaubt, muss auch die ausgepackte Größe begrenzen.

Häufige Fragen

Was bringt ein Angreifer mit dieser Lücke fertig?
Er kann Server mit manipulierten Anfragen in die Knie zwingen: Sie fressen Arbeitsspeicher oder hängen mit voller CPU-Last. Zugriff auf Daten oder Codeausführung ist laut Bericht nicht möglich, und es braucht kein Konto. Bekannte Angriffe in freier Wildbahn gibt es bisher nicht, der Proof-of-Concept ist aber öffentlich.
Ist mein Caddy oder Traefik betroffen?
Beide nutzen quic-go für HTTP/3. Dort gibt es einen Fix in Version 0.57.0. Ob dein installiertes Release ihn enthält, musst du in den Release-Notes der Software nachsehen; der Bericht macht dazu keine Angabe. Als Vorsichtsmaßnahme kannst du HTTP/3 am Proxy vorübergehend abschalten, Browser nutzen dann HTTP/2.
Muss ich HTTP/3 komplett abschalten?
Nicht zwingend. Wenn deine Software auf eine gefixte Version aktualisiert ist, kannst du es angeschaltet lassen. Für ungepatchte Stacks wie Bun, den Rust-Crate h3 oder mitmproxy nennt der Bericht Zwischenlösungen: nicht exponieren, Limits setzen oder HTTP/3 abschalten. Browser wechseln bei Ausfall automatisch auf HTTP/2.
Was hat Wireshark damit zu tun?
Wireshark stürzt im HTTP/3-Dissector ab, wenn Datenverkehr mit einer Key-Log-Datei entschlüsselt oder ein Mitschnitt mit Entschlüsselungsgeheimnissen geöffnet wird. Das ist kein aus dem Netz erreichbarer Serverfehler. Gefixt ist es in 4.6.2 und 4.4.12, Exploits sind Wireshark nach eigener Aussage nicht bekannt.

Quellen

Kommentar hinterlassen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert