Kerentanan DoS dan kebocoran kode sumber pada React Server Components diungkap

 (react.dev)
4 poin oleh GN⁺ 2025-12-13 | 1 komentar | Bagikan ke WhatsApp
  • Kerentanan penolakan layanan (DoS) dan kebocoran kode sumber baru ditemukan dan diungkap pada React Server Components
  • Kerentanan ini tidak memungkinkan eksekusi kode jarak jauh (RCE), tetapi tetap menimbulkan risiko penghentian server atau kebocoran kode
  • Paket yang terdampak adalah react-server-dom-webpack, react-server-dom-parcel, dan react-server-dom-turbopack pada versi 19.0.0~19.2.2, dengan versi perbaikan 19.0.3, 19.1.4, 19.2.3
  • Kerentanan DoS (CVE-2025-55184, CVE-2025-67779) dapat memicu loop tak berujung pada server melalui permintaan HTTP berbahaya, sementara kerentanan kebocoran kode sumber (CVE-2025-55183) dapat mengembalikan sebagian kode fungsi server
  • Tim React merekomendasikan upgrade segera dan menjelaskan bahwa pengungkapan tambahan ini adalah bagian normal dari siklus respons keamanan

Ringkasan kerentanan yang baru diungkap

  • Peneliti keamanan menemukan dua kerentanan tambahan saat memverifikasi patch untuk kerentanan kritis yang diumumkan pekan lalu
  • Kerentanan baru ini tidak memungkinkan eksekusi kode jarak jauh (RCE), dan patch React2Shell yang ada tetap efektif
  • Kerentanan yang baru diungkap adalah sebagai berikut
    • Penolakan layanan (DoS) — CVE-2025-55184, CVE-2025-67779 (CVSS 7.5, tingkat keparahan tinggi)
    • Kebocoran kode sumber — CVE-2025-55183 (CVSS 5.3, tingkat keparahan sedang)
  • Tim React merekomendasikan upgrade segera

Ketidaklengkapan patch sebelumnya

  • Patch pada versi 19.0.2, 19.1.3, 19.2.2 yang dirilis pekan lalu tidak lengkap, sehingga perlu diperbarui lagi
  • Perbaikan lengkap tersedia di versi 19.0.3, 19.1.4, 19.2.3
  • Harus mengikuti panduan pembaruan pada posting sebelumnya
  • Detail tambahan akan diungkap setelah distribusi perbaikan selesai

Paket dan versi yang terdampak

  • Kerentanan ini ada pada paket dan versi yang sama dengan CVE-2025-55182
  • Versi yang terdampak: 19.0.0~19.2.2
  • Paket yang terdampak:
    • react-server-dom-webpack
    • react-server-dom-parcel
    • react-server-dom-turbopack
  • Versi perbaikan: 19.0.3, 19.1.4, 19.2.3
  • Aplikasi yang tidak menggunakan server atau tidak mendukung React Server Components tidak terdampak

Pola umum pengungkapan kerentanan lanjutan

  • Setelah pengungkapan CVE kritis, kerentanan lanjutan sering ditemukan saat jalur kode terkait dianalisis lebih lanjut
  • Disebutkan contoh kasus ketika CVE tambahan dilaporkan setelah Log4Shell
  • Pengungkapan tambahan semacam ini menunjukkan bahwa respons keamanan berjalan sebagaimana mestinya

Framework dan bundler yang terdampak

  • Framework dan bundler berikut menyertakan atau bergantung pada paket React yang rentan
    • next, react-router, waku, @parcel/rsc, @vitejs/plugin-rsc, rwsdk
  • Harus mengikuti panduan pembaruan pada posting sebelumnya

Langkah mitigasi oleh penyedia hosting

  • Bekerja sama dengan beberapa penyedia hosting untuk menerapkan langkah mitigasi sementara
  • Namun, jangan bergantung pada langkah tersebut dan segera lakukan pembaruan

