NGINX 1.31.7 ve 1.30.6, yalnızca belirli directive'ler etkinleştirildiğinde önem taşıyan beş CVE'yi düzeltiyor

Beş düzeltme, beş ön koşul

NGINX 1.31.7 ve 1.30.6 beş güvenlik kusurunu kapatıyor ve bunların her biri koşullu: hata yalnızca belirli bir yapılandırma ögesi devredeyken önem taşıyor. Bu, dev.to'da yayımlanan bir analizin temel gözlemi; analiz, sürüm odaklı bir güvenlik duyurusunu yapılandırma odaklı bir açık değerlendirmesine nasıl dönüştüreceğini adım adım anlatıyor.

Beş tanımlayıcı şunlar: CVE-2026-15176, CVE-2026-93479, CVE-2026-97205, CVE-2026-95101 ve CVE-2026-97629; bunlar, analizin 14 Ekim 2026 tarihli bir F5 NGINX güvenlik duyurusuna bağladığı sürümlerde giderildi. Analizin adını verdiği koşullar şöyle: $request_filename ile birlikte kullanılan alias, map blokları içindeki isimlendirilmemiş capture'lar, ssi ile birlikte aio, session ticket anahtar işleme ve — CVE-2026-95101 için — HTTP/3 istek ayrıştırma. Session ticket kusurunun tanımlayıcısı CVE-2026-97629. Bu yapılandırma ögelerinin hiçbiri sıra dışı değil ama hiçbiri evrensel de değil; bir sunucunun açıkta olup olmadığını tek başına sürüm numarası çok az şey söylüyor.

Bir tarama bunu çözemez

Yazar, açıkta kalan popülasyonu ölçeklendirmeyi ZoomEye ile denedi, ancak API araştırma süresi boyunca HTTP 502 hataları döndürdü; bu yüzden makale herhangi bir sayı olmadan yayımlandı. Bu başarısızlık, yazının asıl vurguladığı noktanın yanında neredeyse önemsiz kalıyor: internet genelindeki taramalar directive'leri hiç göremez.

Yaygın iki sorgu farklı makine gruplarını tanımlıyor. app="nginx" eşleşmesi, motorun parmak izini NGINX olarak belirlediği varlıkları döndürürken, Server yanıt başlığı üzerinden eşleşme, varsayılan banner'ı olduğu gibi bırakan her kurulumu yakalıyor; bu, NGINX'i belli etmeden gömen cihazları da içeriyor. Her yaklaşım bir yönüyle diğerinden daha kapsamlı ve ikisi de alias, rewrite, $request_filename, ssi, aio veya ssl_session_cache kullanımının raporlamıyor. NGINX varlıklarının bir dökümü, ne kadar büyük olursa olsun, beş kusurdan herhangi birine açıkta kalma dökümü değildir.

Gerçekten işe yarayan kontrol

Analize göre sorunu kesin olarak çözmenin tek güvenilir yolu, her varlık üzerinde, onu yöneten ekibin içinden nginx -T çalıştırmaktır; çünkü bu komut birleştirilmiş yapılandırmayı yazdırır. Önerilen iş akışı, tarama çıktısını bir bulgu olarak değil, bir talebe girdi olarak ele alıyor: internete açık NGINX host'larının bir aday listesini bir taramadan ya da iç envanterden oluştur, her host'u sahibi ekibe eşleştir ve o ekibe alias ile $request_filename, isimlendirilmemiş map capture'ları, ssi ile aio, session ticket anahtar işleme ve QUIC'in sonlandırılıp sonlandırılmadığı konusunda birkaç hedefli soru sor.

Tarama eksiksizlik sayesinde yerini hâlâ koruyor. İç envanterler proje ekiplerinin kurup hiç kaydetmediği sunucuları çoğu zaman gözden kaçırıyor ve yapılandırması en az gözden geçirilmiş makinelere de tam olarak bunlar.

Rol, riski şekillendirir

Statik dosyalar sunan bir NGINX instance'ı, bir kimlik doğrulama sınırının önünde TLS sonlandıran instance'dan farklı bir önermedir ve session ticket kusuru ikinci rolde en çok önem taşır. Analizi onları ayırt etmek için sinyaller sunuyor: iç servis adlarına düzenlenmiş sertifikalar zincirdeki bir bileşene işaret ederken, varsayılan karşılama sayfası genellikle ya taze bir kurulumu ya da unutulmuş bir test ortamını gösterir —后者 ikincisi, internet genelindeki verilerde tekrar eden bir kategoridir, çoğu zaman tamamen açık ve izlenmeyen, ve varsayılan banner'ı koruyan host'lar arasında rastlantısal beklentiden daha yüksek oranda temsil edilir.

Analiz ayrıca raporlama için temel kurallar koyuyor: tam sorguyu, eşleştirilen alanı, koleksiyon tarihini ve sayılan birimleri adlandır; gözlemi ("bu host'lar bir NGINX başlığı döndürdü") çıkarımdan ("bu host'lar etkilenen bir sürüm çalıştırıyor olabilir") ayrı tut, çünkü bir banner nadiren sürüm kanıtı taşır; ve NGINX kurulu tabanının salt büyüklüğünü bir ciddiyet argümanı olarak kullanmaktan kaçın, çünkü o sayı herhangi bir tekil duyurudan önce vardı ve ondan sonra da var olmayı sürdürecek.

Neden önemli

Koşullu CVE'ler, yapılandırmalarını bilen operatörleri ödüllendirir. Beş kusurun da belirli bir directive ya da protokolün etkin olmasını gerektirmesi sayesinde, açıkta kalma durumu kör bir filo geneli acil yükseltme yerine bir yapılandırma incelemesiyle tespit edilebilir — ya da dışlanabilir. NGINX'i uçta çalıştıran herkes için pratik yol, düzeltilmiş sürümlere geçmek; ama işi önce adı geçen yapılandırma ögelerinin varlığını kontrol ederek sıralamak; özellikle TLS ve QUIC sonlandıran ön uçlara ve internet taramalarının yeniden yeniden keşfettiği kayıtsız test sunucularına dikkat etmek.