Apache HTTP/2 Açığı CVE-2026-119618: 2.4.71'e Güncelleyin

CVE-2026-119618 nedir?

CVE-2026-119618, Apache HTTP Server'da HTTP/2 trafiğini işleyen modül olan mod_http2'deki kritik bir güvenlik açığıdır; yığın (heap) belleğinin bozulmasına ve uzaktan kod çalıştırmaya yol açabilir ^[1].

Apache bunu, "Apache HTTP Server'ın mod_http2 modülünde assign_headers() içinde, paylaşılan kaynağın uygunsuz eşzamanlama ile eşzamanlı kullanımı açığı" olarak tanımlıyor ve bunun "RCE'ye yol açabileceğini" belirtiyor ^[1]. Lüksemburg'un ulusal bilgisayar acil durum müdahale ekibi CIRCL, HTTP/2 akışlarının eşzamanlı işlenmesi sırasında bir çalışanın (worker) başka bir yürütme bağlamı için ayrılmış bir başlık tablosunu değiştirebildiğini ve paylaşılan belleğe yönelik bu güvensiz erişimin yığını bozabildiğini açıklıyor ^[2].

Başarılı bir saldırgan, oturum açmadan Apache web sunucusu sürecinin ayrıcalıklarıyla kod çalıştırabilir ^[2][4]. BleepingComputer'a göre Apache HTTP Server'ın kabaca beş web sitesinden birinde çalıştığı tahmin ediliyor ^[4].

Üst akış (upstream) düzeltmesi, modules/http2/h2_request.c içindeki tek bir yazma işlemini paylaşılan istek başlığı tablosundan, mevcut isteğin kendi giriş başlıklarına çeviriyor ^[2].

Hangi Apache sürümleri etkileniyor?

Apache HTTP Server 2.4.55'ten 2.4.70'e kadar olan sürümler ile GitHub'daki bağımsız mod_h2 2.0.8'den 2.0.42'ye kadar olan sürümler etkileniyor; 2.4.71 sürümü bunu düzeltiyor ^[1].

Dağıtım paketleri sürüm kontrolünü zorlaştırıyor. CIRCL, dağıtıcı tarafından bakımı yapılan paketleri kullanan kuruluşlara yalnızca üst akış sürüm numarasına güvenmek yerine güvenlik backport'unu doğrulamalarını öneriyor ^[2]. CIRCL'in özetlediğine göre Red Hat, bellek ayırıcısı istismarı zorlaştırdığı için RHEL 9 ve 10 paketlerini Kritik değil, Önemli olarak derecelendiriyor ve RHEL 8 ile öncesini etkilenmeyen olarak bildiriyor ^[2].

Red Hat genel olarak 9,8 (Kritik) CVSS v3.1 puanı veriyor ^[2][3]. Apache'nin kendi derecelendirmesi Kritik'tir ^[1].

Apache sunucum savunmasız mı?

Yalnızca etkilenen bir sürüm çalıştırıyorsa ve HTTP/2 bağlantılarını gerçekten kabul ediyorsa: Red Hat, yalnızca HTTP/1.1 sunmak üzere yapılandırılmış sunucuların savunmasız olmadığını söylüyor ^[3]. CIRCL, yalnızca mod_http2 kurulu ya da yüklü olduğu için bu kod yoluna erişilebileceğini düşünmemek gerektiğini vurguluyor ^[2].

• HTTP/2'yi Protocols yönergesi denetler: "h2" TLS üzerinden, "h2c" ise şifresiz bağlantı üzerinden etkinleştirir ^[2].
• Apache'nin çekirdek varsayılanı http/1.1'dir ve mod_http2'yi yüklemek bunu tek başına değiştirmez ^[2]. BleepingComputer, HTTP/2'nin varsayılan olarak kapalı olduğunu belirtiyor ^[4].
• Bir sanal sunucu (virtual host) kendi Protocols yönergesini belirleyebilir; bu yüzden yalnızca genel yapılandırmaya bakmak HTTP/2 etkin bir siteyi gözden kaçırabilir ^[2].
• HTTP/2'yi bir ters proxy, yük dengeleyici veya CDN sonlandırıp Apache'ye yalnızca HTTP/1.1 iletiyorsa, istemcinin HTTP/2 oturumu tek başına Apache'yi erişilebilir kılmaz; ancak her sıçramadaki protokolü doğrulamalısınız ^[2].

CIRCL; sürümü ve yüklü modülleri (apachectl -v, apachectl -M), yapılandırılmış sanal sunucuları (apachectl -S) ve açıkça belirtilmiş her Protocols ayarını gözden geçirmeyi öneriyor ^[2]. Bir uç noktanın HTTP/2 kabul ettiğini gösteren bir test, arka ucunun savunmasız olduğunu kanıtlamaz; olumsuz bir test de her bağlantı noktasının ya da sanal sunucunun HTTP/2'yi reddettiğini kanıtlamaz ^[2].

