Nieuwe QPACK-kwetsbaarheden HTTP/3 kunnen veel HTTP/3-webservers laten crashen of volledig laten vastlopen. Wat dit extra vervelend maakt: een aanvaller heeft geen inloggegevens nodig en kan met één verbinding al een denial-of-service opzetten.
Onderzoekers van FoxIO publiceerden werkende proof-of-concept-code. De kern zit in QPACK: het mechanisme waarmee HTTP/3 verzoekheaders comprimeert. Door een slimme set gecomprimeerde headers kan de server bij het uitpakken veel méér headerinformatie in het geheugen opbouwen dan hij “had binnengekregen”.
Wat is er mis met QPACK bij HTTP/3?
HTTP/3 gebruikt QPACK om repetitieve headervelden niet steeds opnieuw tekstueel te versturen. In plaats daarvan komen er korte codes mee, die de server moet terugvertalen naar volledige header entries.
Volgens FoxIO is de bedoeling helder: na het uitpakken moet de server een limiet hanteren op de hoeveelheid headers die uiteindelijk in het geheugen terechtkomt. In meerdere HTTP/3-implementaties ontbreekt zo’n controle óf wordt die te laat toegepast. Daardoor kan één enkel verzoek exploderen in enorme aantallen header entries die de server moet bijhouden.
Waarom kan één verzoek zo veel geheugen kosten?
De aanvaller stuurt een relatief kleine “batch” gecomprimeerde HTTP-headers. Bij het uitpakken zetten de getroffen stacks die batch om naar een veel grotere set headers. Het resultaat: de server kan zo veel geheugen vasthouden dat een standaardinstantie uit het geheugen loopt (of blijft doordraaien).
In FoxIO-tests varieert de amplificatie per stack. Bij quic-go unpackte bijvoorbeeld ongeveer 1 MB gecomprimeerde data tot rond 160.000 header fields, met grofweg 15 MB in het verzoek dat in het geheugen werd gehouden—ruim zeventien keer zoveel als de ontvangen bytes. De quic-go-adviseur noemt zelfs een mogelijke uitbreidingsfactor van circa 50x.
Er is bovendien een tweede techniek die de verhouding nog hoger kan trekken door header entries herhaaldelijk te “refereren” en de server telkens opnieuw te laten opbouwen. FoxIO rapporteerde ongeveer 4.000x bij Bun en tussen 600x en 1.800x bij lsquic.
Wie is getroffen en wie niet (zoals FoxIO dat meldt)
FoxIO stelt dat de foutklasse in zeven van tien HTTP/3-stacks werd gevonden die zij testten. Omdat deze libraries onder diverse producten zitten, kan de impact breder zijn dan “alleen maar een losse webserver”.
De onderzoekers benoemen ook stacks waarvan ze zeggen dat die niet zijn geraakt. Dit zijn onder andere:
- IIS
- Envoy
- ngtcp2/nghttp3
- Google’s quiche
Volgens FoxIO komt dit doordat die implementaties het aantal uitgepakte headers beperken tijdens het decoderen, in plaats van alleen de gecomprimeerde batch te cappen of de limiet pas later toe te passen.
De grootste zorgen: Bun, lsquic en quic-go
De grootste praktische problemen liggen bij implementaties waar de totale hoeveelheid uitgepakte headerinformatie onvoldoende wordt begrensd.
Bun: experimentele HTTP/3 server en een overflow-scenario
FoxIO beschrijft een worst-case situatie bij Bun. Bun’s HTTP/3 server gebruikt lsquic, maar vervangt volgens FoxIO het deel dat normaliter headergeheugen cap’t. In plaats daarvan controleert de code elke header, maar houdt de lopende totale hoeveelheid niet correct bij.
FoxIO meldt dat wanneer uitgepakte headers de grens van 2 GB passeren, een counter overflowt naar nul. Daarna start de server een loop waar hij niet meer uit lijkt te komen.
In dat scenario kan één stream met ongeveer 516 KB over de wire ervoor zorgen dat de server 100% CPU vasthoudt, zonder herstel, waardoor nieuwe requests geblokkeerd raken.
lsquic en quic-go: fixes beschikbaar
Voor sommige stacks zijn al reparaties beschikbaar. FoxIO geeft aan dat fixes zijn uitgebracht voor quic-go, Cloudflare quiche, lsquic en Wireshark.
Specifiek: de lsquic-fix is volgens FoxIO gepubliceerd op 16 juli 2026. Die cap’t hoeveel uitgepakte header sets een server per stream vasthoudt—standaard op één.
Ook bij quic-go zijn updates beschikbaar. Omdat quic-go doorwerkt in meerdere omgevingen (zoals Caddy, Traefik en cloudflared), is het belangrijk om te checken of je indirect via een bundel of webtool de vulnerabele library draait.
Geen datadiefstal, maar wel directe uitval
FoxIO benadrukt dat de QPACK-kwetsbaarheden gaan om denial-of-service. Er is geen bewijs van data-exfiltratie of code execution. Ook melden de onderzoekers geen openbare gevallen in “the wild”.
Toch is de operationele impact groot: een server die vastloopt of uit het geheugen raakt, kan onbeschikbaar worden voor legitieme gebruikers. Daarbij geldt: HTTP/3 loopt over UDP, waardoor het verzoek sneller bij de server kan aankomen voordat gebruikelijke filtering veel kan uitrichten.
Wireshark: ander type probleem, geen remote server-aanval
Niet alle QPACK-gerelateerde aandacht betekent hetzelfde risico voor production. FoxIO beschrijft ook een Wireshark-issue, maar die richt zich op het crashen van de HTTP/3-dissector wanneer Wireshark verkeer ontcijfert met een key-log file of wanneer je een capture opent die decryptie-secrets bevat.
Wireshark gaf aan dat men geen exploits kent voor deze issue. Dat is dus iets anders dan een remote aanval op een HTTP/3 webserver.
Wat kun je nu doen? (upgrade en mitigaties)
De meest effectieve stap is upgraden naar de gefixte releases die door de betrokken projecten zijn uitgebracht. FoxIO noemt daarbij specifiek de fixes voor quic-go, Cloudflare quiche, lsquic en Wireshark.
Voor stacks waar nog geen fix beschikbaar was ten tijde van de disclosure, geeft FoxIO interim-mitigaties:
- Bun: stel voor om een HTTP/3 server niet bloot te stellen.
- mitmproxy: zet HTTP/3 uit via de optie –set http3=false.
- h3 (Rust library): zet een passende limiet met max_field_section_size.
Als je wilt weten waar je precies kwetsbaar kunt zijn, kijk dan niet alleen naar je webframework, maar ook naar de onderliggende QUIC/HTTP/3 libraries die in je stack zitten.
Extra context: waarom dit zo lijkt op eerder DoS-onderzoek
FoxIO koppelt de lsquic-reparatie aan eerder onderzoek naar “MadeYouReset”, een den-of-service techniek tegen HTTP/2. De onderzoeksvraag was daarbij of de headercompressie in HTTP/3 een vergelijkbare zwakte zou kunnen bevatten.
Het resultaat laat zien hoe belangrijk het is dat grenzen niet alleen op ingangsdata gelden, maar ook op wat de server intern opbouwt na decompressie en decoding.
Gerelateerde aandachtspunten
Omdat dit soort DoS-aanvallen sterk samenhangt met kwetsbaarheden in netwerkprotocollen en parsers, is het nuttig om ook bredere patch- en incidentpraktijken te bekijken. Je kunt bijvoorbeeld lezen hoe teams reageren bij AI-agent runtime security issues in AI-agent runtime security: Beacon en beleid—niet hetzelfde protocol, maar wél dezelfde focus op snelle beheersmaatregelen en controlemechanismen.
Conclusie
QPACK-kwetsbaarheden HTTP/3 vormen een serieus beschikbaarheidsrisico. Hoewel er geen aanwijzingen zijn voor datadiefstal of code execution, kan een aanvaller zonder account via een enkele verbinding een server laten crashen of langdurig vastzetten door extreme geheugenvergroting bij header-uitpak.
Upgrade waar fixes beschikbaar zijn, controleer of je indirect via Caddy, Traefik, cloudflared of andere tooling kwetsbare QUIC/HTTP/3 libraries gebruikt, en pas interim-mitigaties toe voor stacks zonder directe patch. Zo voorkom je dat “kleine” gecomprimeerde pakketten in de praktijk uitgroeien tot grote downtime.
Bron: https://thehackernews.com/2026/10/new-qpack-flaws-can-crash-http3-servers.html
