Temmuz başında ortaya çıkan ve XRING adı verilen kritik bir açık, XQUIC kütüphanesini kullanan HTTP/3 sunucularında ciddi servis kesintilerine yol açıyor. FoxIO güvenlik araştırmacısı Sébastien Féry tarafından keşfedilen bu zafiyet, herhangi bir kimlik doğrulama ya da bozuk paket gerektirmeden, sıradan QPACK trafiğiyle sunucu işlemini tamamen durdurabiliyor.
Hangi Sunucular Risk Altında?
XQUIC açık kaynak kodlu bir proje olduğu için, Alibaba’nın altyapısıyla sınırlı kalmıyor. Standart QPACK ayarlarıyla HTTP/3 hizmeti veren tüm sunucular etkilenebilir. Alibaba’nın Taobao ve Alipay gibi dev e-ticaret ve ödeme platformlarında kullandığı Nginx tabanlı Tengine sunucuları da bu risk altında. Mevcut en yeni sürüm v1.9.4 dahil olmak üzere tüm sürümlerde açık mevcut ve henüz resmi bir yama ya da CVE tanımlaması bulunmuyor.
Açığın Teknik Detayları ve Çökme Mekanizması
HTTP/3 protokolünde header bilgisini sıkıştırmak için QPACK adı verilen bir yöntem kullanılır. Bu yöntem, ortak bir tabloyu kontrol kanalı üzerinden dinamik olarak günceller. XQUIC ise bu tabloyu ‘ring buffer’ denilen döngüsel bir bellek yapısında tutuyor. Tablo büyütüldüğünde, eski veriler yeni, daha büyük belleğe kopyalanıyor. Ancak bu kopyalama işlemi sırasında, verinin tamponun sonundan başına doğru sarması durumunda yanlış bir hesaplama yapılıyor. Örneğin, 64 baytlık bir tablo 65 bayta çıkarılırken, 6 baytlık veri yerine 70 bayt veri kopyalanmaya çalışılıyor.
Bu aşırı kopyalama bellek taşmasına, yani buffer overflow’a neden oluyor. Ubuntu 26.04 üzerinde yapılan testlerde glibc’nin güvenlik mekanizması _FORTIFY_SOURCE=2 sayesinde süreç hata verip kapanıyor. Ancak bu koruma olmasaydı, bellek taşması daha ciddi sorunlar yaratabilirdi. Şimdilik bu durum sadece sunucu çökmesine yol açıyor; henüz kötü amaçlı kod çalıştırma ya da daha derin bir istismar gözlemlenmedi.
Benzer Zafiyetler ve Gelişmeler
XRING, HTTP/3 ve HTTP/2 protokollerinde son aylarda ortaya çıkan uzaktan çökertme açıkları zincirinin son halkası. Yaklaşık üç hafta önce, NGINX’in HTTP/3 modülünde bir use-after-free sorunu tespit edilmişti (CVE-2026-42530). Bu açık da benzer şekilde QPACK encoder akışını hedef alıyor ancak farklı bir hata tipi. Haziran ayında ise HTTP/2’nin header sıkıştırma yöntemi HPACK üzerinden yapılan ‘HTTP/2 Bomb’ saldırısı, Nginx, Apache, IIS ve Envoy sunucularını hedef almıştı. Ayrıca Şubat ayında HAProxy, token doğrulama sırasında tam sayı taşması içeren iki QUIC çökme açığını yamalamıştı.
Sistemi Koruma ve Müdahale Önerileri
Şu an için resmi bir yama yayınlanmadığından, sistem yöneticileri SETTINGS_QPACK_MAX_TABLE_CAPACITY değerini sıfıra çekerek QPACK’ın dinamik tablo özelliğini devre dışı bırakabilir ya da HTTP/3 desteğini tamamen kapatabilirler. Bu önlemler, saldırganların tablonun büyütülmesini tetiklemesini engelliyor ve sunucunun çökmesini önlüyor.
Ayrıca olay müdahale ekipleri, ağ trafiğinde QPACK encoder stream üzerinde anormal paket hareketlerini izlemeli, sistem loglarını detaylı takip etmeli ve EDR çözümleriyle bellek taşması girişimlerine karşı tetikte olmalı. Ağ segmentasyonu ve çok faktörlü kimlik doğrulama gibi katmanlı güvenlik yaklaşımları da bu tip zafiyetlerin etkisini azaltabilir.
İstismar Girişimleri ve Şeffaflık
FoxIO araştırmacısı, hatayı Nisan ayında Alibaba’ya ilettiğini, ancak üç iş günü içinde yanıt alamayınca Mayıs ayına kadar dört kez daha bildirimde bulunduğunu açıkladı. Sonuç alamayınca bulgularını kamuoyu ile paylaştı. Şu ana kadar doğrudan bir istismar tespit edilmedi.
Bu tür protokol açıkları, özellikle bulut altyapıları ve kritik web servisleri için ciddi riskler barındırıyor. Türkiye’de de HTTP/3 kullanan hizmetler bulunduğu için, sistem yöneticilerinin bu gelişmeleri yakından takip edip önlem alması gerekiyor. Özellikle e-posta güvenliği ve bulut güvenliği uygulamalarında, protokol bazlı saldırı vektörlerine karşı hazırlıklı olmak kritik.