fosstr
Yazı

Apache mod_http2 CVE-2026-119618: HTTP/2 yarış koşulu nasıl RCE'ye dönüşüyor?

Apache HTTP Server 2.4.55-2.4.70 arasındaki mod_http2, paylaşılan başlık tablosundaki bir yarış koşuluyla heap bozulmasına ve uzaktan kod çalıştırmaya yol açıyor. Düzeltme 2.4.71'de.

Apache HTTP Server, internetin görünmez iş atlarından biri. Önünde CDN veya ters proxy olsa bile arka planda sayısız kurulumda hâlâ httpd çalışıyor. 11 Kasım 2026’da yayınlanan 2.4.71 sürümü, bu sunucunun HTTP/2 modülünde kritik bir açığı kapatıyor: CVE-2026-119618.

Apache açığı “kritik” olarak sınıflandırıyor. Red Hat CVSS 3.1 skorunu 9.8 veriyor. Etkilenen sürüm aralığı geniş: 2.4.55’ten 2.4.70’e kadar. Açık, HTTP/2 açık olan sunucularda kimlik doğrulaması gerektirmeden heap bozulmasına ve potansiyel olarak uzaktan kod çalıştırmaya (RCE) yol açabiliyor.

Bu yazı, açığın teknik mekanizmasını, hangi kurulumların gerçekten risk altında olduğunu ve yükseltme dışında ne yapılabileceğini anlatıyor.

Kısa özet

Alan Değer
CVE CVE-2026-119618
Önem Kritik (Apache), CVSS 9.8 (Red Hat)
Vektör AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Zayıflık sınıfı CWE-362 (uygunsuz eşitleme ile paylaşılan kaynak)
Etkilenen Apache HTTP Server 2.4.55–2.4.70, mod_h2 2.0.8–2.0.42
Düzeltme Apache HTTP Server 2.4.71, mod_h2 2.0.43
Düzeltme commit’i 824beab9b942
Bildirim Anthropic OSS Scanner (26 Ekim), Google Cloud VR (3 Kasım)
CISA KEV Hayır (12 Kasım 2026 itibarıyla)
Aktif istismar Doğrulanmış rapor yok; kamuya açık laboratuvar PoC’leri var

Açık nasıl çalışıyor?

Sorun, modules/http2/h2_request.c içindeki assign_headers() fonksiyonunda. HTTP/2’de her istek, bağlantı seviyesindeki paylaşılan bir h2_request yapısından türetiliyor. Fonksiyon önce paylaşılan başlık tablosunu isteğe özel r->headers_in yapısına kopyalıyor:

r->headers_in = apr_table_clone(r->pool, req->headers);

Sonra, gövdesiz bir istek için Content-Length başlığını sentezliyor. Normalde bu yazma işleminin isteğe özel tabloya gitmesi gerekir. Ancak hatalı kod yolu, yazmayı paylaşılan req->headers tablosuna yapıyor:

apr_table_setn(req->headers, "Content-Length", "0");

Tetikleyici istek şekli oldukça dar görünüyor: HTTP/2 üzerinden Content-Type başlığı taşıyan, Content-Length içermeyen ve hemen END_STREAM ile biten bir istek. Bu durumda assign_headers() paylaşılan tabloya Content-Length: 0 ekliyor.

Asıl mesele burada başlıyor. apr_table_t thread-safe değil. Paylaşılan tablo, HTTP/2 bağlantı iş parçacığı (connection thread) tarafından da kullanılıyor. Worker thread’in bu tabloya yazması, bağlantı thread’i aynı tabloyu okurken veya değiştirirken çalışabiliyor. apr_table_setn çağrısı, tablonun altındaki apr_array için yeniden tahsis (reallocation) tetikleyebiliyor. İki thread aynı pool/heap üzerinde yarışınca bellek bozuluyor. Bozulan heap, uygun koşullarda kontrol akışının ele geçirilmesine ve kod çalıştırmaya kadar gidebiliyor.

Kısacası: tek bir hatalı yazma hedefi, çok iş parçacıklı bir sunucuda bellek güvenliği açığına dönüşüyor.

Gerçekten istismar edildi mi?

12 Kasım 2026 itibarıyla doğrulanmış bir aktif istismar raporu yok. Açık CISA’nın Known Exploited Vulnerabilities kataloğunda değil (KEV’e girmemesi, teorik olduğu anlamına gelmez; sadece sahada gözlemlenmiş istismar kanıtı olmadığını söyler).

Ancak bunu “saldırı yok” diye okumamak lazım:

  • Apache ve Red Hat, yayın sırasında kamuya açık bir istismar bildirimi olmadığını söylüyor.
  • Kısa süre içinde bağımsız araştırmacılar, etkilenen sürümlerde heap bozulmasını gösteren laboratuvar PoC’leri ve diferansiyel test ortamları yayınladı. Yani “tetiklenemez” bir açık değil.
  • HTTP/2, Apache’nin yaygın olarak etkinleştirilen bir özelliği. Sunucunun internete bakan yüzeyi geniş.

