FoxIO: QPACK amplification, test edilen on HTTP/3 sunucusundan yedisinde belleği tüketebiliyor

HTTP/3 için yeni bir hizmet dışı bırakma sınıfı

FoxIO'daki güvenlik araştırmacıları, HTTP/3'ün bel sıkıştırma şeması olan QPACK'ta bir dizi bellek amplification açıklığı ortaya çıkardı. Hacker News ana sayfasına düşen şirket blog yazısına göre, kimlik doğrulaması yapmayan uzaktan bir istemci, sunucuyu ağ üzerindeki trafik hacminin çok ötesinde — en kötü durumda kabaca 4.000 kat fazlasını — bellek ayırmaya zorlayan bir istek gönderebiliyor. Bazı durumlarda tek bir bağlantı, sunucunun belleğini tüketmeye veya varsayılan ayarlarla bellek tavanında tutmaya yetiyor. Ekibin test ettiği on uygulamadan yedisi savunmasızdı ve birkaç geliştirici şimdiden yamaları yayımladı.

Bu çalışma, FoxIO'nun aktif TLS tarayıcısı JA4Scan için yaptığı QUIC araştırmasından doğdu ve HTTP/2 istek iptali saldırıları üzerine yazılan Gal Bar Nahum'un MadeYouReset serisinden ilham aldı; bu seri, HTTP/3'ün sıkıştırma katmanında benzer zayıflıklar olup olmadığı sorusunu gündeme getirmişti.

Amplification nasıl çalışıyor

QPACK, tekrarlanan header alanlarını, spesifikasyonun tanımladığı statik tablodan ve bağlantı boyunca oluşan dinamik tablodan alınan küçük indeks referanslarıyla değiştiriyor. FoxIO, 71 baytlık bir strict-transport-security header'ının ağ üzerinde tek bayta indiğine dikkat çekiyor. RFC 9114, sunucuların bir field section'ın çözülen (decoded) boyutunu sınırlamasını söylüyor; bu sınıra her alanın adı ve değeri ile alan başına 32 baytlık ek yük dahil. Araştırmacılar, sıkıştırılmış frame boyutunu çözülmüş boyut yerine doğrulayan, sınırları yalnızca her şeyi açtıktan sonra kontrol eden, 32 baytlık ek yükü atlayan, varsayılan olarak sınırsız kabul eden ya da bu ayarı hiç uygulamayan uygulamalar buldu.

Bundan iki saldırı varyantı türetiliyor. Araştırmacıların "header accordion" adını verdiği ilkinde, bir megabaytlık bir HEADERS frame'i, sunucunun ayrı bellek nesnelerine açmak zorunda kaldığı kabaca 160.000 benzersiz adlı header ile dolduruluyor. İkincisinde saldırgan, QPACK dinamik tablosuna yaklaşık 4 KiB'lik tek bir girdi ekleyip sonra buna binlerce kez tek baytlık işaretçilerle referans veriyor; her referans, tam girdinin yeniden ayrılmasını ve kopyalanmasını tetikleyerek kabaca 4.064'e 1'lik bir amplification oranı üretiyor.

Etkilenen uygulamalar ve yamalar

20 Ekim 2026 itibarıyla yedi savunmasız projeden dördü yamalanmış durumda. Caddy, Traefik ve cloudflared'ın altında yatan Go stack'i quic-go, sorunu 0.57.0'da düzeltti (CVE-2025-64702); orada bir megabaytlık kodlanmış blok, 160.075 alan ve yaklaşık 15 MiB tutulan heap'e çözülüyordu. Cloudflare'in quiche'i 0.29.3'te iki sorunu giderdi (CVE-2026-12523): alan başına eksik olan 32 baytlık ek yük ve bildirilen frame uzunluğundan buffer önceden ayıran bir parser — bu da saldırganın 16 MiB'lik bir frame duyurup payload'u hiç göndermemesine izin veriyordu. Araştırmacıların en derinden etkilenen olduğuna karar verdikleri lsquic, Temmuz 2026'da 4.9.0'da CVE atanmadan düzeltildi; testlerinde 50 bağlantıya yayılan 10 MiB'ın altındaki trafik, bir süreci bir saniye içinde 5 GiB'lık bellek sınırına dayandırdı. Sınırsız çözümlemeyle çökertilebilen Wireshark'ın QPACK dissector'ü ise 4.6.2 ve 4.4.12'de düzeltildi (CVE-2025-13945).

Hâlâ yamasız olanlar arasında Bun 1.4.3, bir header haritası 32.768 girdiyi aşınca panikleyen Rust h3 crate'i ve bu ayarı ayrıştırdığı halde hiç uygulamayan, mitmproxy tarafından kullanılan aioquic var. FoxIO'nun bunlara tavsiyesi: Bun'un HTTP/3 sunucusunu dışa açmayın, mitmproxy'de HTTP/3'ü kapatın ve h3 için makul bir max_field_section_size değeri belirleyin. Google'ın quiche'i, Microsoft'un IIS'i ve ngtcp2/nghttp3 etkilenmedi. Araştırmacılar ayrıca QPACK sınırlarını duyuran üretim sunucuları gözlemledi ve duyurulan ayarların sınırın gerçekten uygulandığının garantisi olmadığına dikkat çekti.

Neden önemli

QUIC üzerinden HTTP/3 artık ana akım altyapı ve bu açıklama, yedi bağımsız stack'taki varsayılan kurulumların aynı hata modunu paylaştığını gösteriyor: sıkıştırılmış girdiye güvenmek ve çözülmüş çıktıyı — uygulanıyorsa bile — çok geç doğrulamak. Bu örüntü, araştırmayı başlatan HTTP/2 sorunlarını yankılıyor ve çare iyi biliniyor: çözülmüş header'lara kümülatif bir bütçeyi, her alan çözülüp tutulduğunda artımlı olarak, sonradan değil, uygula. Etkilenen kitaplıkları çalıştıran işletmeciler hemen yükseltmeli ya da henüz yama yoksa HTTP/3'ü kapatmalı.