Blog'a Dön

Next.js Güvenlik Yamaları Artık Takvimle Geliyor: İlk Sürüm Neleri Düzeltiyor

Next.js 16.2.11 ve 15.5.21, ilk planlı güvenlik sürümünde dört yüksek ve beş orta seviye CVE'yi kapatıyor. Bunları nasıl önceliklendirirdim ve aşağı yukarı aylık bu takvime göre nasıl plan yapardım, anlatıyorum.

Umut Korkmaz

Yayın tarihi: 4 dk okuma

Next.js bugün ilk planlı güvenlik sürümünü yayınladı. Kapsanan iki sürüm hattı için çıkan yama sürümleri, 16.2.11 (Active LTS) ve 15.5.21 (Maintenance LTS), dört yüksek ve beş orta seviyeli güvenlik açığını düzeltiyor. Ayrıntılar July 2026 Security Release yazısında. Düzeltmeler önemli ama bence süreçteki değişiklik daha önemli. Şimdiye kadar Next.js güvenlik yamaları önceden haber verilmeden geliyordu. Artık çoğu, ekiplerin plan yapabileceği bir takvimle gelecek.

Sürpriz yamalardan takvime

Next.js ekibi programı 13 Temmuz'da duyurdu. Next.js blogu yaklaşık ayda bir, yaklaşan güvenlik sürümü için önceden duyuru yayınlayacak; duyuruda beklenen zaman çizelgesi ve kapsanan en yüksek önem derecesi yer alacak. Acil bildirimler ve sahada aktif olarak istismar edilen açıklar ise yine plansız yamalarla kapatılacak. Ekip iki gerekçe sunuyor: eski plansız yamalar hiçbir uyarı olmadan gelip kullanıcıları zor durumda bırakıyordu, ayrıca LLM destekli keşif sayesinde güvenlik açığı araştırmalarının hacmi hızla artıyor. Ekip bu yöntemi Next.js üzerinde kendisi de kullanıyor.

İlk sürüm 20 Temmuz'a planlanmıştı, sonra 21 Temmuz'a kaydı. npm registry'ye göre 15.5.21 ve 16.2.11 21 Temmuz'da yayınlandı, aynı gün ardından 16.3.0-canary.92 ve 16.3.0-preview.7 geldi. Bir günlük kayma sorun değil, ama güncelleme pencerenizde biraz pay bırakın.

Neler düzeltildi

Dört yüksek seviyeli açık:

  • CVE-2026-64641: En az bir Server Action içeren bir App Router uygulamasına özel hazırlanmış istekler, aynı süreçteki diğer istekleri bloklayan aşırı CPU kullanımına yol açabiliyor; yani bir denial of service.
  • CVE-2026-64642: Turbopack ile derlenen ve config.i18n.locales içinde tek bir girdi bulunan App Router uygulamalarında middleware/proxy atlatılabiliyor.
  • CVE-2026-64645: Harici hedef hostname'ini istekten gelen, kullanıcı kontrolündeki girdiden oluşturan bir rewrites() veya redirects() kuralı, kuralın beklediği hostname soneki ne olursa olsun herhangi bir host'a yönlendirilebiliyor. Rewrite'lar SSRF'e, redirect'ler ise open redirect'e dönüşüyor.
  • CVE-2026-64649: Custom server'larda, bir isteği ileten ya da yönlendiren bir Server Action, saldırgan Host ile ilişkili header'ları kontrol ediyorsa kötü niyetli bir host'a yönlendirilebiliyor.

Beş orta seviyeli açık şunlar: kötü niyetli SVG'ler yüzünden /_next/image içinde CPU tükenmesi, Edge runtime'da boyut sınırı olmayan Server Action payload'ları, Server Action ve use cache endpoint ID'lerinin ifşası ve iki fetch cache karışıklığı hatası. Bu son ikisinde, body içeren bir sunucu tarafı fetch, aynı URL'e farklı bir body ile gönderilmiş isteğin cache'lenmiş yanıtını alabiliyor. Biri fetch(new Request(init), aDifferentInit) biçimini gerektiriyor, diğeri ise geçersiz UTF-8 içeren bir body.

Middleware tek kimlik doğrulama katmanınız olmamalı

CVE-2026-64642 bildirimi açık konuşuyor: middleware/proxy'nizin yaptığı tüm kimlik doğrulama veya güvenlik kontrolleri atlatılıyor. Etkilenen yapılandırma dar, ama çıkarılacak ders öyle değil.

Middleware; redirect'ler, kaba erişim kontrolü ve header'lar için işe yarayan bir ilk filtre. Anonim bir istekle verileriniz arasındaki tek engel olmamalı. Her Server Action, Route Handler ve sunucu tarafı veri erişim fonksiyonu, oturumu ve yetkilendirmeyi kendi başına kontrol etmeli. Uygulamanız zaten böyle çalışıyorsa bu CVE bir auth bypass olmaktan çıkıp routing'le ilgili ufak bir sıkıntıya dönüşür. Böyle çalışmıyorsa, bu bug'dan çok daha uzun ömürlü bir tasarım sorununuz var demektir.

