Frontend Artık Sadece Frontend Değil

Bazı açıklar yamalanır ve kısa sürede unutulur. Bazıları ise kullandığımız mimarinin risk modelini yeniden düşünmemize neden olur. CVE-2025-55182 ikinci kategoriye giriyor.

3 Aralık 2025'te React ekibi, React 19 ve React Server Components kullanan Next.js sürümlerini etkileyen kritik bir uzaktan kod çalıştırma açığını duyurdu. Araştırmacılar kısa sürede bu açığa React2Shell adını verdi. Log4Shell benzetmesi de bu noktada ortaya çıktı. Bu benzetme abartılı görünse de temelsiz değil.

React2Shell'i kritik yapan üç özellik var: yaygın kullanılan modern web framework'lerini etkiliyor; kimlik doğrulama gerektirmeden uzaktan tetiklenebiliyor; "frontend" olarak görülen bir framework üzerinden sunucu tarafında kod çalıştırma riski oluşturuyor. Son madde özellikle önemli.

React uzun süre arayüz katmanı olarak düşünüldü. Ancak React Server Components ve modern SSR mimarileriyle birlikte bu ayrım değişti. Artık bazı React bileşenleri doğrudan sunucu tarafında çalışıyor. Bu da frontend framework'ünü uygulama güvenliği açısından backend yüzeyinin parçası haline getiriyor. React2Shell bu geçişin güvenlik sonucunu görünür hale getirdi.

Bir saldırgan, hazırlanmış bir HTTP isteğiyle sunucu tarafı RSC işleyicisini hedefleyebiliyorsa, konu artık yalnızca tarayıcıda çalışan JavaScript değildir. Konu; uygulama süreci, ortam değişkenleri, veritabanı bağlantıları, dosya sistemi ve iç servis erişimleridir. Bu yüzden React2Shell yalnızca bir React açığı değil, modern web mimarisinin yanlış sınıflandırılmış bir güvenlik yüzeyidir.

Bir Bakışta Açık

CVSS 10.0
Maksimum Seviye

Kimliği doğrulanmamış, uzaktan, kullanıcı etkileşimi gerekmez

React Güvenlik Bildirimi
3 Ara 2025
Açıklama Tarihi

Yamaları mevcut koordineli açıklama

React Güvenlik Bildirimi
React 19
Birincil Etkilenen Yığın

Ayrıca React Server Components kullanan Next.js sürümleri

React Güvenlik Bildirimi
~%40
Tahmini React Benimsenmesi

React kullanan yeni web uygulamalarının payı (sektör tahmini)

Strobes Top CVEs Aralık 2025

Açık Nedir?

React Server Components, React 19 ve modern Next.js mimarisinde kullanılan önemli bir modeldir. Bu modelde bazı bileşenler istemci tarafında, bazıları ise sunucu tarafında çalışır. Sunucu tarafında çalışan bileşenler, istemciye klasik anlamda yalnızca HTML göndermez. Bunun yerine React ağacının yeniden oluşturulabilmesi için özel bir serileştirme formatı kullanılır. Bu format hızlıdır, ifade gücü yüksektir ve framework'e esneklik sağlar. Ancak bu esneklik aynı zamanda risk üretir.

CVE-2025-55182, etkilenen sürümlerde bu serileştirme ve deserialization sürecinin kötüye kullanılabilmesiyle ilgilidir. Özel olarak hazırlanmış bir RSC isteği, sunucu tarafı handler'ın saldırgan kontrollü veriyi güvenli olmayan şekilde işlemesine neden olabilir. Bu süreçte saldırgan, uygulama süreci içinde kod çalıştırma imkânı elde edebilir.

Bu tür açık güvenlik dünyası için yeni değildir. Java RMI, Python pickle, .NET BinaryFormatter ve benzeri teknolojilerde yıllardır görülen "güvenilmeyen verinin deserialize edilmesiyle kod çalıştırma" sınıfının modern web framework dünyasındaki yeni bir örneğidir. Yeni olan şey, bu örüntünün React Server Components gibi frontend kökenli görülen bir mimaride ortaya çıkmasıdır.

Açığın etkisini artıran kritik nokta: RSC işleyicisi, bazı dağıtımlarda kimlik doğrulama veya yetkilendirme uygulanmadan önce saldırgan kontrollü veriyi işleyebilir. Bu da açığı klasik "authenticated admin panel bug" kategorisinden çıkarır. İnternete açık bir RSC endpoint'i varsa, saldırganın tek ihtiyacı uygun biçimde hazırlanmış bir istektir.

