Konuyu Okuyanlar: 4 Ziyaretçi

NGINX ve Juniper Ekim 2026: CVE-2026-15176 Dahil 5 NGINX Açığı ve Junos Yamaları

NGINX ve Juniper Ekim 2026: CVE-2026-15176 Dahil 5 NGINX Açığı ve Junos Yamaları
[Resim: attachment.php?aid=148]

Selam arkadaşlar,

Bu hafta altyapı tarafında iki büyük yama paketi birden geldi. NGINX ekibi 14 Ekim'de nginx 1.30.6 (stable) ve 1.31.7 (mainline) sürümleriyle beş güvenlik açığını kapattı; aynı dönemde F5 ve Juniper Networks da kendi ürün ailelerinde kritik açıklar için güncelleme yayımladı. İnternete bakan sunucuların önemli bir kısmının önünde NGINX olduğunu düşünürsek, bu konuyu "sonra bakarım" listesine atmamak lazım.

Konuda Anlatılacaklar
  1. NGINX'teki beş açık ve tetiklenme koşulları
  2. Puanlama farkı: NGINX "orta" diyor, F5 "kritik"
  3. Yapılandırmanız etkileniyor mu? Hızlı kontrol
  4. Juniper'ın ekim paketi
  5. Yama ve geçici önlem önerileri
  6. Kaynaklar

NGINX'teki Beş Açık

Bu açıkların ortak noktası, çoğunun yalnızca belirli yapılandırmalarda tetiklenmesi. nginx.org güvenlik bildirimleri ve The Hacker News'in derlemesine göre:

1. CVE-2026-15176 - alias + rewrite + $request_filename
Bellek bozulması türünde bir açık. Bir location bloğunda alias, rewrite ve $request_filename değişkeninin birlikte kullanıldığı yapılandırmaları etkiliyor. Etkilenen sürümler 0.1.29 - 1.31.6; yani neredeyse projenin tüm geçmişi kapsamda. Açığı F5'in kendisi bulmuş.

2. CVE-2026-93479 - map içindeki regex yakalamaları
map bloğundaki düzenli ifade yakalamalarının root veya log_format içinde kullanılmasıyla tetikleniyor. Etkilenen sürümler 1.30.0 - 1.30.5 ve 1.31.2 - 1.31.6. The Hacker News'e göre hata, temmuzda yayımlanan CVE-2026-42533 düzeltmesine dayanıyor. Bulan isimler: Matt Suiche (Tolmo) ve Mateusz Gierblinski.

3. CVE-2026-95101 - HTTP/3 istek gövdesi enjeksiyonu
HTTP/3 etkinken ve proxy_request_buffering on (varsayılan değer) durumunda istek gövdesine veri enjeksiyonu yapılabiliyor. Etkilenen sürümler 1.25.0 - 1.31.6. Bulan: Hansol Lee (GOTROOT). F5'in geçici önerisi proxy_request_buffering değerini off yapmak.

4. CVE-2026-97629 - TLS oturum bileti anahtar rotasyonu
ssl_session_cache shared kullanılıp ssl_session_ticket_key tanımlanmadığında ortaya çıkan bir mantık hatası. Etkilenen sürümler 1.23.2 - 1.31.6. Kaynaklara göre bu hata, deterministik olmayan şekilde istemci sertifikası kontrolünün atlanmasına yol açabiliyor; mTLS ile korunan uç noktalar için ciddi bir durum. Bulan: PhiNode Labs.

5. CVE-2026-97205 - AIO + SSI use-after-free
aio etkinken SSI include virtual kullanımında, 256'da sıfıra dönen 8 bitlik bir sayaç nedeniyle use-after-free oluşuyor. Etkilenen sürümler 0.8.11 - 1.31.6.



Puanlama Farkı: "Orta" mı, "Kritik" mi?

İlginç bir ayrıntı: NGINX projesi beş düzeltmenin hepsini "orta" (medium) önem derecesiyle işaretlemiş. F5'in CVSS v4 puanları ise farklı bir tablo çiziyor: bellek bozulması türündeki açıklar 9.2, TLS açığı 8.3, HTTP/3 açığı 6.9.

SecurityWeek'in haberine göre F5 toplamda 11 NGINX sorununu düzeltti ve CVE-2026-15176, CVE-2026-93479 ile CVE-2026-97205'i kritik olarak sınıflandırdı. Bu üç açığın, ASLR devre dışıysa ya da atlatılabilirse uzaktan kod çalıştırmaya imkân verebileceği belirtiliyor. Aradaki fark büyük ölçüde şu: NGINX, açığın tetiklenmesi için gereken özel yapılandırmayı hesaba katarak "orta" diyor; F5'in puanı ise koşullar sağlandığında ortaya çıkan etkiyi yansıtıyor.

İyi haber: Beş açığın hiçbiri CISA KEV kataloğunda değil ve aktif sömürü raporu yok. Kötü haber: The Hacker News, VulnCheck'e dayanarak mayıstaki CVE-2026-42945'in yayımlanmasından birkaç gün sonra sömürülmeye başlandığını hatırlatıyor. Bu, NGINX'in 2026'daki sekizinci güvenlik sürümü; araştırmacıların bu koda yoğun ilgi gösterdiği açık.