Sunucumun HTTP/2 kabul edip etmediğini nasıl kontrol ederim?

CIRCL iki kontrol öneriyor: önce sunucunun kendisinde Apache yapılandırmasını gözden geçirin, ardından ağ üzerinden anlaşılan protokolü, mümkünse bir proxy üzerinden değil doğrudan Apache'ye bağlanarak test edin ^[2].

1. Sürümü ve modülleri kontrol edin. Sürümü görmek için apachectl -v, modülün yüklü olup olmadığını görmek için http2 için süzülmüş apachectl -M çalıştırın ^[2].
2. Sanal sunucuları listeleyin. apachectl -S yapılandırılmış tüm sanal sunucuları gösterir; her biri kendi Protocols satırını taşıyabileceği için bu önemlidir ^[2].
3. Her Protocols yönergesini bulun. CIRCL, sanal sunucu geçersiz kılmaları dahil açık Protocols ayarları için /etc/apache2 ve /etc/httpd içinde arama yapan bir grep komutu veriyor; yollar dağıtıma göre değişir ^[2].
4. TLS üzerinden test edin. HTTP sürümünü yazdıran --http2 seçenekli bir curl isteği, bir HTTPS uç noktasının HTTP/2 üzerinde anlaşıp anlaşmadığını gösterir ^[2].
5. Şifresiz bağlantıyı test edin. --http2-prior-knowledge ile curl, düz bir HTTP uç noktasının h2c kabul edip etmediğini denetler ^[2].

Sonuçları dikkatle okuyun. HTTP/2 bildiren bir yanıt, test edilen uç noktanın HTTP/2 kabul ettiğini gösterir ancak Apache arka ucunun savunmasız olduğunu doğrulamaz; olumsuz bir sonuç da her adresin, bağlantı noktasının veya sanal sunucunun bunu reddettiğini kanıtlamaz ^[2]. CIRCL'in tavsiyesi, etkin Apache yapılandırmasını ve tedarikçinin yamalı paket durumunu birlikte doğrulamaktır ^[2]. Bulut kurulumlarında Wiz, ele geçirilmiş bir Apache örneğinin yakındaki mikro hizmetlere ya da bulut meta veri uç noktalarına yanal hareket için giriş noktası olabileceği konusunda uyarıyor; bu da yalnızca herkese açık web sitesini değil her örneği kontrol etmek için bir başka neden ^[5].

CVE-2026-119618 nasıl giderilir?

Apache HTTP Server 2.4.71 veya sonrasına yükseltin ya da dağıtımınızın yamalı paketini kurun, ardından Apache'yi yeniden başlatın ve çalışan süreçlerin yeni sürümü kullandığını doğrulayın ^[2][1].

1. Apache'yi güncelleyin. 2.4.71'i ya da CVE-2026-119618 için açıkça yamalanmış bir tedarikçi sürümünü kurun ^[2].
2. Bağımsız mod_h2'yi güncelleyin kullanıyorsanız, tedarikçisinin yönergesine göre; Wiz 2.0.42'nin ötesine geçmenizi söylüyor, CIRCL ise kontrol etmeden daha yeni bir bağımsız sürümün var olduğunu varsaymamanız konusunda uyarıyor ^[5][2].
3. Yeniden başlatın ve doğrulayın: çalışan süreçler düzeltilmiş sürümü kullanmalı ^[2].
4. Henüz yama yapamıyorsanız HTTP/2'yi devre dışı bırakın: Protocols'ü http/1.1 yapın, geçersiz kılan her sanal sunucudan h2 ve h2c'yi kaldırın, apachectl -t ile test edin ve yeniden yükleyin ^[2]. Bu, açığın yolunu kapatır ancak kodu düzeltmez ^[2].
5. Erişimi kısıtlayın: ne yama ne de protokol değişikliği mümkünse, geçici bir önlem olarak güvenilen ağlara ^[2].

BleepingComputer'ın aktardığına göre watchTowr araştırmacıları durumu "şimdi yamalayın ya da yamalayana kadar h2'yi bırakın" diye özetledi ^[4]. SecurityWeek, Defiant'ın da WordPress güvenlik güncellemelerinin sorunu çözemeyeceği uyarısında bulunduğunu bildiriyor, çünkü sorun alttaki web sunucusunu etkiliyor ^[3].

CVE-2026-119618 istismar ediliyor mu?