Neden 'Frontend'in Log4Shell'i' Benzetmesi Doğru?

Log4Shell modern yazılım güvenliğinde dönüm noktası oldu. Bunun nedeni yalnızca Log4j'de kritik bir açık bulunması değildi — asıl neden Log4j'nin neredeyse her yerde kullanılması ve saldırının son derece düşük eşikle tetiklenebilmesiydi. Tek bir saldırgan kontrollü string, doğru kod yoluna ulaştığında uzaktan kod çalıştırmaya yol açabiliyordu. React2Shell modern web yığınına çevrilmiş aynı özellikleri paylaşıyor: React modern web geliştirmede en yaygın kullanılan framework'lerden biri (sektör tahmini yeni web uygulamalarının ~%40'ı), Next.js React tabanlı üretim uygulamalarında güçlü konumda, RSC modern Next.js mimarisinde varsayılan. Tek bir hazırlanmış HTTP isteği, kimlik doğrulama yok, tam sunucu ele geçirme. Birçok ekip React'i hâlâ "frontend" olarak sınıflandırır — bu refleks artık yetersiz. Uygulama kodunun bir kısmı sunucuda çalışır ve saldırgan için backend etkisi doğurur. "Frontend'in Log4Shell'i" yalnızca çarpıcı bir başlık değil; daha derin bir mimari uyarıdır: frontend framework'leri artık backend güvenlik disiplininden muaf değildir.

Saldırı Zinciri Nasıl İşler?

React2Shell sınıfı bir saldırı dışarıdan bakıldığında oldukça sade görünebilir. Ancak etkisi, sunucu tarafı çalışma bağlamı nedeniyle büyüktür.

1

Hedefin Belirlenmesi

Saldırgan önce React 19 veya RSC kullanan güncel Next.js uygulamalarını tespit etmeye çalışır. Bu parmak izi alma süreci çoğu zaman zor değildir. RSC endpoint'leri karakteristik URL örüntüleri, içerik tipleri, response formatları veya framework davranışları üzerinden belirlenebilir. İnternete açık tarayıcılar ve otomatik keşif araçları bu tür yüzeyleri geniş ölçekte listeleyebilir. Açık duyurulduktan sonra ilk risk, hedefli saldırılardan önce otomatik tarama dalgasıdır.

2

Hazırlanmış RSC İsteği

Saldırgan RSC endpoint'ine özel biçimlendirilmiş bir HTTP isteği gönderir. Bu istek dışarıdan bakıldığında tamamen anormal görünmek zorunda değildir. İçerik tipi, header yapısı ve endpoint hedefi meşru RSC trafiğine benzeyebilir. Tehlikeli kısım payload'ın içindedir — sunucu tarafındaki deserialization sürecini kötüye kullanacak şekilde hazırlanır. Farklı gadget zincirleri, farklı encoding teknikleri veya farklı çerçeveleme biçimleriyle aynı etki üretilebilir; bu da tespiti zorlaştırır.

3

Sunucu Tarafında Deserialization

Etkilenen sürümlerde sunucu tarafı RSC handler'ı gelen payload'ı güvenli olmayan biçimde işler. Deserialization, kimlik doğrulama veya yetkilendirme kontrollerinden önce gerçekleşiyorsa, saldırganın kimliği doğrulanmamış olması saldırıyı engellemez. Bu aşamada saldırgan uygulamanın çalıştığı süreç içinde kod çalıştırma imkânı elde edebilir. Saldırının asıl kırılma noktası budur — çünkü saldırgan artık tarayıcıda değil, sunucuda etki üretir.

4

Uygulama Yetkileriyle İlerleme

Sunucu tarafında kod çalıştırma yalnızca tek bir komut çalıştırmak anlamına gelmez. Saldırgan uygulama sürecinin sahip olduğu yetkilere erişebilir — ortam değişkenleri, veritabanı bağlantı bilgileri, API anahtarları, dosya sistemi erişimi, iç servis erişimleri, log ve cache sistemleri, queue/storage/messaging altyapıları, cloud metadata endpoint'leri, servis hesabı token'ları. Buradan sonra saldırı klasik post-exploitation aşamasına geçer: sırların toplanması, kalıcılık, yatay hareket, veri sızdırma.

5

İzleri Gizleme

React2Shell gibi açıklarda ilk istek meşru RSC trafiğine benzeyebilir. Saldırganlar exploit denemelerini normal trafik örüntüleri içine karıştırmaya çalışabilir. Uygulama seviyesinde yeterli loglama yoksa ilk tetikleyici isteği bulmak zorlaşır. Olay sonrası inceleme için yalnızca access log yeterli olmayabilir — RSC endpoint'lerine gelen payload yapıları, anormal serialization örüntüleri, kimliği doğrulanmamış POST denemeleri ve olağandışı hata kodları birlikte incelenmelidir.

