Ne oldu?
Vercel, 7 Mayıs 2026’da Next.js için toplu bir güvenlik güncellemesi yayımladı: 13 açık, çoğu “yüksek” önem derecesinde. Bir kısmı React’in sunucu bileşenlerini (React Server Components, RSC) çalıştıran react-server-dom-* paketlerinde, yani bu paketleri kullanan başka framework’leri de ilgilendiriyor. Çözüm tek: Next.js 15.5.18 ya da 16.2.6’ya geçmek. 13.x ve 14.x için ayrı düzeltme yok, bu sürümlerdeysen büyük sürüm atlaman gerekiyor. Vercel, bu açıkların güvenlik duvarı (WAF) kurallarıyla güvenilir şekilde engellenemeyeceğini de söylüyor.
Better Stack videosunda her kategoriden bir açığı canlı olarak yeniden üretiyor. Biz de kategorilere bakıp her birinin dersini çıkaralım.
1. Middleware’i atlatmak
Next.js’te middleware (Next.js 16’da adı proxy oldu), her istekten önce çalışan bir kod parçası. Çoğu kişi burada “giriş yapmamışsa login sayfasına yönlendir” kontrolü yapıyor. Bu güncellemedeki dört yüksek dereceli açık, tam bu kontrolün atlatılmasıyla ilgili. Aynı sayfaya farklı bir URL biçimiyle ulaşmak yetiyordu: Sayfa önceden yüklenirken kullanılan .rsc ve segment-prefetch adresleri, dinamik route parametresini değiştiren özel sorgu parametreleri ya da çok dilli (i18n) sitelerde dil öneki olmayan veri adresi. Middleware’in eşleştirme kuralı bu varyantları yakalamıyordu, sayfa korumasız açılıyordu.
Videodaki yorum yerinde: Bu açıklar kulağa olduğundan daha kötü geliyor, çünkü Next.js zaten middleware’i tek koruma olarak kullanmanı önermiyor. Dokümantasyon, proxy’deki kontrolü “iyimser” bir ön filtre olarak görüyor. Asıl kontrol veriye en yakın yerde, bir Data Access Layer içinde yapılmalı: Sunucu bileşeninde, route handler’da ve her server action’da oturumu yeniden doğrula. Bunu yapan bir uygulamada middleware atlatılsa bile korunan veri açığa çıkmaz; Next.js’in kendi önerdiği geçici çözüm de tam olarak bu.
2. Sunucuyu kilitlemek (DoS)
En öğretici açıklardan biri React’in Flight protokolünde, yani sunucu ile tarayıcı arasında bileşen ve veri taşıyan formatta. Videoya göre, bir server action’a giden isteğe on binlerce sahte alan ve binlerce referans eklendiğinde, sunucu her referans için bütün alanları baştan tarıyordu. İş miktarı “referans sayısı çarpı alan sayısı” kadar büyüyor, tek bir istek sunucuyu saniyelerce meşgul ediyordu. Düzeltme, listeyi geri dönmeyen tek bir imleçle taramak: İş, çarpımdan toplama iniyor. Kendi protokolünü ve ayrıştırıcını (parser) yazmanın neden zor olduğunu gösteren güzel bir örnek.
3. Sunucuya iç ağa istek attırmak (SSRF)
En yüksek puanlı açık (8.6) yalnızca kendi sunucusunda Next.js çalıştıranları etkiliyor; Vercel’de barınan siteler etkilenmiyor. Özel hazırlanmış bir WebSocket “upgrade” isteğiyle Next.js sunucusu, saldırganın seçtiği bir adrese istek atıyordu. Dışarıya kapalı bir veritabanı paneli ya da bulut sağlayıcısının metadata servisi böylece erişilebilir oluyordu. Ders: Uygulama sunucunu doğrudan internete açma, kullanmıyorsan WebSocket upgrade isteklerini önündeki ters vekil sunucuda kapat, sunucunun iç ağa çıkışını kısıtla.
4. Önbellek zehirleme ve XSS
Önünde bir CDN varsa, normal HTML isteği ile RSC verisi isteği karışabiliyordu. Sona bir sorgu parametresi eklenmiş RSC isteği HTML sanılıp önbelleğe yazılıyor, sonraki ziyaretçiler sayfa yerine anlamsız veri görüyordu. XSS tarafında ise beforeInteractive stratejili bir <Script> etiketine kullanıcıdan gelen bir değer (ör. URL parametresi) verildiğinde, değer düzgün kaçışlanmadığı için sayfaya başka bir script enjekte edilebiliyordu. Ders: Kullanıcı girdisini script etiketlerine hiç koyma.
Sonra ne oldu?
Bu yoğunluk Next.js ekibini süreç değiştirmeye itti. Temmuz’da ekip, büyük dil modelleriyle yapılan güvenlik araştırmalarının açık sayısını hızla artırdığını belirterek aylık, önceden duyurulan güvenlik sürümlerine geçtiğini açıkladı; ilki 21 Temmuz’da çıktı. Acil durumlar için ara sürümler de sürüyor: 25 Ağustos’ta AVIF görsel işleme ve Windows sunucularla ilgili iki kritik uzaktan kod çalıştırma açığı 15.5.24 ve 16.3.3 ile kapatıldı. 14 Ekim için de iki kritik, bir yüksek dereceli açığı kapatacak yeni bir güncelleme duyuruldu. Yani Next.js kullanıyorsan güncellemeyi ayda bir yapılan bir rutin olarak planlamak artık şart.
Düşün
- Uygulamanda bir sayfayı koruyan tek şey middleware/proxy mi, yoksa veriyi getiren kod da oturumu kontrol ediyor mu?
- Next.js sunucun, iç ağdaki hangi servislere ulaşabiliyor? Ulaşması gerekiyor mu?
Videoyu izle
Kaynaklar (10, İngilizce)
- Better Stack: Yeah it's over for NextJS... 13 NEW vulnerabilities (video) (yeni sekmede açılır)
- Vercel: Next.js May 2026 security release (yeni sekmede açılır)
- GitHub: GHSA-267c-6grr-h53f (segment-prefetch ile yetki atlatma) (yeni sekmede açılır)
- GitHub: GHSA-492v-c6pp-mqqv (dinamik route parametresiyle atlatma) (yeni sekmede açılır)
- GitHub: GHSA-c4j6-fc7j-m34r (WebSocket upgrade ile SSRF) (yeni sekmede açılır)
- Next.js Docs: Authentication (Data Access Layer) (yeni sekmede açılır)
- Next.js Docs: proxy.js (middleware'in yeni adı) (yeni sekmede açılır)
- Next.js Blog: Next.js Security Release and Our Next Patch Release (yeni sekmede açılır)
- Next.js Blog: August 2026 Security Release (yeni sekmede açılır)
- Next.js Blog: Upcoming security update, October 2026 (yeni sekmede açılır)
Kendi cümlelerimizle yazılmış bir özettir, çeviri değildir. Tüm kaynaklar yukarıda.