Bug RSC React: Ancaman Kritis di Next.js

1.1 Apa sebenarnya Bug RSC React?

Secara sederhana, kerentanan ini terjadi
di cara React Server Components memproses data dari client.

Jadi:

• server menerima payload RSC dari client,

• lalu React mendeserialize payload itu,

• dan kemudian memutuskan fungsi apa yang harus dipanggil.

Masalahnya, di titik inilah bug terjadi.
Karena validasi tidak cukup ketat,
penyerang bisa mengarahkan proses itu
untuk menjalankan fungsi yang tidak seharusnya.

1.2 Kenapa Bug RSC React tergolong kritis?

Celah ini berbahaya karena:

• bisa mengarah ke Remote Code Execution (RCE),

• terjadi di sisi server,

• dan tidak butuh autentikasi terlebih dulu.

Selain itu:

• banyak aplikasi modern sudah pakai RSC,

• banyak template Next.js mengaktifkan fitur ini by default,

• dan banyak developer mungkin belum sadar ada risiko besar.

Karena itu, kerentanan ini
masuk kategori kritis, bukan sekadar peringatan biasa.

---

2. Cara Kerja Bug RSC React di Balik Layar

2.1 Peran React Server Components dalam arsitektur

Pertama, kita lihat dulu peran RSC.

React Server Components dirancang untuk:

• merender sebagian UI di server,

• mengurangi beban di client,

• dan memudahkan integrasi dengan data server-side.

Untuk melakukan itu, RSC:

• mengirim “payload Flight” dari server ke client,

• dan sebaliknya, client bisa mengirim data balik ke server.

Jadi, ada protokol khusus yang berjalan di balik layar.

2.2 Di mana Bug RSC React muncul?

Celah ini muncul di bagian:

• deserialisasi payload Flight,

• pemetaan data ke modul dan fungsi di server.

Alurnya kira-kira seperti ini:

• Client mengirim payload RSC ke server.

• Server membaca payload dan mendeserialize isinya.

• Server memetakan data ke modul atau export tertentu.

• Server menjalankan fungsi yang ditentukan payload.

Masalahnya, karena validasi lemah:

• penyerang bisa memanipulasi payload,

• lalu mengarahkan eksekusi ke fungsi yang tidak diekspos,

• dan akhirnya mengeksekusi kode arbitrary di server.

2.3 Kenapa tidak butuh autentikasi?

Ini bagian yang paling mengerikan.

Kerentanan ini terjadi sebelum:

• autentikasi user,

• pengecekan token,

• atau validasi sesi.

Jadi:

• siapa pun yang bisa mengirim request ke endpoint RSC,

• berpotensi memicu celah ini,

• tanpa harus login dulu.

Karena itu, surface area-nya cukup luas,
apalagi jika endpoint RSC langsung menghadap internet.

---

3. Stack dan Versi yang Rentan Bug RSC React

3.1 React 19 dan paket terkait RSC

Biasanya, masalah ini berkaitan dengan:

• React 19.x,

• paket seperti react-server-dom-*,

• dan penggunaan RSC di server.

Jadi, kalau proyekmu:

• sudah upgrade ke React 19,

• dan memakai RSC dalam arsitektur,

kemungkinan besar kamu perlu cek changelog
dan pastikan versi yang kamu pakai
sudah mencakup patch untuk isu ini.

3.2 Next.js dengan App Router dan RSC

Di sisi lain, Next.js menjadi framework
yang sangat terdampak oleh kerentanan ini,
karena App Router mengandalkan RSC.

Umumnya, aplikasi yang rentan:

• memakai folder app/,

• memakai React Server Components,

• dan mengekspos route yang memanfaatkan RSC.

Karena itu, aplikasi Next.js modern
otomatis menjadi kandidat target serangan semacam ini.

3.3 Ringkasan dalam tabel

Untuk memudahkan, lihat ringkasan berikut:

Komponen Stack — Kondisi Risiko Bug RSC React

• React 19 — Pakai RSC, belum patch terbaru

• Next.js — App Router + RSC aktif + endpoint publik

• Server — Mengizinkan akses langsung ke endpoint RSC

• Infrastruktur — Tidak ada WAF atau filter ekstra di depan endpoint

Kalau kombinasi environment-mu mirip tabel di atas,
maka prioritas mitigasi kerentanan ini
harus masuk to-do teratas.

---

4. Dampak Bug RSC React untuk Aplikasi Produksi

4.1 Kemungkinan Remote Code Execution (RCE)

Dengan celah seperti ini, penyerang bisa:

• menjalankan perintah di server,

• membaca file sensitif,

• atau men-deploy backdoor secara diam-diam.

Selain itu, kalau server punya akses luas:

• database bisa ikut terekspos,

• sistem internal lain bisa tersentuh,