Panduan terkait React Native

  • Pengguna React Native saja tidak memerlukan tindakan tambahan
  • Dalam lingkungan monorepo, hanya paket berikut yang perlu diperbarui
    • react-server-dom-webpack
    • react-server-dom-parcel
    • react-server-dom-turbopack
  • react dan react-dom tidak perlu diperbarui
  • Detail terkait dapat dilihat pada issue GitHub React Native

Keparahan tinggi: penolakan layanan (DoS)

  • CVE-2025-55184, CVE-2025-67779, CVSS 7.5
  • Jika permintaan HTTP berbahaya dikirim ke endpoint fungsi server React, proses deserialisasi dapat memicu loop tak berujung
  • Proses server dapat berhenti dan menggunakan CPU secara berlebihan
  • Meski tidak mengimplementasikan endpoint fungsi server secara langsung, aplikasi yang mendukung React Server Components tetap dapat rentan
  • Patch yang dirilis hari ini menyelesaikan masalah dengan mencegah loop tak berujung
  • Karena perbaikan awal tidak lengkap, dilakukan pelengkapan melalui kerentanan tambahan (CVE-2025-67779)

Keparahan sedang: kebocoran kode sumber

  • CVE-2025-55183, CVSS 5.3
  • Permintaan HTTP berbahaya dapat mengembalikan sebagian kode sumber dari fungsi server
  • Ini terjadi ketika fungsi server secara eksplisit atau implisit mengekspos argumen string
  • Pada contoh kode, rahasia yang di-hardcode seperti kunci koneksi database dapat terekspos
  • Patch menyelesaikan masalah dengan mencegah stringifikasi kode sumber fungsi server
  • Cakupan kebocoran terbatas pada kode internal fungsi server, dan rahasia runtime (process.env.SECRET dan sejenisnya) tidak terdampak
  • Verifikasi perlu dilakukan berdasarkan bundle produksi

Linimasa

  • 3 Desember: Andrew MacPherson melaporkan kebocoran kode ke Vercel dan Meta Bug Bounty
  • 4 Desember: RyotaK melaporkan kerentanan DoS
  • 6 Desember: Tim React mengonfirmasi kedua masalah dan memulai investigasi
  • 7 Desember: Menyusun perbaikan awal dan rencana verifikasi
  • 8 Desember: Memberi tahu penyedia hosting dan proyek open source
  • 10 Desember: Langkah mitigasi diterapkan dan verifikasi patch selesai
  • 11 Desember: Shinsaku Nomura melaporkan DoS tambahan, CVE-2025-55183·55184·67779 diungkap

Pelapor

  • Andrew MacPherson (AndrewMohawk) — melaporkan kebocoran kode sumber
  • RyotaK (GMO Flatt Security Inc) dan Shinsaku Nomura (Bitforest Co., Ltd.) — melaporkan kerentanan penolakan layanan

Bacaan terkait

