ModSecurity 3.0.17: CVE-2026-104269 ile Dosya Adı Kuralı Atlatma, CVE-2026-73856 ile Cevap Denetimi Kaçağı

ModSecurity nedir, nerede kullanılır? (What is ModSecurity)

ModSecurity, OWASP çatısı altında geliştirilen açık kaynaklı bir web uygulama güvenlik duvarı (WAF) motorudur. Apache, nginx ve LiteSpeed gibi web sunucularına eklenir ve çoğunlukla OWASP Core Rule Set (CRS) kurallarıyla birlikte çalışır. Paylaşımlı hosting panellerinin pek çoğu ModSecurity'yi hazır bir seçenek olarak sunar. Kuralların işe yaraması için motorun isteği ve cevabı arka uç uygulamayla aynı şekilde yorumlaması gerekir; iki açık da tam bu noktada ortaya çıkıyor.

CVE-2026-104269: filename* ile dosya adı karmaşası (Multipart parser interpretation conflict)

Dosya yükleme isteklerinde her parçanın Content-Disposition başlığında dosya adı bulunur. RFC 2231 bu başlıkta iki parametreye izin verir: düz filename ve kodlanmış filename*. İkisi birlikte gönderildiğinde filename* öncelikli sayılır; Go, Python, Node.js ve Java'nın yaygın ayrıştırıcıları da böyle davranır.

ModSecurity 3.0.0'dan 3.0.17'ye kadar bu önceliği uygulamıyordu. Saldırgan düz parametreye zararsız bir ad (resim.jpg), kodlanmış parametreye başka bir ad yazarak dosya adı kurallarını atlatabiliyor: güvenlik duvarı birini, arka uç diğerini görüyor. Açık CWE-436 (yorum çatışması) olarak sınıflandırıldı ve bütünlük etkisi yüksek. Kayıtta PHP'nin kendi multipart ayrıştırıcısının etkilenmediği belirtiliyor; risk, filename* parametresini öncelikli okuyan uygulamalarda.

CVE-2026-73856: cevap denetiminde harf duyarlılığı (Response body inspection bypass)

ModSecurity, sunucunun gönderdiği cevabın gövdesini de denetleyebilir. Hata mesajı, yığın izi ya da veritabanı bilgisi sızdıran cevapları engelleyen kurallar 4. aşamada (phase 4) bu gövdeye bakar. Hangi içerik türlerinin denetleneceği SecResponseBodyMimeType yönergesiyle belirlenir.

Sorun şu: motor cevaptaki Content-Type değerini bu listeyle büyük-küçük harfe duyarlı karşılaştırıyordu. Uygulama Text/Html gibi karışık harfli bir tür döndürdüğünde cevap "denetlenmeyecek tür" sayılıyor ve 4. aşama kuralları hiç çalışmıyor. HTTP'de içerik türleri harfe duyarsız olduğu için tarayıcı sayfayı normal gösteriyor. Açığın gizlilik etkisi yüksek; kimlik doğrulama gerektirmeden, engellenmesi gereken hata ya da hata ayıklama bilgisinin okunmasına yol açabiliyor.

Aynı sürümdeki diğer düzeltmeler (Other fixes in 3.0.17)

SecurityOnline'ın Ekim başındaki haberine göre 3.0.17 ve 2.9.15 sürümleri şu sorunları da gideriyor:

• XML gövdesi işlenirken başlatılmamış işaretçi kullanımı (özel hazırlanmış bir istekle süreç çökmesi)
• Desteklenmeyen HTML varlıklarıyla kural atlatma; t:htmlEntityDecode dönüşümü bazı varlıkları çözmüyordu (2.9.14 ve öncesi de etkileniyor)
• Uzak kural indirmede libcurl ayarı nedeniyle zayıflayan TLS sunucu adı doğrulaması

Kavram kanıtı kodlar bulunuyor, ancak yayın tarihi itibarıyla aktif bir saldırı bildirilmedi.

Sürüm kontrolü ve güncelleme (Check and upgrade)

# Debian / Ubuntu
dpkg -l | grep -i modsecurity

# RHEL / AlmaLinux / Rocky
rpm -qa | grep -i mod_security

# Apache error log'da motor sürümü
grep -i "ModSecurity for" /var/log/apache2/error.log | tail -1

# nginx bağlayıcısı kullanıyorsanız kitaplık sürümü
ldconfig -p | grep libmodsecurity

• Dağıtım paketi kullanıyorsanız güvenlik deposundan gelen güncellemeyi kurun ve web sunucusunu yeniden başlatın.
• libmodsecurity'yi kaynaktan derlediyseniz v3.0.17 etiketinden yeniden derleyin; nginx bağlayıcısı da yeni kitaplıkla bağlanmalı.
• Güncellemeden sonra CRS kurallarının yüklendiğini ve test isteklerinin engellendiğini doğrulayın.

Güncelleyemeyenler için geçici önlemler (Mitigations)

• CVE-2026-73856 için: Uygulamanın içerik türlerini küçük harfle döndürdüğünden emin olun; SecResponseBodyMimeType listesine karışık harfli varyantları da ekleyin.
• CVE-2026-104269 için: Dosya türü kontrolünü yalnız WAF'a bırakmayın. Uygulama tarafında dosya içeriğinin türünü (ilk baytlarını) kontrol edin ve yüklenen dosyaları çalıştırılabilir olmayan bir dizine kaydedin.
• XML sorunu için: Gerekmiyorsa SecParseXmlIntoArgs yönergesini kapatın.

WAF tek başına bir koruma değildir; uygulamanın kendi doğrulaması ve güncel sunucu yazılımı ile birlikte işe yarar. Alesta WEB web yazılım projelerinde dosya yüklemelerini uygulama katmanında ayrıca denetler. Sunucu tarafındaki diğer güncel açıklar için OpenSSH sshole yazımıza bakabilirsiniz.

Sık sorulan sorular

Paylaşımlı hosting kullanıyorum, bir şey yapmam gerekir mi?

ModSecurity'yi hosting firması yönetir. Firmanızın 3.0.17 veya 2.9.15'e geçip geçmediğini sorabilirsiniz. Kendi tarafınızda yapılacak en önemli şey, yükleme formlarında dosya türünü uygulama içinde de kontrol etmektir.

ModSecurity 2.x kullananlar etkileniyor mu?

CVE-2026-104269 ve CVE-2026-73856 kayıtları 3.x aralığını gösteriyor. HTML varlık çözme sorunu 2.9.14 ve öncesini de etkiliyor; 2.x kullananlar 2.9.15'e geçmeli.

OWASP CRS'yi güncellemek yeterli mi?

Hayır. Sorunlar kurallarda değil motorun kendisinde. Kural setini güncellemek motor açıklarını kapatmaz.

Bu açıklar uzaktan kod çalıştırmaya yol açar mı?

Doğrudan hayır. Ancak dosya adı kuralını atlatan bir saldırgan, uygulamada başka bir zayıflık varsa zararlı dosya yükleyebilir.

İlgili sayfalar: Web hosting · Web yazılım hizmetleri · APT CVE-2026-109518 · İletişim

Kapak fotoğrafı: Raysonho @ Open Grid Scheduler / Grid Engine / Wikimedia Commons (CC0)