Aynı dönemde njs 1.0.2 sürümü de CVE-2026-101025 ve CVE-2026-101019'u düzeltti; njs modülünü kullananlar onu da güncellemeli.

Yapılandırmanız Etkileniyor mu?

Önce sürümünüze bakın:
Kod:
nginx -v

Sonra çalışan yapılandırmanın tamamını (include edilen dosyalar dahil) döküp riskli direktifleri arayın:
Kod:
nginx -T 2>/dev/null | grep -nE "alias|rewrite|request_filename"

Kod:
nginx -T 2>/dev/null | grep -nE "^\s*map |log_format|root "

Kod:
nginx -T 2>/dev/null | grep -nE "listen .*quic|http3|proxy_request_buffering"

Kod:
nginx -T 2>/dev/null | grep -nE "ssl_session_cache|ssl_session_ticket_key|ssl_verify_client"

Kod:
nginx -T 2>/dev/null | grep -nE "aio |ssi on|include virtual"

Bu aramalar size sadece incelemeniz gereken satırları gösterir; bir direktifin var olması tek başına zafiyetli olduğunuz anlamına gelmez. Örneğin ilk açık için alias, rewrite ve $request_filename'in aynı location bağlamında birlikte kullanılması gerekiyor.

Dağıtım paketlerini kullananlar için:
Kod:
apt list --installed 2>/dev/null | grep -i nginx rpm -qa | grep -i nginx
Dağıtımlar düzeltmeleri genellikle kendi sürüm numaralarına geri taşıdığı (backport) için paket sürümünü dağıtımın güvenlik bildirimiyle karşılaştırın.

Juniper'ın Ekim Paketi

SecurityWeek'e göre Juniper Networks, Junos OS ve Junos OS Evolved'da 150'den fazla açığı kapatan 17 güvenlik bildirimi yayımladı; buna Juniper Cloud-Native Router'daki (JCNR) dört hata da ekleniyor. Bunlardan yaklaşık iki düzinesi kritik olarak derecelendirilmiş ve root yetkisiyle kod çalıştırma ya da cihazın tamamen ele geçirilmesi gibi sonuçlara yol açabiliyor. Juniper'ın bu açıkların sömürüldüğüne dair bir bilgisi yok.

Not: Juniper bildirimlerini tek tek açıp her CVE'yi doğrulamadım; buradaki sayılar SecurityWeek'in özetine dayanıyor. Juniper cihazı yönetenlerin kendi model ve sürümleri için Juniper Support Portal'daki bildirimleri doğrudan kontrol etmesini öneririm.



Junos sürümünü kontrol etmek için:
Kod:
show version

Yama ve Geçici Önlemler

NGINX Open Source:
  • Stable dalındaysanız 1.30.6'ya, mainline dalındaysanız 1.31.7'ye yükseltin.
  • Yükseltme sonrası yapılandırmayı test edip yeniden yükleyin:
Kod:
nginx -t && systemctl reload nginx

Hemen yükseltemiyorsanız (geçici):
  • HTTP/3 kullanıyorsanız F5'in önerdiği gibi proxy_request_buffering off değerini değerlendirin ya da HTTP/3'ü geçici olarak kapatın.
  • mTLS kullanan sunucularda ssl_session_ticket_key ile açık bir bilet anahtarı tanımlamak veya oturum biletlerini kapatmak (ssl_session_tickets off) TLS açığının tetiklenme koşulunu ortadan kaldırır. Bu öneriyi açığın tanımladığı koşuldan çıkarıyorum; uygulamadan önce F5 bildirimini kontrol edin.
  • SSI kullanmıyorsanız kapalı olduğundan emin olun.

NGINX Plus ve F5 ürünleri: The Hacker News'e göre NGINX Plus ve NGINX içeren diğer F5 ürünlerinin kullanıcıları F5 bildirimlerine bakmalı; bazı ürünler için 15 Ekim itibarıyla henüz düzeltilmiş sürüm yoktu.

Juniper: Kendi platformunuz için ilgili bildirimdeki düzeltilmiş Junos sürümüne geçin, yönetim arayüzlerine erişimi güvenilir ağlarla sınırlayın.

Sizin ortamınızda HTTP/3 veya SSI kullanan NGINX var mı? Yoksa çoğunuz sade reverse proxy olarak mı kullanıyorsunuz? Yorumlarda kontrol sonuçlarınızı paylaşabilirsiniz.

Kaynaklar
Alıntı:Yasal Uyarı: Bu konu yalnızca bilgilendirme ve savunma amaçlıdır. Paylaşılan kontrol ve tespit adımlarını yalnızca sahibi olduğunuz veya yazılı izinle yönettiğiniz sistemlerde uygulayın. İzinsiz erişim, tarama ve sistemlere müdahale, 5237 sayılı Türk Ceza Kanunu'nun 243-245. maddeleri kapsamında suçtur.

Yasal uyarı: Bu içerik eğitim amaçlıdır. Yalnızca kendi sistemlerinizde veya yazılı izin aldığınız hedeflerde uygulayın (TCK 243-245).


Ek DosyalarEkran Görüntüleri
   
Cevapla



Hızlı Menü: