React Sunucu Bileşenlerinde DoS ve kaynak kodu ifşa açığı açıklandı

• React Server Components içinde yeni keşfedilen ve açıklanan hizmet reddi (DoS) ile kaynak kodu ifşası açıkları bulunuyor
• Bu açıklarla uzaktan kod çalıştırma (RCE) mümkün değil, ancak sunucunun durması veya kod sızıntısı riski var
• Etkilenen paketler react-server-dom-webpack, react-server-dom-parcel, react-server-dom-turbopack paketlerinin 19.0.0~19.2.2 sürümleri; düzeltilmiş sürümler ise 19.0.3, 19.1.4, 19.2.3
• DoS açıkları (CVE-2025-55184, CVE-2025-67779) kötü amaçlı HTTP istekleriyle sunucuda sonsuz döngü tetikleyebilir; kaynak kodu ifşa açığı (CVE-2025-55183) ise sunucu fonksiyonlarının kodunun bir kısmını döndürebilir
• React ekibi hemen yükseltme yapılmasını öneriyor ve bu ek duyurunun güvenlik müdahale döngüsünün normal bir parçası olduğunu belirtiyor

---

Yeni açıklanan açıkların özeti

• Güvenlik araştırmacıları, geçen hafta açıklanan kritik güvenlik açığı yamasını doğrularken iki ek açık keşfetti
• Yeni açıklarla uzaktan kod çalıştırma (RCE) mümkün değil ve mevcut React2Shell yaması hâlâ geçerli
• Yeni açıklanan açıklar şunlar:
  • Hizmet reddi (DoS) — CVE-2025-55184, CVE-2025-67779 (CVSS 7.5, yüksek önem derecesi)
  • Kaynak kodu ifşası — CVE-2025-55183 (CVSS 5.3, orta önem derecesi)
• React ekibi derhal yükseltme yapılmasını tavsiye ediyor

Mevcut yamanın eksik kalması

• Geçen hafta dağıtılan 19.0.2, 19.1.3, 19.2.2 sürümlerindeki yamalar eksik kaldığı için yeniden güncelleme gerekiyor
• Tam düzeltme 19.0.3, 19.1.4, 19.2.3 sürümlerinde yer alıyor
• Önceki gönderideki güncelleme talimatları izlenmeli
• Düzeltmeler dağıtıldıktan sonra ek ayrıntılar açıklanacak

Etkilenen paketler ve sürümler

• Açıklar, CVE-2025-55182 ile aynı paket ve sürümlerde bulunuyor
• Etkilenen sürümler: 19.0.0~19.2.2
• Etkilenen paketler:
  • react-server-dom-webpack
  • react-server-dom-parcel
  • react-server-dom-turbopack
• Düzeltilmiş sürümler: 19.0.3, 19.1.4, 19.2.3
• Sunucu kullanmayan veya React Server Components desteklemeyen uygulamalar etkilenmiyor

Sonradan açıklanan açıkların yaygın kalıbı

• Kritik bir CVE açıklandıktan sonra, ilişkili kod yolları ek olarak analiz edilirken sonradan gelen açıklar sıkça keşfedilir
• Örnek olarak Log4Shell sonrasında ek CVE’lerin raporlandığı duruma değiniliyor
• Bu tür ek açıklamalar, güvenlik müdahale sürecinin normal şekilde işlediği anlamına geliyor

Etkilenen framework ve bundler'lar

• Aşağıdaki framework ve bundler'lar savunmasız React paketlerini içeriyor veya onlara bağımlı
  • next, react-router, waku, @parcel/rsc, @vitejs/plugin-rsc, rwsdk
• Önceki gönderideki güncelleme talimatları izlenmeli

Hosting sağlayıcılarının geçici önlemleri

• Birden fazla hosting sağlayıcısıyla birlikte geçici önlemler uygulandı
• Ancak bu önlemlere güvenmek yerine hemen güncelleme yapılması gerekiyor

React Native ile ilgili talimatlar

• Sadece React Native kullananların ek işlem yapması gerekmiyor
• Monorepo ortamlarında yalnızca şu paketlerin güncellenmesi gerekiyor
  • react-server-dom-webpack
  • react-server-dom-parcel
  • react-server-dom-turbopack
• react ve react-dom paketlerini güncellemeye gerek yok
• İlgili ayrıntılar için React Native GitHub issue’suna bakılabilir

Yüksek önem derecesi: hizmet reddi (DoS)

• CVE-2025-55184, CVE-2025-67779, CVSS 7.5
• Kötü amaçlı bir HTTP isteği React sunucu fonksiyonu endpoint’ine gönderildiğinde, deserialize sürecinde sonsuz döngü oluşabilir
• Sunucu süreci durabilir ve CPU’yu aşırı tüketebilir
• Sunucu fonksiyonu endpoint’ini doğrudan uygulamış olmasanız bile, React Server Components destekleyen bir uygulama savunmasız olabilir
• Bugün dağıtılan yama, sonsuz döngüyü önleyerek sorunu çözüyor
• İlk düzeltme eksik kaldığı için ek açık (CVE-2025-67779) ile tamamlandı

Orta önem derecesi: kaynak kodu ifşası

• CVE-2025-55183, CVSS 5.3
• Kötü amaçlı bir HTTP isteği, sunucu fonksiyonunun kaynak kodunun bir kısmını döndürebilir
• Bu durum, sunucu fonksiyonu string argümanları açık ya da örtük biçimde ifşa ettiğinde ortaya çıkabilir
• Örnek kodda veritabanı bağlantı anahtarı gibi hardcoded gizli değerler açığa çıkabilir
• Yama, sunucu fonksiyon kaynak kodunun string’e çevrilmesini engelleyerek sorunu çözüyor
• İfşa kapsamı sunucu fonksiyonunun iç koduyla sınırlı; çalışma zamanı sırları (process.env.SECRET vb.) etkilenmiyor
• Doğrulama, production bundle üzerinden yapılmalı

Zaman çizelgesi

• 3 Aralık: Andrew MacPherson, Vercel ve Meta Bug Bounty’ye kod ifşasını bildirdi
• 4 Aralık: RyotaK, DoS açığını bildirdi
• 6 Aralık: React ekibi iki sorunu doğruladı ve incelemeye başladı
• 7 Aralık: İlk düzeltme taslağı hazırlandı ve doğrulama planı oluşturuldu
• 8 Aralık: Hosting sağlayıcıları ve açık kaynak projeleri bilgilendirildi
• 10 Aralık: Geçici önlemler uygulandı ve yama doğrulaması tamamlandı
• 11 Aralık: Shinsaku Nomura ek DoS açığını bildirdi; CVE-2025-55183, 55184 ve 67779 açıklandı

Bildirenler

• Andrew MacPherson (AndrewMohawk) — kaynak kodu ifşasını bildirdi
• RyotaK (GMO Flatt Security Inc) ve Shinsaku Nomura (Bitforest Co., Ltd.) — hizmet reddi açıklarını bildirdi

[GN⁺]

Hacker News yorumları

• React Server Components (RSC) bana her zaman rahatsız edici gelmiştir
  Çünkü yalnızca JavaScript koduna bakarak istemcide çalışan kısım ile sunucuda çalışan kısmı ayırt etmek zordur
  Üstelik bunu uygulamak için derin bir serileştirilmiş RPC mekanizması gerekir; bu da geliştirici için opaktır ve güvenlik açıkları riskini artırır

  • Eskiden NextJS pages router döneminde sunucu ve istemci kodu arasındaki sınır netti, bu güzeldi
    Ama app router'a geçince kafa karıştırıcı oldu. Kod her iki tarafta da çalışabildiği için Headers gibi nesneler her zaman mevcut olmuyor ve neyin nerede çalıştığını anlamak zorlaşıyordu
  • Yeni katıldığım bir ekipte Next kullanıldığını gördüm ve “bunun nasıl çalıştığını bilen var mı?” diye sordum, ama kimse net biçimde açıklayamadı
    React+Next iyi çalıştığında sihir gibi hissettiriyor, ama ekip olarak çalışırken öngörülebilirliğin giderek kaybolması sorun
  • Bu yüzden ben Inertia.js hayranıyım. Inertia.js, Laravel, Rails, Django gibi geleneksel MVC arka uçları ile React, Vue, Svelte gibi ön uç araçlarını doğal biçimde birleştiriyor
    Roller net, iş akışı basit ve çoğu projede en güvenli seçenek olduğunu düşünüyorum
  • RSC ve SSR bana fazla benimsenmiş gibi geliyor
    Landing page veya pazarlama sayfaları için SSR faydalı olabilir, ama genel SaaS panoları gibi uygulamalarda karmaşıklığına kıyasla neredeyse hiçbir getirisi yok
  • Diğer framework'lerin (Angular, SvelteKit, Nuxt) bu tür açıklara ne kadar maruz olduğunu merak ediyorum
    React yalnızca çok popüler olduğu için mi daha fazla dikkat çekiyor, yoksa yapısal olarak daha mı riskli diye düşünüyorum

• Geçen hafta RSC'yi inceledim; karmaşıklık çok yüksekti ve dokümantasyon da neredeyse yoktu
  React bunun hâlâ deneysel bir özellik olduğunu söylüyor ama NextJS bunu zaten geniş ölçekte dağıttı
  İleride daha fazla güvenlik sorunu çıkacak gibi görünüyor ve Next'in build sistemi o kadar karmaşıktı ki debug etmek bile zordu
  Sağladığı faydaya göre maliyeti fazla yüksek

  • Eskiden beri Next'in “henüz production'a hazır olmayan React özelliklerini” en yeni özelliklermiş gibi sunduğuna dair şikâyetler vardı
    Ben de bu yüzden Next'ten ayrıldım. Bilişsel yük çok fazlaydı ve karşılığında elde edilen şey azdı
  • React uzun süredir dokümantasyon eksikliği sorunu yaşıyor
    Sadece RSC'de değil, genel olarak da net rehberler geç geldi ve CRA gibi araçlar da resmî olarak sahiplenilmedi
    Şimdi ancak useEffect dokümantasyonu iyileşti ama çok geç oldu
    2025 olmuş olmasına rağmen işte hâlâ kullanıyorum ve yine de açık, net dokümantasyon eksik

• SPA'nın özü, “tüm uygulamayı istemciye gönderip sunucuyla yalnızca veri alışverişi yapmak”tı

  • Ama şimdi C# dünyasında Blazor Server moda
    Eski .aspx Web Forms gibi, her tıklama ve giriş sunucuya gönderiliyor ve değişen DOM geri geliyor
    Fiilen eski yönteme dönmüş gibiyiz; bu biraz absürt
  • Sonuçta birçok geliştirici server-side rendering'in neden var olduğunu yeniden fark edip PHP, Rails, Spring gibi full-stack framework'lere geri döndü
  • Ama bugünlerde React gibi kütüphanelerle statik siteler yapmak yaygınlaştı ve bu, basit bir template engine + JS birleşiminden daha yavaş ve daha karmaşık
    “İşe uygun aracı seçme hissi”nin kaybolmuş olması üzücü
  • Tabii RSC saf SPA için değil. Başka bir amacı olan bir yaklaşım

• Bu güvenlik duyurusunda en çok dikkatimi çeken ifade, “ciddi bir CVE bulunduğunda ardından ek açıkların ortaya çıkması yaygındır” cümlesiydi
  Sorunun kapsamını, etkisini veya azaltma yöntemlerini açıklamadan önce CVE'yi meşrulaştırmaya çalışıyor gibi göründüğü için tedirgin ediciydi

  • Ama bazıları bunun meşrulaştırma değil, insanların ilk merak edeceği noktaya yönelik bir açıklama olduğunu düşünüyor
  • Geri bildirimler yansıtılarak ifade değiştirildi deniyor → güncellenmiş PR bağlantısı
  • Bunu algı yönetimi (perception management) olarak tanımlayanlar da var
    ilgili Vikipedi maddesi
  • Bu meselede kariyerle ilgili çıkar ilişkileri olduğunu düşünen bir bakış açısı da var
  • Birisi “bu, sanki Vercel pazarlama ekibinin yazdığı bir metin gibi duruyor” dedi