WAF Tespiti Neden Zor?

WAF'lar birçok saldırı sınıfında güçlü bir ilk savunma katmanıdır. SQL injection, XSS, path traversal, bilinen exploit payload'ları ve protokol ihlalleri gibi örüntüleri ölçekli şekilde yakalayabilirler. React2Shell sınıfı açıklar ise WAF tespiti açısından daha zordur — üç nedenle.

Trafik Meşru RSC Trafiğine Benzeyebilir

Exploit isteği aynı endpoint'i, aynı içerik tipini ve benzer header yapısını kullanabilir. Yalnızca URL veya içerik tipi üzerinden engelleme yapmak yüksek yanlış pozitif üretebilir. RSC trafiğini tamamen kapatmak işlevselliği bozar. WAF'ın yalnızca "RSC isteği gördüm, engelleyeyim" yaklaşımı yeterli değildir — payload yapısını, istek örüntüsünü, endpoint davranışını ve uygulama bağlamını birlikte değerlendirmek gerekir.

Payload Polimorfiktir

Deserialization exploit'leri farklı biçimlerde ifade edilebilir — farklı gadget zincirleri, farklı encoding, farklı nesting yapıları, farklı serileştirme varyasyonları. Aynı sömürü amacı birçok farklı payload biçimiyle elde edilebilir. Bu, statik imzaların ömrünü kısaltır. Bir imza belirli bir varyantı yakalarken saldırgan aynı açığı farklı bir payload yapısıyla tekrar deneyebilir.

Uygulama Bağlamı Gerekir

React2Shell'in etkili tespiti yalnızca protokol seviyesinde yapılamaz. Payload'ın RSC akışında ne anlama geldiğini ve hangi yapıların normalde kabul edilmemesi gerektiğini anlamak gerekir. Bu uygulama bağlamı olmadan WAF tespiti kısmî kalır. Kalıcı çözüm framework yamasıdır — WAF, yama penceresinde tarama ve düşük becerili exploit denemelerini azaltır ama yamalamanın yerine geçmez.

Kurumlar Ne Yapmalı?

React2Shell gibi açıklar için doğru yanıt panik değil önceliklendirilmiş müdahaledir. Aşağıdaki adımlar sırayla ele alınmalıdır.

1

React 19 ve Next.js RSC Uygulamalarını Envantere Alın

İlk adım hangi uygulamaların etkilendiğini bilmektir. Yalnızca ana üretim uygulamaları değil; staging ortamları, partner portalları, iç yönetim panelleri, demo ortamları, geçici yayınlar, edge deployment'lar, serverless fonksiyonlar, preview environment'lar ve eski ama internete açık Next.js uygulamaları da envantere dahil edilmelidir. Sahiplik bilgisi de envanterin parçası olmalıdır. Öncelik: internete açık mı, RSC kullanıyor mu, kimlik doğrulama öncesi endpoint var mı, hassas veri veya iç servis erişimi var mı, yüksek yetkili servis hesabıyla mı çalışıyor.

2

Resmi Yamaları Uygulayın

Kalıcı çözüm resmi yamaları uygulamaktır. React güvenlik bildirimi ve ilgili framework duyuruları etkilenen sürümler ve güncelleme yolları için takip edilmelidir. Bağımlılık çatışmaları, test kırılmaları veya deployment süreci nedeniyle gecikiyorsa konu normal bakım döngüsüne bırakılmamalıdır. Bu sınıftaki açıklar için yama önceliği en yüksek seviyede olmalıdır. İnternete açık, RSC kullanan ve hassas veri işleyen uygulamalarda yama süresi saatler veya günler ölçeğinde düşünülmelidir.

3

RSC Endpoint Doğrulamasını Sıkılaştırın

Yama gecikiyorsa veya geçiş sürecinde ek savunma gerekiyorsa RSC endpoint'leri için ek doğrulama uygulanmalıdır: beklenen içerik tiplerinin zorunlu kılınması, payload boyut sınırları, şema doğrulama, kötü biçimlendirilmiş serileştirme dizilerinin reddi, kimlik doğrulama öncesi RSC erişiminin azaltılması, beklenmeyen HTTP method'larının kapatılması, endpoint bazlı rate limit, anormal header ve body kombinasyonlarının işaretlenmesi. Bu kontroller yamayı ikame etmez ama saldırı yüzeyini daraltır.

