React ve Next.js'te uzaktan kod çalıştırma (RCE) zafiyeti

 (github.com/vercel)
8 puan yazan GN⁺ 2025-12-04 | 1 yorum | WhatsApp'ta paylaş
  • React ve Next.js için uzaktan kod çalıştırma (RCE) olasılığı olan bir güvenlik zafiyeti rapor edildi
  • Bu sorun Next.js paketi içinde meydana geliyor ve saldırganın kötü niyetli girdiler yoluyla istediği kodun yürütülmesini tetikleyebilmesine imkan tanıyor
  • Vercel, GitHub güvenlik tavsiyesi (GHSA-9qr9-h5gf-34mp) aracılığıyla bu zafiyeti kamuya açıkladı ve bir güncelleme sürümü yayımladı
  • Kullanıcıların zafiyeti azaltmak için en son sürüme yükseltmeleri gerekir
  • Bu örnek, çerçeve seviyesinde güvenlik yönetiminin önemini bir kez daha öne çıkarıyor

RCE zafiyeti özeti

  • Next.js ve React ortamlarında uzaktan kod çalıştırma (RCE) olasılığı olan bir zafiyet bulundu
    • Saldırganın sunucu tarafında keyfi JavaScript kodu çalıştırabilmesi riski var
  • Bu zafiyet, Next.js paketi içindeki kod işleme sürecinde ortaya çıkıyor
    • Belirli zayıf fonksiyon veya modülle ilgili teknik detaylar açıklanmadı
    Reklam

Etki ve yanıt

  • Vercel, GitHub güvenlik tavsiyesi (GHSA-9qr9-h5gf-34mp) ile konuyu resmi olarak duyurdu
    • Bu tavsiye, Next.js deposunun güvenlik duyuruları bölümüne eklendi
  • Zafiyet içeren sürümler belirtilmedi ancak güncelleme sürümü yayımlandı
    • Kullanıcılara en son stabil sürüme yükseltme önerildi
Reklam

Güvenlik tavsiyesi ve önlemler

  • Next.js paketi kullanan tüm projeler sürümlerini hemen kontrol etmeli
    • package.json içindeki Next.js sürümünü en güncel tutmak gerekir
  • Vercel, yamalı sürümü dağıtmanın dışında ek bir risk azaltma adımından bahsetmedi
  • Zafiyetin teknik ayrıntıları açıklanmamış durumda olduğu için güvenlik nedeniyle yalnızca sınırlı bilgi paylaşıldı

Önemi

  • Bu zafiyet, sunucu taraflı render ortamlarında kod çalıştırma riskini ortaya koyuyor
  • React ve Next.js tabanlı hizmetleri işletenler düzenli olarak güvenlik güncellemelerini uygulamalı
  • Çerçeve seviyesindeki güvenlik zafiyetleri, tüm uygulama güvenliğine doğrudan etki edebilir

İlgili okumalar