• 15 yıl önce Opa'da zaten benzer bir deneme yapılmıştı
  İstemci ve sunucu kodu otomatik olarak ayrılıyor, JSX benzeri bir söz dizimi kullanılıyordu
  Ama güvenlik analizini güçlendirdikçe derleyici devasa hale geldi ve sonunda tek uygulama fikrindense net ayrımın daha önemli olduğu anlaşıldı
  Belki bir gün LLM'ler böyle kodları otomatik üretebilir ama şimdilik daha basit yapıların daha iyi olduğunu düşünüyorum

  • Aslında RSC açığı kod bölmeden çok serileştirme/seri çözme sürecinin dinamik doğasından kaynaklanıyor
    JS'deki prototype pollution, function toString, Promise override gibi sorunları önlemek için yamalar hazırlanıyor
    RSC, import "server-only" veya import "client-only" gibi statik doğrulama ile ortamları ayırdığı için yapısal olarak güvenli bir yaklaşım
  • Benzer fikirle geliştirilmiş Electric Clojure adlı bir proje de var → bağlantı
  • Bu arada Ocsigen Eliom, Opa'dan da önce bu kavramı denemişti

• React aslında MVC'nin View parçası olarak küçük ve basitken daha iyiydi
  Şimdi ise içine çok fazla özellik girdiği için şişmiş gibi hissettiriyor

  • Ama RSC ayrı bir kütüphane, bu yüzden varsayılan React kurulumuna dahil değil
  • Eski sürüme dönmek isterseniz git checkout v15.0.0 yeterli

• RSC en başta hiç var olmamalıydı
  Çoğu uygulama için sunucuda HTML render etmek yeterlidir ve SPA gerektiren durumlar çok azdır
  RSC yalnızca karmaşıklığı ve güvenlik açıklarını artırdı

  • Katılıyorum. Ama bootcamp'lerin ve VC fonlarının ittiği ekosistem bu yönü beslemeye devam ediyor
    Bun, Vercel gibi projeler “her şeyin kusursuz çalıştığı bir JS ütopyası” gibi bir illüzyon satıyor; bu yüzden bu akım kolay kolay kaybolmayacak gibi

• Geçmişte X'te Dan Abramov ile RSC hakkında tartışmıştım
  O bunun yenilikçi bir özellik olduğunu söylüyordu, ben ise “kişinin kendi ayağına sıktığı silah” demiştim. Sonunda gerçek de öyle çıktı

  • Ben şahsen RSC ile uygulama geliştirdim ve bu yaklaşımı hâlâ seviyorum
    Ama protokol düzeyindeki hata ihtimalini hafife almıştım. Bu açık özellikle serileştirme protokolüne odaklanıyor
    Güvenlik topluluğu buna ancak şimdi derinlemesine bakıyor; ekibin daha erken harekete geçmesi daha iyi olurdu
  • Başarılı sistemler sonunda aşırı genişleme yüzünden canavara dönüşmeye meyillidir
    React de basit bir render kütüphanesinden bir runtime'a dönüşürken karmaşıklığı patladı
  • Kişisel olarak Dan'in yaklaşımını pek de etkileyici bulmuyorum
    Buna karşılık Vue ve Vite bana çok daha zarif tasarlanmış geliyor → Evan You kişisel sitesi
  • Elbette çoğu fikir başarısız olur; bu yüzden sadece eleştiren bir tavra da dikkat etmek gerekir
    Bazen cesur girişimler gerçekten büyük başarıya dönüşebilir
  • “Belki de daha iyisini sen biliyorsundur” diye destek veren bir yorum da vardı

• RSC, ön ucun arka ucu yutmaya çalışması ise HTMX bunun tersidir
  HTMX istemci–sunucu sınırını koruduğu için arka uç tarafı daha güvenli kalır, ama ön uçta XSS riski vardır

  • Ama HTMX, XSS sorununu zaten template engine'in otomatik escape etmesi ile çözmüş durumda
    ilgili yazı

• Next ekibi yeni bir güvenlik güncellemesi duyurdu → NextJS Security Update 2025-12-11
  14.x, 15.x ve 16.x sürümleri etkileniyor