Bu kombinasyon, yamayı ertelemek için kötü bir bahis. Özellikle açık, kimlik doğrulaması istemiyor ve ağ üzerinden tetiklenebiliyor.

Hangi kurulumlar risk altında?

Risk, üç koşulun birlikte oluşmasına bağlı:

  1. Apache HTTP Server sürümü 2.4.55 ile 2.4.70 arasında,
  2. HTTP/2 etkin: Protocols yönergesinde h2 (TLS üzerinden) veya h2c (şifresiz) var,
  3. Sunucuya güvenilmeyen bir ağdan erişilebiliyor.

Yalnızca HTTP/1.1 sunan kurulumlar etkilenmiyor. Bu ayrımı netleştirmek için:

# Sürüm
httpd -v

# mod_http2 yüklü mü?
apachectl -M | grep http2

# Protocols yönergesinde h2/h2c var mı?
grep -RniE '^\s*Protocols' /etc/httpd /etc/apache2 2>/dev/null

Varsayılan yapılandırmalarda Protocols h2 http/1.1 gibi bir satır varsa HTTP/2 açık demektir. Yalnızca http/1.1 yazıyorsa bu CVE kapsamında değilsiniz.

Ters proxy arkasındaki kurulumlar da muaf değil: proxy ile Apache arasında HTTP/2 konuşuluyorsa, açık proxy katmanında değil Apache tarafında tetiklenir.

Düzeltme: 2.4.71

Yükseltme hedefi net: Apache HTTP Server 2.4.71 veya dağıtımınızın yamalı paketi. Kaynaktan derliyorsanız:

# 2.4.71 tarball'ı ile derleyin; mod_h2 ayrı kullanılıyorsa 2.0.43'e çıkın
wget https://dlcdn.apache.org/httpd/httpd-2.4.71.tar.gz

Dağıtım paketleri her zaman upstream sürüm numarasını taşımaz. RHEL 9 ve 10’da mod_http2 ayrı bir paket olarak geliyor; düzeltme httpd değil mod_http2 paketiyle geliyor. Kontrol:

rpm -q httpd mod_http2
rpm -q --changelog mod_http2 | grep CVE-2026-119618

Debian/Ubuntu tarafında apache2 paketinin dağıtım sürümüne bakın; güvenlik güncellemesi geldiyse uygulayın:

apt update
apt install --only-upgrade apache2

Aynı 2.4.71 sürümü iki ek sorunu da kapatıyor: mod_md’de NULL pointer dereference (CVE-2026-106023, önemli) ve mod_vhost_alias’ta 1 baytlık stack taşması (CVE-2026-109163, düşük). Yani yükseltmeyi sadece bu CVE için değil, paket bütünü için yapın.

Hemen yükseltemiyorsanız

Apache bu açık için bir yapılandırma yaması yayınlamadı. En etkili geçici önlem HTTP/2’yi kapatmak:

# h2/h2c'yi Protocols satırından çıkarın
Protocols http/1.1

Bunun bedeli var: HTTP/2’nin multiplexing ve başlık sıkıştırma avantajlarını kaybedersiniz. Ama internete bakan ve yamayı hemen uygulayamadığınız sunucularda, bilinmeyen bir heap bozulması açığını açık tutmaktan iyidir.

Ek olarak:

  • Ters proxy’de HTTP/2’yi sonlandırıp backend’e HTTP/1.1 ile gitmek, Apache tarafındaki riski azaltır. Proxy ile Apache arasında h2c kullanmayın.
  • Apache’yi mümkün olduğunca düşük yetkili bir kullanıcı ve ayrı konteyner içinde çalıştırın; RCE’nin etkisini sınırlar.
  • mod_http2’ye ihtiyacınız yoksa modülü tamamen kaldırın. Kullanmıyorsanız yüklemenin bir anlamı yok.

Daha geniş ders

Bu açık, iki ayrı hikâyeyi aynı anda anlatıyor.

Birincisi, klasik bellek güvenliği: C’de paylaşılan bir veri yapısını, onu kullanan tüm thread’leri hesaba katmadan değiştirmek. apr_table_t’nin thread-safe olmadığı biliniyor; buna rağmen paylaşılan tabloya yazma yolu kodda kalmış. HTTP/2 gibi eşzamanlılığın yoğun olduğu bir modülde bu tür hatalar nadir değil, ama sonuçları ağır.

İkincisi, açığı Anthropic’in OSS Scanner aracı buldu; Google Cloud Vulnerability Research ekibi de bağımsız olarak aynı sorunu raporladı. Yani otomatik kod analizi, artık gerçek dünyada kritik RCE bulacak seviyeye geldi. Bu, yama seli tartışmasının diğer yüzü: aynı otomasyon, kodu yazarken de denetlerken de ölçeği değiştiriyor.

Pratik sonuç basit. Apache kullanıyorsanız sürümü kontrol edin, HTTP/2’nin açık olup olmadığını doğrulayın ve 2.4.71’e (veya dağıtım yamanıza) çıkın. İnternete bakan bir HTTP sunucusunda “muhtemelen tetiklenmez” yeterli bir gerekçe değil.

Kaynaklar