1 komentar

 
GN⁺ 2025-12-13
Opini Hacker News

  • React Server Components (RSC) selalu terasa tidak nyaman
    Karena hanya dengan melihat kode JavaScript saja, sulit membedakan bagian yang berjalan di klien dan bagian yang berjalan di server
    Selain itu, untuk mewujudkannya dibutuhkan mekanisme RPC serialisasi yang dalam, yang tidak transparan bagi developer dan menjadi titik yang meningkatkan risiko celah keamanan

    • Dulu pada era NextJS pages router, batas antara kode server dan klien jelas sehingga terasa lebih baik
      Namun setelah beralih ke app router, semuanya jadi membingungkan. Karena kode bisa berjalan di kedua sisi, objek seperti Headers tidak selalu ada, jadi sulit mengetahui apa yang berjalan di mana
    • Saat melihat tim baru yang memakai Next, saya bertanya, “Apakah ada yang tahu bagaimana ini bekerja?” tetapi tidak ada yang bisa menjelaskannya dengan jelas
      Ketika React+Next berjalan dengan baik, rasanya seperti sihir, tetapi saat bekerja dalam tim, masalahnya adalah prediktabilitas makin hilang
    • Karena itu saya penggemar Inertia.js. Inertia.js menghubungkan backend MVC tradisional seperti Laravel, Rails, dan Django dengan alat frontend seperti React, Vue, dan Svelte secara alami
      Perannya jelas, pekerjaannya sederhana, dan menurut saya ini pilihan paling aman untuk sebagian besar proyek
    • RSC dan SSR tampaknya diadopsi secara berlebihan
      Untuk landing page atau halaman pemasaran, SSR memang berguna, tetapi untuk aplikasi seperti dashboard SaaS biasa, hampir tidak ada manfaatnya dibanding kompleksitasnya
    • Saya penasaran seberapa rentan framework lain (Angular, SvelteKit, Nuxt) terhadap celah semacam ini
      Apakah React hanya lebih disorot karena lebih populer, atau memang secara struktural lebih berisiko?

  • Minggu lalu saya melihat RSC, dan kompleksitasnya terlalu tinggi serta dokumentasinya nyaris tidak ada
    React memang bilang ini masih fitur eksperimental, tetapi NextJS sudah menyebarkannya secara luas
    Sepertinya akan muncul lebih banyak isu keamanan ke depan, dan sistem build Next terlalu rumit sampai-sampai sulit di-debug
    Biayanya terlalu besar dibanding manfaat yang didapat

    • Sudah lama ada keluhan bahwa Next “membungkus fitur React yang belum siap produksi” seolah-olah itu fitur mutakhir
      Karena itu saya juga meninggalkan Next. Beban kognitifnya terlalu besar dan hasil yang didapat tidak seberapa
    • React sudah lama punya masalah kurangnya dokumentasi
      Bukan hanya RSC, secara umum panduan yang jelas selalu datang terlambat, dan alat seperti CRA pun tidak diakui secara resmi
      Baru sekarang dokumentasi useEffect membaik, tetapi sudah terlambat
      Bahkan di tahun 2025 saat masih dipakai di dunia kerja, dokumentasi yang jelas tetap kurang

  • Inti dari SPA adalah “mengirim seluruh aplikasi ke klien dan hanya bertukar data dengan server”

    • Namun sekarang di ekosistem C#, Blazor Server sedang populer
      Seperti .aspx Web Forms dulu, semua klik dan input dikirim ke server, lalu DOM yang berubah dikirim balik
      Praktiknya seperti kembali ke cara lama, jadi agak absurd
    • Pada akhirnya banyak developer kembali menyadari alasan pentingnya server-side rendering, lalu kembali ke framework full-stack seperti PHP, Rails, dan Spring
    • Namun belakangan makin banyak orang membuat situs statis dengan library seperti React, padahal itu lebih lambat dan lebih rumit daripada kombinasi template engine sederhana + JS
      Sayang sekali rasa untuk “memilih alat yang tepat” seakan menghilang
    • Tentu saja RSC bukan untuk SPA murni. Ini pendekatan dengan tujuan yang berbeda

  • Dalam pengumuman keamanan kali ini, bagian yang paling menonjol adalah kalimat “ketika CVE besar ditemukan, celah lanjutan sering kali ikut terungkap”
    Sebelum menjelaskan cakupan masalah, dampak, atau mitigasinya, kalimat itu terasa seperti sedang mencoba membenarkan CVE sehingga membuat tidak nyaman

    • Namun ada juga yang melihatnya sebagai “bukan pembenaran, melainkan hanya penjelasan atas hal yang paling pertama ingin diketahui orang”
    • Disebutkan bahwa redaksinya telah diubah setelah menerima masukan → tautan PR revisi
    • Ada yang menyebut ini sebagai perception management
      Dokumen wiki terkait
    • Ada juga pandangan bahwa isu ini melibatkan kepentingan karier
    • Seseorang berkata, “Ini terlihat seperti tulisan tim marketing Vercel”

  • 15 tahun lalu Opa sudah mencoba pendekatan serupa
    Ia memisahkan kode klien dan server secara otomatis serta memperkenalkan sintaks mirip JSX
    Namun saat analisis keamanan diperkuat, kompilernya menjadi sangat besar, dan pada akhirnya disadari bahwa pemisahan yang jelas lebih penting daripada konsep aplikasi tunggal
    Mungkin suatu hari LLM bisa menghasilkan kode seperti ini secara otomatis, tetapi untuk sekarang struktur yang sederhana terasa lebih baik

    • Sebenarnya celah pada RSC lebih disebabkan oleh sifat dinamis proses serialisasi/deserialisasi daripada pemisahan kode
      Patch sedang dikerjakan untuk mencegah masalah seperti prototype pollution di JS, function toString, dan override Promise
      RSC membedakan lingkungan lewat verifikasi statis seperti import "server-only" atau import "client-only", jadi secara struktural ini pendekatan yang aman
    • Ada juga proyek dengan ide serupa bernama Electric Clojure → tautan
    • Sebagai catatan, Ocsigen Eliom sudah mencoba konsep ini lebih dulu daripada Opa

  • React dulu bagus saat kecil dan sederhana sebagai View dalam MVC
    Sekarang terasa membengkak karena terlalu banyak fitur masuk

    • Namun RSC adalah library terpisah, jadi tidak termasuk dalam instalasi React dasar
    • Kalau ingin kembali ke versi lama, cukup git checkout v15.0.0

  • Seharusnya RSC memang tidak pernah ada
    Sebagian besar aplikasi cukup dengan merender HTML di server, dan kasus yang benar-benar butuh SPA sangat sedikit
    RSC hanya menambah kompleksitas dan celah keamanan

    • Setuju. Namun ekosistem yang didorong bootcamp atau pendanaan VC terus mendorong arah ini
      Proyek seperti Bun dan Vercel menjual ilusi “utopia JS tempat semuanya berjalan sempurna”, jadi tren ini tampaknya tidak akan cepat hilang

  • Dulu saya pernah berdebat dengan Dan Abramov di X soal RSC
    Dia menyebutnya fitur inovatif, tetapi saya menyebutnya “senjata untuk menembak kaki sendiri”. Dan ternyata kenyataannya memang begitu

    • Secara pribadi saya pernah membuat aplikasi dengan RSC, dan saya tetap menyukai pendekatan ini
      Hanya saja, kemungkinan bug di tingkat protokol diremehkan. Celah kali ini berfokus pada protokol serialisasi
      Komunitas keamanan baru sekarang meninjaunya secara mendalam, jadi rasanya akan lebih baik jika tim merespons lebih awal
    • Sistem yang sukses pada akhirnya mudah berubah jadi monster karena ekspansi berlebihan
      React pun berubah dari library rendering sederhana menjadi sebuah runtime, sehingga kompleksitasnya meledak
    • Secara pribadi saya tidak merasa pendekatan Dan begitu luar biasa
      Sebaliknya, menurut saya Vue dan Vite memiliki desain yang jauh lebih elegan → situs pribadi Evan You
    • Tentu saja kebanyakan ide memang berakhir gagal, jadi sikap yang hanya mengkritik juga perlu diwaspadai
      Kadang percobaan berani justru menjadi home run
    • Ada juga komentar penyemangat: “Mungkin Andalah yang lebih hebat”

  • Jika RSC adalah upaya frontend untuk menelan backend, maka HTMX adalah kebalikannya
    HTMX mempertahankan batas klien–server sehingga sisi backend aman, tetapi di frontend ada risiko XSS

    • Namun HTMX sebenarnya sudah mengatasi masalah XSS lewat auto-escaping pada template engine
      Tulisan terkait

  • Tim Next mengumumkan pembaruan keamanan baru → NextJS Security Update 2025-12-11
    Mempengaruhi versi 14.x, 15.x, dan 16.x