• dan kredensial lain bisa dicuri.

Jadi, risiko utamanya bukan hanya crash,
melainkan pengambilalihan penuh environment.

4.2 Dampak ke data dan pengguna

Dari sisi data, kerentanan ini berpotensi menyebabkan:

• kebocoran data pelanggan,

• manipulasi data aplikasi,

• atau injeksi konten berbahaya ke response.

Selain itu, dari sisi user:

• mereka bisa menerima konten yang sudah diubah,

• atau diarahkan ke halaman lain yang berbahaya.

Pada akhirnya, kepercayaan user
bisa turun drastis hanya karena satu celah seperti ini.

4.3 Dampak jangka panjang ke tim dan bisnis

Untuk tim, situasi ini berarti:

• kerja ekstra untuk incident response,

• audit log dan forensic,

• serta refactor dan patching di banyak repositori.

Untuk bisnis:

• downtime bisa meningkat,

• reputasi bisa turun,

• dan biaya pemulihan bisa cukup besar.

Karena itu, mengabaikan masalah semacam ini
bisa jauh lebih mahal
daripada meluangkan waktu untuk patch sekarang.

---

5. Menentukan Apakah Aplikasi Kamu Terdampak Bug RSC React

5.1 Audit dependency dan versi framework

Langkah pertama, lakukan audit dependency:

• cek package.json untuk versi React dan Next.js,

• pastikan apakah React 19 dan RSC dipakai,

• dan cek apakah rilis yang kamu pakai
  sudah mengatasi isu ini.

Selain itu, cek juga:

• apakah ada paket react-server-dom-* di project,

• dan bagaimana konfigurasi RSC di app-mu.

5.2 Review penggunaan RSC dan server actions

Berikutnya, review codebase:

• apakah banyak komponen yang ditandai sebagai server components,

• apakah kamu memanfaatkan server actions,

• dan apakah ada route yang mengandalkan RSC.

Jika jawabannya “ya” untuk beberapa poin di atas,
maka kemungkinan efek kerentanan ini ke proyekmu cukup besar.

5.3 Cek endpoint publik dan arsitektur jaringan

Selain versi dan codebase,
kamu juga perlu melihat arsitektur jaringan.

Tanyakan:

• apakah endpoint RSC bisa diakses langsung dari internet,

• apakah ada WAF di depan aplikasi,

• dan apakah ada rate limit atau filter request tambahan.

Dengan begitu, kamu bisa mengukur
seberapa mudah celah ini
bisa dieksploitasi dari luar.

---

6. Strategi Mitigasi Bug RSC React di React dan Next.js

6.1 Patch dan upgrade sebagai langkah utama

Langkah paling penting:

• upgrade React ke versi yang sudah memperbaiki kerentanan ini,

• upgrade Next.js ke rilis yang sudah mendapat patch RSC.

Setelah itu:

• rebuild aplikasi,

• redeploy,

• dan tes fungsi utama.

Selain itu, tulis catatan internal:

• versi sebelum patch,

• versi sesudah patch,

• dan langkah upgrade yang sudah dilakukan.

6.2 Gunakan WAF dan filtering request

Sambil patch berjalan di semua environment,
kamu bisa menambah lapisan proteksi.

Misalnya:

• memasang Web Application Firewall (WAF),

• menambah rule untuk memblok payload aneh,

• dan membatasi HTTP method yang diizinkan.

Dengan cara ini:

• permukaan serangan tidak langsung “terbuka lebar”,

• karena ada filter ekstra yang menyaring request.

Namun, ingat:
WAF hanya mitigasi sementara,
bukan solusi inti.

6.3 Hardening environment server

Selain patch dan WAF,
lakukan juga hardening server:

• jalankan app di container dengan privilege minimal,

• pisahkan secret ke secret store,

• batasi outbound network dari container.

Karena itu, kalau suatu hari
kerentanan semacam ini atau bug lain sempat dieksploitasi,
kerusakannya masih bisa dibatasi.

---

7. Praktik Aman Menggunakan RSC Setelah Bug RSC React

7.1 Desain surface area dengan lebih sadar

Setelah paham risikonya,
cara desain arsitektur juga sebaiknya ikut berubah.

Misalnya:

• jangan ekspos semua endpoint yang berhubungan dengan RSC,

• gunakan gateway atau reverse proxy sebagai perisai,

• dan kelompokkan endpoint yang benar-benar perlu publik.

Selain itu, dokumentasikan:

• endpoint mana yang memakai RSC,

• dan lapisan keamanan apa yang melindunginya.

7.2 Disiplin validasi input dan sesi

Walaupun akar masalah ada di framework,
disiplin validasi tetap penting.

Jadi:

• validasi semua input dari client,

• batasi ukuran dan bentuk payload,

• dan pastikan autentikasi diterapkan di layer lain.

