NGINX 1.30.6 ve 1.31.7: kontrol edilecek 5 CVE

Ne oldu?

NGINX, beş açığı düzelten 1.30.6 (stable) ve 1.31.7 (mainline) sürümlerini yayınladı. nginx.org advisory’leri beşini de medium olarak derecelendiriyor, çünkü her biri belirli bir özellik ya da config gerektiriyor. Bazı vendor’lar bunların bir kısmını daha yüksek puanlıyor. Ne kadar acil olduğuna karar vermeden önce kullandığınız ürünün advisory’sini okuyun.

CVE	Ne olduğu	Gereken özellik	Etkilenen sürümler
CVE-2026-15176	Buffer overflow	alias ile rewrite birlikte	0.1.29 ile 1.31.6 arası
CVE-2026-93479	Script evaluation’da buffer overflow	Config’te script evaluation	1.31.2 ile 1.31.6 ve 1.30.0 ile 1.30.5 arası
CVE-2026-95101	Request body injection	HTTP/3	1.25.0 ile 1.31.6 arası
CVE-2026-97629	Session forgery	TLS session ticket	1.23.2 ile 1.31.6 arası
CVE-2026-97205	Use after free	Asenkron dosya I/O (aio)	0.8.11 ile 1.31.6 arası

Kaynaklar her sürüm aralığında tam uyuşmuyor. Fleet’iniz hakkında rapor vermeden önce kesin rakamlar için nginx.org sayfasına bakın.

Etkilenip etkilenmediğinizi öğrenin

İki soru önemli: hangi NGINX sürümü nerede çalışıyor ve config etkilenen özelliği kullanıyor mu?

# Host üzerindeki sürüm
nginx -v

# Bir image içindeki sürüm
docker run --rm your-image:tag nginx -v

# Yüklü config'teki özellikler
nginx -T 2>/dev/null | grep -nE '^\s*(alias|aio|ssl_session_tickets|http3|listen .*quic)'

Grep hiçbir şey bulmazsa riskiniz daha düşüktür ama yine de upgrade edin. Sürüm kontrolü ucuz, config ise zamanla kayar.

Ne yapmalı?

1. 1.30.6 veya 1.31.7 ve üstüne upgrade edin. NGINX içeren her container image’ını yeniden build edip deploy edin. Registry’de yeni bir tag olması, pod’lar restart edilene kadar bir şey değiştirmez.
2. Bugün upgrade edemiyorsanız, servisiniz izin veriyorsa CVE’nin gerektirdiği özelliği kapatın. Örneğin HTTP/3 veya aio. Önce advisory’yi okuyun ve değişikliği staging’de deneyin.
3. Reload edin ve doğrulayın. Upgrade sonrası çalışan container’da ya da host’ta tekrar nginx -v çalıştırın. Upgrade edilmiş görünen bir sistem, process restart edilene kadar eski binary’yi çalıştırmaya devam eder.

Kubernetes ingress için ayrı bir kontrol gerekir

NGINX sürümünü her zaman siz seçmezsiniz. Ingress controller’lar kendi build’lerini getirir.

kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx

• Community ingress-nginx: Kubernetes SIG Network ve Security Response Committee, projenin emekliye ayrılacağını Kasım 2025’te duyurdu. Kesin takvim için duyuruyu okuyun. Emekli bir proje bu sürüm için size patch vermez. Gateway API’ye ya da desteklenen bir controller’a geçişi planlayın.
• F5 NGINX Ingress Controller ve diğer ürünler: Düzeltilmiş build için vendor advisory’sine bakın. Bazı ürünler sadece daha yeni bir NGINX değil, kendi yamalı sürümlerini gerektirir.
• Managed gateway’ler ve CDN’ler: Sağlayıcınıza patch’i yapıp yapmadığını ve ne zaman yaptığını sorun.

Nasıl yardımcı olabiliriz?

Bir ortamdaki tüm NGINX’leri, image’ların ve ingress controller’ların içindekiler dahil, envantere çıkarırız ve emekli controller’lardan geçişi planlarız. Aşağıdaki butondan bir görüşme ayarlayın.