Next.js Güvenlik Krizi: 13 Yeni CVE Bize Ne Anlatıyor?
Next.js için 2026 Mayıs güvenlik duyuruları, sıradan bir "paketleri güncelleyin" notundan daha fazlası. Vercel'in GitHub advisory sayfalarında aynı hafta içinde yayımlanan açıklar, React Server Components, App Router, Pages Router, middleware/proxy, WebSocket upgrade akışı, cache anahtarlama ve beforeInteractive script işleme gibi framework'ün en kritik katmanlarına dokunuyor.
Konuya "Next.js yine hacklendi" diye bakmak kolay. Ama daha faydalı soru şu: Bu açıklar bize modern full-stack frontend framework'lerinin hangi noktalarda kırılganlaştığını gösteriyor? Çünkü burada tek bir hatalı if koşulundan değil, çok katmanlı bir mimarinin güvenlik sınırlarını yönetme zorluğundan söz ediyoruz.
13 CVE'nin Ortak Hikayesi
Yeni duyuruların en dikkat çekici tarafı çeşitlilik. Açıkların bir kısmı doğrudan Next.js'in routing ve proxy davranışından kaynaklanıyor. Bir kısmı React Server Components ve React Flight Protocol gibi daha derin React altyapısına bağlı. Bir kısmı ise CDN, reverse proxy ve paylaşımlı cache gibi dağıtım ortamlarında ortaya çıkan yorum farklarını hedefliyor.
Vercel advisory listesinde yüksek önem dereceli başlıklar arasında Pages Router + i18n kullanılan yapılarda middleware/proxy bypass, App Router tarafında segment-prefetch rotalarıyla ilgili bypass senaryoları, dinamik route parametre enjeksiyonu, Cache Components kullanan uygulamalarda connection exhaustion ve WebSocket upgrade üzerinden SSRF yer alıyor. Bunlara ek olarak RSC cache poisoning, _rsc cache-busting çakışmaları, Image Optimization API DoS ve beforeInteractive script'lerinde XSS gibi orta ve düşük seviye ama pratikte can sıkabilecek açıklar var.
Altı açığın yüksek önem derecesinde olması önemli. Çünkü bu seviye, sadece teorik bir bug değil, belirli konfigürasyonlarda veri sızıntısı, yetki atlatma veya servis kesintisi gibi somut sonuçlar doğurabilecek bir risk anlamına geliyor.
Middleware Bypass: Güvenliği Kenara Taşımak
En öğretici örneklerden biri, Pages Router kullanan ve i18n yapılandırması bulunan uygulamalardaki middleware/proxy bypass açığı. CVE-2026-44573 olarak izlenen bu açıkta problem, locale içermeyen /_next/data/ isteklerinin beklenen middleware kontrolünden geçmeden korumalı sayfanın SSR JSON verisine ulaşabilmesi.
Bu bize eski bir dersi yeniden hatırlatıyor: Yetkilendirmeyi yalnızca yol eşleşmesine veya middleware katmanına bırakmak riskli. Middleware, kullanıcıyı doğru sayfaya yönlendirmek için mükemmel bir yer olabilir; fakat asıl veri üretim yolunda da yetki kontrolü yoksa, framework'ün alternatif veri rotaları beklenmedik bir arka kapıya dönüşebilir.
Benzer mantık dinamik route parametre enjeksiyonu açığında da görülüyor. Saldırganın özel hazırlanmış query parametreleriyle sayfanın gördüğü dinamik değeri değiştirebilmesi, görünür path aynı kalsa bile yanlış içeriğin render edilmesine yol açabiliyor. Bu tür açıklar, "URL böyle görünüyorsa güvenlidir" varsayımının artık çok zayıf kaldığını gösteriyor.
React Flight ve DoS Riski
React Server Components tarafındaki en ağır başlıklardan biri CVE-2026-23870. Bu açık, React Flight Protocol deserialization sürecinde özel hazırlanmış HTTP isteklerinin aşırı CPU tüketimine yol açabilmesiyle ilgili. GitHub advisory'si, App Router Server Function endpoint'lerine gönderilen payload'ların unpatched ortamlarda denial-of-service üretebildiğini belirtiyor.
Burada mesele yalnızca "kötü bir request sunucuyu yordu" değil. React Flight, server component ağacını istemciye aktarmak için özel bir serileştirme/deserileştirme modeli kullanıyor. Bu model performans ve geliştirici deneyimi için güçlü, ama aynı zamanda saldırganın hedef alabileceği yeni bir protokol yüzeyi oluşturuyor. Deserialization katmanında doğrulama, derinlik limiti, kaynak kullanımı kontrolü ve beklenmeyen referans yapılarını engelleme gibi savunmalar eksik kaldığında, küçük bir istek büyük bir CPU maliyetine dönüşebiliyor.
React ekibi 2025 sonunda RSC tarafında RCE, DoS ve source code exposure açıkları yayımladığında da benzer bir tablo görmüştük. Bu yeni dalga, RSC'nin güvenlik modelinin hâlâ olgunlaşma sürecinde olduğunu düşündürüyor.
WebSocket Upgrade ile SSRF
CVE-2026-44578 ise self-hosted Next.js uygulamaları için ayrıca önemli. Açık, built-in Node.js server kullanan uygulamalarda özel hazırlanmış WebSocket upgrade isteklerinin sunucuyu keyfi iç veya dış hedeflere proxy yapmaya zorlayabilmesiyle ilgili. Vercel-hosted deployment'ların etkilenmediği belirtiliyor; fakat kendi origin sunucusunu doğrudan internete açan ekipler için SSRF riski ciddi.
SSRF'nin tehlikesi, saldırganın sadece sizin uygulamanıza değil, uygulamanızın erişebildiği iç ağa da dolaylı erişim kazanabilmesidir. Cloud metadata endpoint'leri, internal admin servisleri veya sadece private network'te olduğu için güvenli kabul edilen API'ler bu senaryoda hedef olabilir.
Fix tarafında Next.js, normal HTTP request'leri için var olan güvenlik kontrollerini WebSocket upgrade handling akışına da uyguluyor. Bu da güzel bir ders: Bir framework'te "aynı routing davranışı" gibi görünen iki kanal, güvenlik açısından aynı kontrollerden geçmiyorsa ayrışma başlar.
Cache Poisoning ve _rsc Meselesi
RSC cache poisoning açıkları daha sessiz görünebilir ama büyük trafikli siteler için tatsızdır. CVE-2026-44576, paylaşımlı cache'lerin response varyantlarını doğru ayırmadığı koşullarda RSC payload'ının normal URL üzerinden cache'e zehirli bir varyant olarak yerleşebilmesini anlatıyor. Sonuçta sonraki ziyaretçiler beklenen HTML yerine component payload'ı alabilir.
Bir başka advisory, _rsc cache-busting değerindeki çakışmaların yanlış response varyantlarını aynı cache girişinde buluşturabileceğini söylüyor. Bu açık düşük önem seviyesinde listelenmiş olsa da, CDN davranışı ve Vary header'ları yanlış yönetilen sistemlerde debug edilmesi zor bozulmalara yol açabilir.
Bu bölümün pratik sonucu net: RSC kullanan uygulamalarda CDN ve reverse proxy konfigürasyonunu "statik HTML cache'liyorum" basitliğinde düşünmek artık yeterli değil. RSC header'ları, cache key ayrımı ve response varyantları bilinçli tasarlanmalı.
beforeInteractive XSS: Küçük API, Büyük Etki
CVE-2026-44580, beforeInteractive script'lerine güvenilmeyen veri verilen uygulamalarda XSS riskini gündeme getiriyor. Etkilenen sürümlerde serialize edilen script içeriği sayfaya gömülmeden önce yeterince güvenli escape edilmediği için saldırgan kontrollü içerik inline script sınırından çıkabiliyor.
Bu açık orta seviye olarak listelenmiş, çünkü genellikle uygulamanın zaten untrusted veriyi bu alana taşıması gerekiyor. Yine de mesaj açık: Script stratejileri performans optimizasyonu gibi görünse de, veri sınırı yanlış çizildiğinde doğrudan tarayıcıda kod çalıştırma riskine dönüşebilir.
Geliştiriciler Ne Yapmalı?
En kısa cevap: Next.js'i yamalı hatlara yükseltin. Mayıs 2026 advisory'lerinde birçok açık için patch sürümleri 15.5.16 ve 16.2.5 olarak belirtiliyor. React Server Components kullanan projelerde React ve react-server-dom-* paketlerinin de güncel olduğundan emin olun.
Ama sadece upgrade yetmez. Authorization kontrolünü middleware dışına da taşıyın. Server-side data path, route handler, server action ve API katmanlarında gerçek yetki kontrolü olsun. Self-hosted çalışıyorsanız origin sunucunuzu doğrudan internete açmayın; WebSocket upgrade gerekmiyorsa proxy seviyesinde kapatın. CDN tarafında RSC ile ilgili Vary ve cache key davranışlarını test edin. beforeInteractive içine kullanıcıdan gelen ham veri koymayın.
Next.js'ten Uzaklaşmak Mantıklı mı?
Bazı geliştiricilerin TanStack, Astro veya daha sade server/client ayrımına sahip araçlara yönelmesi anlaşılır. Next.js, özellikle App Router ve RSC ile birlikte artık sadece "React için routing framework'ü" değil; custom protocol, server runtime, cache sistemi, streaming, partial rendering ve deployment varsayımları olan büyük bir platform.
Bu güç, aynı zamanda daha büyük saldırı yüzeyi demek. Ancak tabloyu adil okumak gerekir: Çok kullanılan projeler daha fazla incelenir, daha fazla CVE üretir ve daha hızlı yama döngüsüne girer. Sorun CVE yayımlanması değil; ekiplerin bu karmaşıklığı anlayıp anlayamadığı, framework'ün güvenlik varsayımlarını dokümante edip edemediği ve üretim ortamlarının bu varsayımlara uyup uymadığıdır.
Benim çıkarımım şu: Next.js hâlâ güçlü bir araç, fakat artık "kur, deploy et, unut" aracı değil. RSC, middleware, cache ve self-hosting kullanan ekiplerin güvenlik modelini açıkça sahiplenmesi gerekiyor. Daha basit bir stack seçmek bazen en doğru güvenlik kararı olabilir. Ama Next.js kullanmaya devam edilecekse, dependency update'i bir angarya değil, mimarinin parçası olarak görülmeli.
Kaynaklar: Vercel/Next.js GitHub security advisories, React security blog duyuruları, Cloudflare ve Netlify'in Mayıs 2026 React/Next.js güvenlik notları.