4

Kasım 2025'ten İtibaren Logları İnceleyin

Açık duyurulmadan önce de bazı saldırganların exploit denemeleri yapmış olma ihtimali değerlendirilmelidir. Kasım 2025'ten itibaren RSC endpoint'lerine gelen trafiği inceleyin: kimliği doğrulanmamış POST istekleri, olağandışı payload boyutları, beklenmeyen serialization yapıları, kötü biçimlendirilmiş istekler, normal kullanıcı akışıyla ilişkili olmayan RSC çağrıları, tek IP'den çok sayıda varyasyon denemesi, hata kodu artışları, uygulama crash veya restart olayları, RSC endpoint'lerinde anormal latency artışı. Başarılı sömürü ihtimali varsa: sır rotasyonu, servis hesabı gözden geçirme, container image doğrulama, dosya sistemi değişiklik analizi ve iç ağ hareketi incelemesi yapılmalıdır.

5

WAF Yönetilen Kurallarını Etkinleştirin

TR7 dahil büyük WAF sağlayıcıları React2Shell saldırı örüntülerine yönelik yönetilen kurallar yayınlamıştır. Bu kurallar otomatik tarama dalgalarını azaltmak, bilinen exploit varyantlarını yakalamak, düşük becerili saldırıları engellemek, RSC endpoint trafiğinde anomali görünürlüğü sağlamak ve yama uygulanana kadar ek koruma katmanı oluşturmak için fayda sağlar. WAF kuralları mutlak güvence olarak görülmemelidir — payload polimorfizmi ve uygulama bağlamı nedeniyle WAF'ın yakalayamayacağı varyantlar olabilir. Doğru sıra: önce yama, sonra WAF ile derinlemesine savunma.

6

Bir Sonraki Framework Açığı İçin Hazırlık Yapın

React2Shell yalnızca tek bir CVE değildir. Modern framework mimarisinin güvenlik testinden geçmesi gereken yeni yüzeyler oluşturduğunu gösterir. React Server Components, SSR, edge rendering, server actions, streaming response'lar ve framework içi serileştirme protokolleri klasik frontend güvenlik modelinden daha fazlasını gerektirir. Bu yüzeyleri backend gibi tehdit modelleyin: hangi framework kodu sunucuda çalışıyor, hangi endpoint'ler otomatik oluşturuluyor, deserialization veya serialization nerede yapılıyor, kimlik doğrulama hangi aşamada uygulanıyor, server action'lar hangi yetkilerle çalışıyor, framework endpoint'leri loglanıyor mu, rate limit var mı, preview/staging ortamları internete açık mı.

Bu Açık Modern Web Yığını Hakkında Ne Söylüyor?

React2Shell'in en önemli dersi açık sınıfının yeni olması değil. Tam tersine, açık sınıfı çok tanıdık: güvenilmeyen verinin deserialize edilmesi ve kod çalıştırmaya yol açması. Yeni olan yüzeydir. Bu açık klasik backend güvenlik probleminin frontend kökenli bir framework mimarisinde ortaya çıkabileceğini gösterdi. İki sonuç doğurur: birincisi, frontend framework ekipleri artık backend framework ekiplerinin taşıdığı güvenlik sorumluluklarının bir kısmını taşır — sunucu tarafında çalışan bileşenler, framework protokolleri, server actions ve serialization katmanları saldırgan gözüyle test edilmelidir. İkincisi, kurumsal güvenlik ekipleri React, Next.js, Remix, Astro ve benzeri modern framework'leri yalnızca istemci tarafı teknoloji olarak sınıflandırmamalıdır — bu framework'ler çoğu dağıtımda backend davranışı üretir. Güvenlik mimarisindeki kategori değişmelidir: sunucuda çalışan frontend kodu, backend kodudur.

TR7 Katmanları React2Shell Sınıfı Tehditlere Nasıl Yanıt Verir?

React2Shell gibi açıklarda birincil çözüm yamadır. Ancak yama uygulanana kadar ve yama sonrası benzer sınıf risklere karşı katmanlı savunma gerekir. TR7'nin WAAP yaklaşımı bu tür tehditlere birden fazla katmanda yanıt verir.

WAF Yönetilen Kurallar

TR7 WAF, React2Shell saldırı örüntülerini protokol, endpoint ve payload yapısı seviyesinde tespit etmek için ayarlanmış yönetilen kurallar sunar. Yeni exploit varyantları ortaya çıktıkça kural setleri güncellenir. İnternet genelinde başlayan otomatik tarama ve düşük becerili exploit denemelerine karşı ilk savunma katmanıdır.