Selain itu,
disiplin ini akan membantu
mengurangi efek bug lain di masa depan.

7.3 Observability untuk mendeteksi anomali

Setelah itu, jangan lupa observability.

Kamu bisa:

• log semua request ke endpoint sensitif,

• pasang alert untuk pola request yang tidak biasa,

• dan rutin cek log untuk aktivitas aneh.

Dengan observability yang baik,
kalau ada eksploitasi terhadap celah seperti ini
atau bug lain,
tim bisa respons lebih cepat.

---

8. Kesalahan Umum Saat Menangani Bug RSC React

8.1 Meremehkan karena “belum ada insiden”

Salah satu kesalahan terbesar adalah:

“Belum ada tanda serangan, berarti aman.”

Padahal:

• serangan bisa dilakukan dengan sangat sunyi,

• penyerang bisa menunggu moment yang tepat,

• dan dampak baru terasa jauh belakangan.

Karena itu, jangan jadikan ketiadaan gejala
sebagai alasan untuk diam.

8.2 Hanya mengandalkan scanner otomatis

Scanner otomatis memang berguna,
namun hanya mengandalkannya juga berbahaya.

Kadang:

• signature belum lengkap,

• rule belum update,

• atau pattern serangan terlalu baru.

Jadi, selain scanner:

• baca juga advisory resmi,

• lakukan code review terarah,

• dan diskusikan kerentanan ini
  di internal tim secara eksplisit.

8.3 Menunda patch karena takut breaking changes

Ini juga sangat sering terjadi.

Banyak tim berpikir:

“Takut upgrade, nanti aplikasi rusak.”

Namun, di kasus seperti ini:

• risikonya RCE di server,

• dampaknya bisa ke data dan user,

• dan recovery cost bisa sangat tinggi.

Jadi, lebih baik:

• patch cepat tapi terukur,

• tes rapi di staging,

• dan rollout bertahap di production.

---

9. Tips Praktis untuk Tim Dev, DevOps, dan Security

9.1 Untuk developer React / Next.js

Beberapa langkah yang bisa kamu lakukan sekarang:

• list semua projek yang pakai React 19 dan App Router,

• tandai mana yang memakai RSC dan server actions,

• dan cek apakah sudah menerapkan patch keamanan terbaru.

Selain itu:

• update template internal ke versi aman,

• dan buat checklist keamanan khusus untuk RSC.

9.2 Untuk DevOps / SRE

Dari sisi DevOps dan SRE:

• pastikan pipeline CI/CD bisa menangani upgrade cepat,

• siapkan rollback plan kalau upgrade bermasalah,

• dan pasang monitoring ekstra untuk endpoint RSC.

Selain itu, koordinasikan:

• siapa yang bertanggung jawab patch,

• siapa yang memantau log insiden,

• dan siapa yang mengurus komunikasi internal.

9.3 Untuk tim security dan manajemen

Untuk security dan manajemen:

• masukkan isu ini ke daftar risiko formal,

• prioritaskan patch di aplikasi high-impact,

• dan alokasikan waktu khusus untuk perbaikan.

Selain itu, siapkan juga:

• prosedur incident response,

• dan rencana komunikasi jika insiden benar-benar terjadi.

---

10. FAQ Singkat tentang Bug RSC React

10.1 Apakah semua aplikasi React terkena Bug RSC React?

Tidak semua,
namun aplikasi yang:

• memakai React 19,

• memanfaatkan RSC,

• dan berjalan di server,

lebih berisiko terhadap kerentanan ini.

10.2 Kalau app-ku hanya client-side, bagaimana?

Kalau app-mu:

• murni client-side SPA,

• tidak memakai RSC,

• dan tidak ada server functions,

risiko dari celah ini jauh lebih kecil.
Namun, tetap cek dependency
dan ikuti best practice keamanan lain.

10.3 Apakah WAF saja cukup?

Tidak.

WAF bagus sebagai lapisan tambahan,
tetapi masalah utama ada di level framework.
Jadi, patch tetap wajib.

10.4 Apa langkah pertama yang paling realistis?

Langkah pertama yang paling realistis:

• audit versi React dan Next.js,

• cek apakah kamu memakai RSC,

• upgrade ke versi yang sudah mengatasi isu ini.

Setelah itu, baru susun langkah lanjutan
seperti hardening dan observability.

---

11. Penutup: Kenapa Kamu Tidak Bisa Mengabaikan Bug RSC React

Sebagai penutup,
kerentanan di RSC ini adalah pengingat keras
bahwa fitur baru yang canggih
selalu datang bersama risiko baru.

Karena itu:

• jangan anggap enteng celah di level framework,

• jangan tunda patch hanya karena “app masih jalan”,

• dan jangan lupa dokumentasikan langkah yang sudah kamu ambil.