Wiz'in 11 Kasım 2026 tarihli yazısı itibarıyla kullanılabilir bir istismar yoktu ve yaygın istismara dair bir rapor da yoktu ^[5]. Ancak tablo hızla değişiyor.

• Red Hat, kamuya açık bir araştırmanın mod_http2'nin etkin olduğu bir sunucuya karşı güvenilir bir istismar gösterdiğini söylüyor, ancak duyurusu araştırmayı belirtmiyor ^[3]. CIRCL, bunun tek başına yaygın istismarı kanıtlamadığını not ediyor ^[2].
• GitHub'daki herkese açık bir kavram kanıtı, bellek bozulmasını ve Apache çökmelerini yeniden ürettiğini bildiriyor, ancak uzaktan kod çalıştırmayı göstermiyor ^[3].
• Wiz verileri, bulut ortamlarının %64'ünün etkilenen sürümleri çalıştıran kaynaklar içerdiğini ve %51'inde herkese açık örnekler bulunduğunu gösteriyor; Wiz bunun yapılandırmayı hesaba katmadığını, dolayısıyla bunların mutlaka istismar edilebilir sistemler olmadığını belirtiyor ^[5][3].

CIRCL, araştırmaya değer işaretleri sıralıyor: beklenmedik çalışan çökmeleri, anormal yeniden başlatmalar, şüpheli alt süreçler, yetkisiz dosya değişiklikleri ve beklenmedik giden bağlantılar ^[2]. Bunlar ipuçlarıdır, doğrulanmış ele geçirilme göstergeleri değildir ve yama, güncellemeden önce kurulan kalıcılığı ortadan kaldırmaz ^[2].

Apache HTTP/2 açığını kim buldu?

Apache, açığı 26 Ekim 2026'da bildiren Anthropic'in OSS Scanner'ını ve 3 Kasım'da bağımsız olarak bildiren Google Cloud Vulnerability Research'ten Anthony Weems ile Simon Scannell'i anıyor ^[1].

Anthropic'in bulgusu ANT-2026-MAPKT6MZ iç tanımlayıcısı altında listeleniyor ^[1]. SecurityWeek iki raporu bağımsız keşifler olarak tanımlıyor ^[3]. Bu, otomatik ve yapay zekâ destekli araçların yaygın kullanılan açık kaynaklı yazılımlarda ciddi hatalar bulduğuna dair bir başka örnek; AI That Finds Security Bugs: What Glasswing and New CVEs Mean for You bu eğilimin ne anlama geldiğini ele alıyor.

Düzeltme işlendi ve 2.4.71, Apache'nin sorunu oss-security posta listesinde açıkladığı gün olan 11 Kasım'da yayımlandı ^[1][2].

Apache 2.4.71 başka neleri düzeltiyor?

Apache HTTP Server 2.4.71 toplam üç CVE'yi düzeltiyor: biri kritik, biri önemli, biri düşük ^[1].

• CVE-2026-106023 (önemli): istek işleme sırasında mod_md'de bir alt süreci çökertebilen NULL işaretçi başvurusu (dereference); 2.4.30'dan 2.4.70'e kadar olan sürümleri etkiler ^[1].
• CVE-2026-109163 (düşük): mod_vhost_alias'ta tek baytlık bir yığın (stack) arabelleği üzerine yazma; Apache bunu "CVE-2026-63292'den sonra" olarak etiketliyor (bu önceki açık 2.4.69'da düzeltildi); 2.4.69 ve 2.4.70'i etkiler ^[1].

Önceki sürüm olan Ekim 2026'daki 2.4.69, 20 CVE'yi düzeltmişti ^[1]. Onu atlayan yöneticiler, 2.4.71'e geçerek bu düzeltmeleri de almış olur. Yakın tarihli bir başka sunucu açığı için CVE-2026-98432 Explained: The Linux TCP Flaw and How to Protect Your Servers rehberine bakın.

Yöneticiler sırada neyi izlemeli?

Herkese açık bir uzaktan kod çalıştırma istismarını, dağıtımınız için tedarikçi backport'larını ve yaygın saldırı raporlarını izleyin ^[3][5].

CIRCL, HTTP/2 etkin örneklerin envanterini çıkarmayı, her mod_http2 sürümünün etkilenip etkilenmediğini kontrol etmeyi ve açıkta kalan sistemleri gecikmeden yamalamayı öneriyor; öncelik internete açık web sitelerinde, API'lerde, paylaşımlı barındırmada ve HTTP/2'yi ileten ön uçların arkasındaki Apache sunucularında ^[2]. Şüpheli etkinlik gören kuruluşlar olay müdahale prosedürlerini izlemeli ve ulusal CSIRT'leriyle iletişime geçmeli ^[2].