1 yorum

 
GN⁺ 2025-12-04
Hacker News görüşü

  • Bu açık, RSC/server actions tanıtıldığından beri uyarısı yapılan en kötü senaryonun gerçeğe dönüşmüş bir örneği
    Sunucu, istemcinin güvenilmeyen girdisini olduğu gibi deserialize edip modülü ve export adını bulup çalıştırmış
    hasOwnProperty yamasıyla engellenebilir ama asıl sorun, React’in bir RPC katmanı oluşturduğu gerçeğinin net biçimde fark edilmemiş olması
    gRPC veya SOAP gibi geleneksel RPC framework’leri açık şema ve servis tanımlarıyla sınırları belirginleştirirken, React bundler’ın görebildiği tüm API’leri açığa çıkarma biçimiyle riskli
    Bu tasarımın doğurduğu güvenlik sorunlarının ileride de tekrarlanma olasılığı yüksek

    • Bu daha çok basit bir dikkatsizlik sorunu gibi görünüyor
      Açık bir şema olsa bile, son aşamada güvenilmeyen girdinin sunucu namespace’inde herhangi bir nesneyi referans almasına izin verilirse bunun pek anlamı kalmaz
    • Aslında istemcinin talep ettiği tüm endpoint’ler açığa çıkmıyor
      Yalnızca "use server" ile işaretlenmiş fonksiyonlar açılıyor ve React ekibi de bir RPC sistemi tasarladıklarının farkında
      Bu tür bug’lar başka RPC sistemlerinde de rahatlıkla ortaya çıkabilir (React katkıcısıyım)
    • Uyarı alınmış olmasına rağmen bunun yaşanmış olması, sonuçta ancak özensiz bir implementasyon olarak görülebilir
    • Sıradan kullanıcı açısından, bu yaklaşım kullanılmazsa güvende olunup olunmadığı merak konusu
      Ama eski bir özel repo’yu sürdürmek de iyi bir seçenek değil

  • Next’in tek gerçek avantajı statik build
    O desteğin sonlanması durumunda artık kullanmak için bir neden kalmaz

  • Facebook/Meta’nın güvenlik duyurusuna göre, React Server Components 19.0.0~19.2.0 sürümlerinde kimlik doğrulama öncesi uzaktan kod çalıştırma (RCE) açığı bulunuyor
    React resmî blogundaki duyuru da, istemcinin sunucu fonksiyonlarını çağırabildiği yapı nedeniyle saldırganların kötü niyetli HTTP istekleri oluşturarak sunucuda keyfi kod çalıştırabildiğini açıklıyor

    • Düzeltme hasOwnProperty kontrolü eklemekten ibaretse, saldırı muhtemelen prototype chain özelliklerini (__proto__ vb.) referans alma yoluyla yapılıyordu
    • “İstemci sunucu fonksiyonlarını çağırabilir” ifadesi amaçlanan bir özellikse, bu oldukça ürkütücü bir tasarım gibi hissettiriyor

  • Düzeltme commit’i bu commit gibi görünüyor
    Birden fazla değişiklikle birlikte squash edildiği için ayrıntılar örtülmüş gibi
    Kodda açığa çıkan fonksiyon listesini whitelist yaklaşımıyla sınırlayan bir desen 4 yerde görünüyor

    • Ya da neden bu commit olabilir (“kritik güvenlik açığı düzeltmesi” açıkça belirtilmiş)

  • Vercel zaten platform düzeyinde koruma ile kötü niyetli istek kalıplarını engelliyor
    Duyuruya bakılabilir
    Cloudflare da WAF kuralı ile proaktif önlem aldı

    • Birden fazla iş ortağıyla birlikte önceden hafifletici önlemler dağıtıldı
      Buna rağmen Next, React ve diğer meta-framework bağımlılıklarının derhal güncellenmesi güçlü biçimde tavsiye ediliyor
    • Netlify’ın yanıt duyurusu ile
      Deno Deploy/Subhosting’in blog yazısı da bakmaya değer
    • Ben doğrudan patch uygulayıp yeniden build aldım; olası bir eksikliği karşılamak için Crowdsec WAF kuralı da ekledim

  • Açığı yeniden üretmek için PoC deposuna baktım

    • Patch uygulanmış react-server-dom-webpack ile bile RCE çalışıyor, yani mekanizma tamamen doğru anlaşılmamış gibi
      Gerçek bir Next.js projesi üzerinde demo gösterilse iyi olurdu
    • Yine de derleyen yazı gerçekten etkileyiciydi

  • “Vercel olmadan RCE yok” denecek noktaya gelinmesi, bu olayın hosting ortamı ile güvenlik arasındaki ilişkiyi ortaya koyduğunu gösteriyor

  • CVE puanı 10.0, bu kadar yaygın kullanılan bir projede sarsıcı bir değer

    • Etkilenen paket react-server-dom-webpack, “deneyseldir ve risk size aittir” diye açıkça belirtiyor
      Buna rağmen haftalık indirme sayısı 310 bini aşıyor
    • Bu tür olaylarda CVSS 10.0’ın açıkça yazılması gerekir; yoksa PR amaçlı söylemlerle üstü örtülebilir
    • React çok yaygın kullanılıyor ama React Server Components henüz o kadar genel değil

  • React ekibinin neden bu kadar kafa karıştırıcı özelliklere zaman harcadığını anlamak zor
    SSR’den ne kadar daha iyi olduğu, performans kazanımının ne düzeyde olduğu da belirsiz
    Hook’ların gelmesinden sonra geliştirici deneyimi kötüleşti ama bunu iyileştirmek yerine yeni bir karmaşıklık daha ekleniyor
    Keşke bunun yerine JS’in doğal kontrol akışının bileşen mantığında doğal biçimde kullanılmasını sağlasalardı

    • Server Components, SSR ile doğrudan ilgili değil
      Ben bunu bileşenleştirilmiş bir BFF (Backend for Frontend) katmanı olarak görüyorum
      Her UI parçası, karşılık gelen backend mantığına doğrudan bağlanıyor ve fetch çağrıları olmadan veri alabiliyor
      Bu da frontend ile backend’in birlikte evrilmesini kolaylaştırıyor ve yalnızca gereken verinin ince ayarlı biçimde yüklenmesine olanak tanıyor
      Sonuç olarak yalnızca UI’ye özel sunucu mantığı, bileşen yapısının içine doğal biçimde yerleşebiliyor
    • React’in “varsayılan framework” hâline gelmiş olması üzücü
      Svelte veya React’in compiler tabanlı modeli çok daha rahat yönetiliyor
    • Temelde sorunun JS dilinin sınırları ve rekabet eksikliği olduğunu düşünüyorum
      Vue, Svelte, Angular vb. hepsi ayrı compiler ve dosya uzantıları gerektiriyor
      Buna karşılık React/JSX, preprocessor aşamasında zaten ayrıcalıklı muamele görüyor
      Rust bu sorunu macro sistemiyle çözdü — örneğin Leptos veya Yew, standart .rs dosyaları içinde JSX ya da HTML template desteği sunuyor
      JS böyle bir genişletilebilirlik kazanmazsa, web büyük olasılıkla ileride de karmaşık ve verimsiz bir ortam olarak kalacak
    • Ben hooks’u seviyorum :)
    • RSC, SSR’yi hızlandıramamanın ardından ortaya çıkan bir alternatif deneme
      İstemci tarafı yükünü azaltmaya çalıştı ama o da başarısız olmuş gibi görünüyor

  • React blogundaki ayrıntılı açıklamaya da bakmaya değer