RSC Endpoint'lerinde Hız Sınırlama

Uygulama farkında hız sınırlama otomatik keşif ve exploit varyasyonu denemelerini azaltır. Saldırganlar çok sayıda hedefte çok sayıda payload denemesi yapar — endpoint bazlı rate limit tarama hızını düşürür ve saldırı ekonomisini bozar.

AGS ile Kimlik Doğrulama

TR7 Erişim Geçidi, iç uygulamalar ve yönetim panelleri için istek uygulamaya ulaşmadan önce kimlik doğrulamayı zorunlu hale getirebilir. RSC endpoint'lerinin kimliği doğrulanmamış internete açık kalmasını engeller. Minimum yetki ve koşullu erişim politikaları uygulanır.

Gerçek Zamanlı Analitik

RSC endpoint trafiğinde olağandışı payload yapıları, beklenmeyen istek örüntüleri, anormal hata oranları ve sıra dışı kaynak dağılımları gerçek zamanlı analitikle işaretlenebilir. Bireysel istekler meşru görünebilir; oturum veya kaynak düzeyinde saldırı denemesi ortaya çıkar — bu görünürlük polimorfik payload'larda özellikle önemlidir.

Forensik Loglama

RSC yollarındaki istek/yanıt detayları, oturum bağlamı, WAF kararları ve anomali sinyalleri olay sonrası rekonstrüksiyon için kullanılabilir hale getirilir. Güvenlik ekipleri "hangi payload geldi, hangi endpoint etkilendi, hangi oturum bağlamında gerçekleşti ve hangi veri riske girdi?" sorularını araştırabilir.

ZeroLeak ile Yüksek Değerli İzolasyon

Bazı React/Next.js uygulamaları sıradan web uygulaması değildir — finansal paneller, müşteri PII konsolları, hukuki belge portalları, yönetici arayüzleri. Bu uygulamalar için ZeroLeak görsel tarayıcı izolasyonu ek bir mimari kontrol sağlar. Kullanıcı yalnızca piksel akışını görür; DOM, JavaScript, API yanıtı veya oturum token'ı gönderilmez.

Sonuç: Önce Yama, Sonra Kalıcı Mimari Ders

React2Shell için ilk ve en önemli yanıt nettir: etkilenen React 19 ve Next.js RSC uygulamalarını bulun ve resmi yamaları uygulayın. Bu adım ertelenmemelidir. Kimlik doğrulama gerektirmeyen uzaktan kod çalıştırma açıkları, özellikle yaygın framework yüzeylerinde en yüksek öncelikli güvenlik olaylarıdır.

Ancak bu açık yalnızca bir yamalama görevi olarak kapatılmamalıdır. React2Shell modern web mimarisine dair daha büyük bir ders verir: frontend framework'leri artık yalnızca tarayıcıda çalışan UI kodundan ibaret değildir. Server Components, SSR, server actions ve edge runtime gibi modeller frontend ile backend arasındaki sınırı bulanıklaştırır.

Bu nedenle güvenlik ekiplerinin tehdit modeli de değişmelidir. React, Next.js ve benzeri framework'lerde sunucuda çalışan her yol backend güvenlik disipliniyle ele alınmalıdır. Serialization ve deserialization katmanları incelenmelidir. Framework tarafından otomatik oluşturulan endpoint'ler envantere alınmalıdır. Kimlik doğrulama sırası ve endpoint maruziyeti açıkça test edilmelidir.

React2Shell'in kısa dersi: sunucuda çalışan frontend kodu, backend riskidir.

Kaynaklar

CVE-2025-55182 React2Shell dahil Aralık 2025 kritik CVE'lerinin sektör analizi. https://strobes.co/blog/top-cves-of-december-2025/

React2Shell duyurusu ve saldırı manzarası hakkında bağımsız haberler. https://securityboulevard.com/2026/01/top-cves-of-december-2025/

CISA'nın vahşi doğada saldırı takibi. https://www.cisa.gov/known-exploited-vulnerabilities-catalog

Önce Yama, Sonra Katmanlı Savunma

React güvenlik bildirimindeki yamaları etkilenen tüm uygulamalara uygulayın. RSC endpoint'lerini envantere alın, geçmiş trafiği inceleyin ve yama penceresinde WAF yönetilen kurallarıyla ek koruma sağlayın. TR7 WAF, AGS, gerçek zamanlı analitik, forensik loglama ve ZeroLeak izolasyonu React2Shell sınıfı tehditlere karşı katmanlı savunma sağlar.

TR7 WAF'ı Keşfet