Tomcat 11.0.26, başlıkları yanlış isteğe ekleyebilen HTTP/2 regresyonunu düzeltiyor

Ne oldu

Apache, 15 Eylül 2026'da Tomcat 11.0.26'yı yayımladı ve sürümün güvenlik sayfasında, CVE-2026-86350 kimlikli HTTP/2 istek işleme kusuruna ilişkin Önemli (Important) dereceli bir kayıt yer alıyor. dev.to'da yayımlanan bir yazıya göre sorun, Tomcat güvenlik ekibi raporu 23 Eylül 2026'da özel listesinden herkese açık duyuruya taşıdığında kamuoyuna duyuruldu; özgün rapor 28 Ağustos 2026'da gönderilmişti.

Belirleyici ayrıntı, bunun yepyeni bir kusur değil bir regresyon olması. Hata, daha önceki bir HTTP/2 işleme hatası olan CVE-2026-41293 için gelen yamayla birlikte geldi ve 11.0.22'den 11.0.25'e kadar olan sürümlerde düzeltilmeden kaldı.

Hata nasıl çalışıyor

O önceki düzeltmenin getirdiği kod, HTTP/2 isteklerini bağlayıcının geri kalanından farklı davranan bir yol boyunca ayrıştırıyor. Bu farklılık nedeniyle, bir isteğe ait başlık alanları aynı bağlantı üzerindeki başka bir isteğe — muhtemelen farklı bir istemciye ait olabilecek bir isteğe — kaydedilebiliyor.

dev.to'daki yazı iki pratik sonucu açıkça ortaya koyuyor. Önbelleğe alınmış veya proxy üzerinden geçirilmiş yanıtlar yanlış istemciye verilebilir ve başlıklardan türetilen her türlü güvenlik kararı — yönlendirme kuralları, hız sınırlama benzeri denetimler — yanlış isteğe göre değerlendirilebilir.

Önem derecesi konusunda Tomcat sorunu Önemli (Important) olarak etiketledi ve bir CVSS vektörü yayımlamadı. dev.to'nun atıf yaptığı securityonline.info derlemesi, sorunu CWE-444 kapsamında 9.1 olarak puanlıyor; ancak bu rakam üreticiden değil, toplayıcıdan geliyor. Duyuruda herhangi bir kavram kanıtı (proof-of-concept) kodu bulunmuyor ve incelenen kaynaklarda sahada sömürüldüğüne dair doğrulanmış bir bilgi yok.

Etkilenen sürümler ve maruziyet

Bakımı yapılan üç dal etkileniyor:

• 11.0.22 ile 11.0.25 arası
• 10.1.55 ile 10.1.59 arası
• 9.0.118 ile 9.0.121 arası

Tomcat 8.5 için bu CVE'ye ilişkin bir kayıt yok.

Kapsam dahilindeki kurulumlar, HTTP/2'yi doğrudan Tomcat bağlayıcısında sonlandıranlar. HTTP/2'yi kapalı tutan ya da TLS ve HTTP/2'yi üst katmandaki (upstream) bir proxy'de sonlandıran dağıtımların pratik yüzeyi daha küçük.

Bağlam için, dev.to raporu, Apache Tomcat için yapılan bir ZoomEye sorgusunun internete açık 580.597 varlık döndürdüğünü, bu CVE'ye kısıtlı bir sorgunun ise sıfır eşleşme döndürdüğünü belirtiyor. Dolayısıyla ürün düzeyindeki sayı, bu sunuculardan kaçının gerçekte etkilenen bir derlemeyi çalıştırdığı hakkında hiçbir şey söylemiyor.

Çözüm

Çözüm, hangi dal kullanılıyorsa 11.0.26, 10.1.60 veya 9.0.122 sürümüne geçmek. Yüklenen akış (upstream) commit'leri şunlar: 11.0.x için 192bc749, 10.1.x için 259e938d ve 9.0.x için 5adadc4e.

Yükseltmeyle birlikte iki pratik uyarı geliyor. Birincisi, bir paket adına güvenmek yerine üretimde gerçekte çalışan derlemeyi doğrulayın; çünkü container imajları ve dağıtım geri taşımalı (backport) paketleri genellikle yüklenen akış sürümünün gerisinde kalır. İkincisi, yükseltmenin bir bakım penceresini beklemesi gerekiyorsa, bağlayıcıda HTTP/2'nin etkin olup olmadığını kontrol edin ve bu arada devre dışı bırakmayı değerlendirin. HTTP/2 erişim günlüklerini beklenmedik başlık örüntülerine karşı incelemek ve üst katmandaki bir proxy'de başlık doğrulamasını güçlendirmek ikincil denetimler olarak öneriliyor.

Neden önemli

Aynı HTTP/2 bağlantısını paylaşan istekler arasındaki başlık sızıntısı, neredeyse hiçbir uygulama kodunun sorgulamadığı bir varsayımı bozuyor: bir istek üzerindeki başlıklar o isteğe aittir. Başkasının oturum belirteci, yönlendirme adresi veya API anahtarını taşıyarak gelen bir istek, önbellek katmanlarını sessizce zehirleyebilir, hız sınırlamayı bozabilir veya trafiği yanlış yönlendirebilir; günlüklerde sebebe açıkça işaret eden hiçbir şey olmaz.

Regresyon boyutu da önemli. CVE-2026-41293'ü düzeltmek için hızla yükseltme yapan ekipler, tam da burada açıkta kalan ekipler; bu da güvenlik yamalarının sadece kurulmakla kalmayıp doğrulanması gerektiğinin bir hatırlatıcısı. Çözüm basit; ancak çalışan derlemeyi doğrulamak — özellikle container tabanlı dağıtımlarda — en çok atlanma ihtimali olan adım.