Deploy şeklinize göre önceliklendirin

Her CVE her uygulamayı etkilemiyor, bu yüzden ben deploy şekline göre sıralıyorum:

  • Server Action kullanan her App Router uygulaması CPU kaynaklı denial of service açığının kapsamında. Yamayı geçin.
  • Varsayılan image loader'ı kullanan ve remote image'ları yapılandırılmış self-hosted uygulamalar SVG açığının kapsamında. Remote optimizasyon varsayılan olarak kapalı, o yüzden images config'inize bakın.
  • Custom server'lar: Server Action SSRF açığı custom server'lar için geçerli ve saldırganın Host ile ilişkili header'ları kontrol edebilmesini gerektiriyor. Bundan ayrı olarak, benim bir VPS üzerinde yaptığım gibi nginx arkasında self-host ediyorsanız, proxy'nizin istemciden gelen Host veya X-Forwarded-Host değerlerini olduğu gibi geçirip geçirmediğini kontrol edin.
  • Dinamik hostname içeren rewrite'lar: next.config içinde harici hedef hostname'i istek girdisinden gelen kuralları arayın.

Hızlı bir ilk tarama:

npm ls next
grep -nE "rewrites|redirects|i18n|remotePatterns" next.config.*

Takvimi işe yarar hale getirmek

Bir takvim, ancak ekip onu gerçekten takvim gibi kullanırsa işe yarar. Bu hafta kuracağım düzen şu:

  • Next.js blogunu takip edin ve her duyuruyu sahibi ve tarihi olan bir ticket'a çevirin.
  • Yamalanan bir sürüm hattında kalın. Bu sürüm 16.2 ve 15.5 için, ayrıca 16.3 canary ve preview için yama içeriyor. Başka bir hattaysanız, önce bunlardan birine geçmek gerekiyor.
  • Güncellemeleri sıkıcı tutun. Bir Server Action'ı, korumalı bir route'u, bir image route'unu ve varsa rewrite'ları kapsayan kısa bir smoke test, yamanın sıradan bir deploy olarak çıkmasını sağlar.
  • Self-hosting'in size neye mal olduğunu unutmayın. Next.js ekibi, bu ön sürenin, yamalanmamış uygulamalar için firewall kuralları gibi önlemler konusunda hosting sağlayıcıları ve platform partnerleriyle koordinasyon kurmasına imkan verdiğini söylüyor. Kendi VPS'inizde bunları sizin için deploy eden kimse yok; o yüzden önceden gelen duyuru sizin avantajınız.

Benim görüşüm

Bu doğru bir adım. Sürpriz yamalar ekipleri her şeyi bırakmakla riski taşımak arasında seçim yapmaya zorluyor; aşağı yukarı aylık bir zaman dilimi ise güvenlik yamalarını planlı bir işe dönüştürüyor. Makine destekli araştırmanın artması daha fazla bulgu demek, bu yüzden bu sürümlerin boş değil dolu geleceğini düşünüyorum. Şu sıralar CEH materyalleri üzerinde çalışıyorum; SSRF ve istemci kontrolündeki Host header'larına güvenmek ders kitabı niteliğinde web hataları. İkisini tek bir framework sürümünde görmek, her projede proxy ve header işleyişini kontrol etmek için iyi bir hatırlatma.

Kaynaklar

Bu yazıda yararlanılan birincil kaynaklar.

  1. nextjs.org/blog/july-2026-security-release (yeni sekmede açılır)
  2. nextjs.org/blog/next-security-release-program (yeni sekmede açılır)
  3. registry.npmjs.org/next (yeni sekmede açılır)

Yazar hakkında

Umut Korkmaz

Lead Yazılım Mühendisi

İstanbul'da kıdemli yazılım mühendisi olarak çalışıyorum. Burada, bizzat canlıya aldığım araçları ve sürümleri, sahada öğrendiklerimle birlikte yazıyorum.

Ortak konulara göre seçildi.

  • 4 dk okuma

    Next.js 16.3: Ücretsiz Gelenler ve Taşıma Gerektirenler

    Next.js 16.3'ün getirdikleri ikiye ayrılıyor: sadece sürümü yükselterek elde ettiğiniz kazanımlar ve isteğe bağlı Instant Navigations geçişi. İkisini nasıl planlardım, yeni AGENTS.md bloğu ekipler için ne anlama geliyor, bu yazıda anlatıyorum.

    • Next.js
    • React
    • Performans
  • 7 dk okuma

    Expo Updates'i Kendi Sunucunda Barındırmak: SaaS Olmadan OTA

    Eşlik Et için barındırılan bir servis yerine kendi Expo Updates sunucumu çalıştırıyorum. Havadan güncellemelerin nasıl çalıştığı, denetim ve bağımlılık riski için neden kendi sunucumda barındırdığım, imzalama ve dağıtımların yükü ve barındırılanın ne zaman daha akıllı seçim olduğu.

    • Expo
    • React Native
    • OTA