HovioneTechnology – Peretas Tiongkok bergerak sangat cepat memanfaatkan kerentanan baru React2Shell (CVE-2025-55182).
Kerentanan ini menyerang React Server Components (RSC) dan Next.js,
dan membuka peluang remote code execution (RCE) tanpa autentikasi.
Jadi, kalau kamu jalankan aplikasi React 19 atau Next.js modern di server,
risiko ini langsung menyentuh stack kamu.
Selain itu, threat intel dari beberapa vendor keamanan melaporkan
aktivitas eksploitasi nyata dari beberapa grup China-nexus
hanya beberapa jam setelah kerentanan diumumkan.
Karena itu, artikel ini akan membahas:
-
bagaimana React2Shell bekerja,
-
bagaimana peretas Tiongkok mengeksploitasi celah ini,
-
dan apa langkah teknis yang bisa kamu ambil hari ini juga
untuk mengurangi risiko di environment-mu.
1. Gambaran React2Shell dan Peretas Tiongkok
1.1 Apa itu React2Shell (CVE-2025-55182)?
Secara singkat, React2Shell adalah kerentanan RCE kritis (CVSS 10.0)
di React Server Components (RSC) Flight protocol.
Bug ini muncul karena proses deserialisasi payload RSC di server
tidak cukup aman.
Jadi, penyerang cukup mengirim HTTP request yang sudah mereka crafting.
Server lalu memproses payload itu sebagai data RSC.
Namun, karena validasinya lemah, data itu bisa mengarahkan eksekusi kode
ke jalur yang seharusnya tidak bisa diakses.
1.2 Kenapa React2Shell begitu berbahaya?
React2Shell berbahaya karena beberapa alasan sekaligus:
-
RCE tanpa autentikasi: penyerang tidak perlu login.
-
Default-config vulnerable: Next.js standar dengan App Router
sudah cukup untuk menjadi target. -
Dipakai luas: React 19 dan Next.js 15/16 sudah ada di banyak stack modern.
-
Eksploitasi simpel: cukup satu HTTP request ter-craft dengan baik.
Karena itu, organisasi yang merasa “hanya pakai Next.js standar”
sebenarnya tetap berada di jalur tembak.
1.3 Peretas Tiongkok dalam gelombang eksploitasi awal
Beberapa laporan threat intel menyebutkan
banyak peretas Tiongkok / China-nexus threat groups
segera memasukkan React2Shell ke dalam infrastruktur scanning mereka,
bahkan dalam hitungan jam setelah publikasi PoC.
Mereka:
-
memakai botnet dan infrastruktur anonymization skala besar,
-
memindai internet untuk endpoint RSC / Next.js,
-
lalu mencoba berbagai variasi payload exploit React2Shell.
Jadi, jendela waktu antara “kerentanan diumumkan”
dan “servermu dipindai” sekarang sangat sempit.
2. Cara Kerja React2Shell di Tingkat Teknis
2.1 Peran React Server Components dan Flight protocol
React Server Components:
-
merender sebagian UI di server,
-
mengirim “Flight payload” ke client,
-
dan mengizinkan pemanggilan Server Functions
dari kode client.
Untuk itu, React memakai protokol khusus
yang meng-encode dan men-deserialize struktur komponen dan referensi fungsi.
2.2 Di mana bug React2Shell muncul?
Masalah inti React2Shell ada di:
-
cara server menerima payload Flight,
-
lalu cara server melakukan deserialisasi payload tersebut,
-
dan cara payload menentukan fungsi mana yang akan dipanggil.
Dengan kata lain:
-
Client (atau penyerang) mengirim payload RSC ke endpoint Server Function.
-
Server membaca payload dan melakukan deserialisasi.
-
Logika mapping payload ke modul/fungsi berjalan.
-
Server mengeksekusi fungsi sesuai referensi dalam payload.
Bug-nya: deserialisasi ini terlalu percaya pada isi payload.
Jadi, penyerang bisa menyuntik nilai yang mengarahkan eksekusi
ke path kode yang seharusnya tidak terekspos.
2.3 React murni vs Next.js: siapa yang kena?
Secara umum:
-
React client-side saja tidak terdampak,
karena tidak memakai RSC Flight protocol di server. -
Stack yang memakai React Server Components
melalui paketreact-server-dom-*terdampak. -
Next.js dengan App Router yang mengaktifkan RSC
ikut terdampak karena menyertakan implementasi Flight protocol.
Jadi, kalau kamu hanya render React di browser,
risiko React2Shell relatif kecil.
Namun, kalau kamu pakai Next.js modern di server,
maka kemungkinan besar kamu masuk scope kerentanan ini.
3. Peretas Tiongkok dan Pola Eksploitasi React2Shell
3.1 Bagaimana peretas Tiongkok memulai eksploitasi
Laporan beberapa vendor menyebut
peretas Tiongkok langsung memanfaatkan PoC React2Shell
begitu contoh exploit publik muncul.
Biasanya mereka:
-
update toolkit scanning otomatis,
-
tambahkan modul React2Shell ke pipeline scanning CVE lain,
-
lalu jalankan kampanye scanning global secara paralel.
Jadi, React2Shell muncul bukan sebagai serangan tunggal,
melainkan sebagai salah satu CVE
di dalam “paket eksploitasi massal” yang sama.
3.2 Target dan infrastruktur serangan
Sebagian besar aktivitas terlihat
berasal dari infrastruktur yang sebelumnya
sudah terkait dengan beberapa grup China-nexus,
misalnya kelompok yang fokus pada:
-
sektor finansial dan e-commerce,
-
layanan cloud dan SaaS,
-
universitas dan institusi riset,
-
serta organisasi pemerintah di Asia dan Amerika Latin.
Mereka memanfaatkan:
-
ASN dan hosting murah,
-
jaringan proxy dan VPN masif,
-
serta IP yang terus berganti,
sehingga attribution detail ke satu grup tertentu
menjadi sangat sulit.
3.3 Rantai serangan Peretas Tiongkok: dari React2Shell ke cloud takeover
Setelah mendapat foothold via React2Shell,
peretas biasanya tidak berhenti di sana.
Beberapa laporan teknis menyebut
mereka kemudian:
-
mengumpulkan cloud credentials (AWS, GCP, Azure),
-
menanam cryptominer,
-
berjalan lateral ke service lain,
-
dan mencoba mengakses data sensitif internal.
Karena itu, React2Shell sebaiknya kamu anggap
sebagai pintu awal ke kompromi yang jauh lebih luas,
bukan hanya bug di satu endpoint.
4. Dampak Bisnis dan Risiko Operasional
4.1 Remote Code Execution dan pengambilalihan server
RCE tanpa autentikasi berarti penyerang:
-
bisa menjalankan perintah di server,
-
bisa membaca file konfigurasi dan secret,
-
bisa men-deploy backdoor secara senyap.
Jadi, konsekuensinya jarang berhenti
di “service down sebentar”.
Serangan bisa berkembang menjadi
pengambilalihan penuh environment.
4.2 Cloud credential theft dan lateral movement
Karena banyak aplikasi React / Next.js
berjalan di container atau VM di cloud,
maka kompromi server sering berarti:
-
akses ke instance metadata (misalnya creds IAM),
-
akses ke secret store,
-
lalu akses ke service lain di VPC yang sama.
Akhirnya, serangan yang mulai di satu web app
bisa meluas ke:
-
database core,
-
message queue,
-
bahkan cluster Kubernetes lain.
4.3 Reputasi, regulasi, dan kontrak bisnis
Selain dampak teknis,
insiden berbasis React2Shell yang sampai ke publik
bisa memicu:
-
kewajiban notifikasi regulator,
-
audit compliance yang lebih agresif,
-
renegosiasi kontrak dengan pelanggan enterprise.
Karena itu, patch cepat
jauh lebih murah dibanding recovery jangka panjang.
5. Memetakan Permukaan Serangan di Stack Kamu
5.1 Audit framework, library, dan versi
Langkah pertama: inventarisasi dependency.
Kamu bisa mulai dengan:
-
cek
package.jsonuntuk React 19 dan Next.js 15/16, -
cari paket
react-server-dom-*, -
identifikasi service yang memakai RSC / Server Functions.
Lalu, catat:
-
nama app,
-
versi framework,
-
environment (prod / staging / dev),
-
dan eksposur internetnya.
5.2 Identifikasi endpoint RSC dan Server Function
Berikutnya, kamu perlu mapping permukaan serangan:
-
route / API yang memakai RSC,
-
endpoint Server Function yang diekspos,
-
domain atau path yang langsung bisa diakses publik.
Semakin banyak endpoint yang bersifat publik,
semakin besar peluang serangan React2Shell
dari internet terbuka.
5.3 Menilai eksposur internet dan kontrol perimeter
Setelah itu, lihat arsitektur jaringan:
-
apakah semua app Next.js langsung menghadap internet,
-
apakah ada WAF di depannya,
-
apakah ada rate limit atau IP blocking sederhana.
Dengan data ini, kamu bisa memprioritaskan:
-
mana yang harus patch hari ini,
-
mana yang bisa masuk batch berikutnya,
-
dan mana yang cukup kamu lindungi sementara
dengan kontrol perimeter tambahan.
6. Strategi Patch dan Hardening untuk React2Shell
6.1 Upgrade React Server Components dan library terkait
Vendor sudah merilis versi patch
untuk paket React Server Components.
Umumnya, langkahnya:
-
upgrade
react-server-dom-*ke versi patch
(misal 19.0.1 / 19.1.2 / 19.2.1 atau setara), -
rebuild image / artefak,
-
redeploy ke semua environment.
Selain itu, dokumentasikan upgrade:
-
versi lama,
-
versi baru,
-
dan service mana saja yang terdampak.
6.2 Patch Next.js dan framework turunan
Untuk Next.js, vendor juga merilis
versi yang menyertakan RSC yang sudah diperbaiki.
Jadi, kamu perlu:
-
upgrade Next.js ke versi patch (misal seri 15.x / 16.x tertentu),
-
memastikan build pipeline memakai versi yang sama,
-
menguji App Router dan route dinamis
setelah upgrade.
Di beberapa kasus,
upgrade ini membawa perubahan kecil di behaviour,
jadi regression test tetap penting.
6.3 Validasi patch dan konfirmasi remediation
Setelah patch, jangan berhenti di “build sukses”.
Kamu perlu:
-
jalankan vulnerability scanner yang sudah mengerti React2Shell,
-
pastikan tidak ada lagi versi lama di container image,
-
cek log runtime untuk melihat apakah masih ada eksploitasi yang sukses.
Tabel ringkas di bawah bisa membantu kamu
melihat status aplikasi:
| Item | Pertanyaan Kunci | Status |
|---|---|---|
| Framework | Pakai React RSC / Next.js App Router? | |
| Versi | Masih di versi rentan atau sudah patch? | |
| Eksposur | Endpoint RSC bisa diakses publik? | |
| Proteksi tambahan | Ada WAF / rate limit di depan app? | |
| Validasi setelah patch | Scanner / log menunjukkan percobaan exploit? |
Isi status sendiri sesuai environment-mu,
lalu jadikan tabel ini sebagai checklist tim.
7. Lapisan Proteksi Tambahan: WAF, Deteksi, Logging
7.1 WAF rules sebagai tameng sementara
Patch tetap solusi utama.
Namun, sambil patch berjalan,
kamu bisa menambahkan WAF rules
untuk memblokir pola payload React2Shell.
Misalnya:
-
blok request ke endpoint RSC yang mencurigakan,
-
batasi size payload tertentu,
-
dan log semua request yang cocok rule React2Shell.
Ini memang tidak menutup semua celah,
namun cukup membantu menurunkan risiko eksploitasi massal.
7.2 Deteksi perilaku di runtime
Selain WAF, kamu juga perlu runtime detection.
Kamu bisa:
-
pantau proses yang tiba-tiba menjalankan shell,
-
pantau percobaan akses ke metadata service,
-
pantau anomali CPU / jaringan yang mengarah ke cryptomining.
Dengan begitu, kamu bisa menangkap
eksploitasi React2Shell yang lolos dari WAF.
7.3 Logging, observability, dan incident response
Terakhir, kamu harus memastikan:
-
log web server cukup detail,
-
log aplikasi mencatat error dan stack trace penting,
-
log infra (container / VM) terkumpul di satu tempat.
Selain itu, siapkan playbook singkat:
-
siapa yang on-call,
-
langkah pertama ketika deteksi RCE,
-
siapa yang memutuskan isolasi service.
Dengan playbook ini,
respon terhadap serangan peretas Tiongkok
bisa berjalan lebih rapi dan tidak panik.
8. Tips Praktis untuk Dev, DevSecOps, dan Security
8.1 Untuk tim dev React / Next.js
-
Tag semua repo yang memakai React 19 / Next.js App Router.
-
Tambahkan checklist React2Shell di PR template.
-
Diskusikan pattern penggunaan RSC dan Server Functions
supaya permukaan serangan tidak terlalu lebar.
8.2 Untuk tim platform / DevOps / SRE Peretas Tiongkok
-
Pastikan pipeline CI/CD mendukung upgrade cepat.
-
Simpan image lama untuk rollback,
namun tandai sebagai “vulnerable”. -
Tambahkan job scanning library
untuk mendeteksi versi rentan di masa depan.
8.3 Untuk tim security / manajemen teknis
-
Masukkan React2Shell ke daftar risiko formal.
-
Prioritaskan patch untuk sistem ber-internet dan high-impact.
-
Alokasikan waktu sprint khusus
untuk hardening dan observability.
Dengan koordinasi tiga sisi ini,
respon terhadap peretas Tiongkok
menjadi jauh lebih terstruktur.
9. Kesalahan Umum Saat Menghadapi React2Shell
9.1 Menunda patch karena takut breaking change
Banyak tim menunda upgrade
karena khawatir aplikasi rusak.
Namun, di kasus React2Shell,
risiko RCE dan kompromi cloud
biasanya jauh lebih mahal
dibanding effort regression test.
9.2 Hanya mengandalkan vendor cloud atau framework
Sebagian tim merasa aman
karena sudah memakai cloud besar
atau framework populer.
Padahal, React2Shell terutama
mengenai cara kamu menjalankan framework itu
di environment-mu sendiri.
Jadi, kamu tetap perlu:
-
audit sendiri,
-
patch sendiri,
-
dan memantau log sendiri.
9.3 Menganggap serangan peretas tiongkok hanya untuk perusahaan besar
Laporan threat intel menunjukkan
toolkit eksploitasi milik peretas Tiongkok
bekerja secara massal,
bukan manual selektif per target.
Jadi, startup kecil dengan Next.js di VPS biasa
tetap bisa kena scan dan exploit,
selama port terbuka dan versi rentan.
10. FAQ: React2Shell dan Peretas Tiongkok
10.1 Apakah semua aplikasi React terdampak React2Shell?
Tidak.
Aplikasi yang hanya render React di browser
dan tidak memakai React Server Components
biasanya tidak berada dalam scope React2Shell.
10.2 Bagaimana saya tahu aplikasi saya memakai RSC?
Cek:
-
penggunaan App Router di Next.js,
-
dependency
react-server-dom-*, -
konfigurasi server yang mendukung Server Functions.
Kalau tiga hal ini muncul,
kamu perlu mengasumsikan ada risiko React2Shell.
10.3 Apakah patch saja cukup tanpa WAF dan deteksi?
Patch menutup celah inti.
Namun, WAF dan deteksi runtime
tetap penting sebagai lini pertahanan tambahan,
apalagi kalau kamu mengelola banyak service sekaligus.
10.4 Apakah serangan ini spesifik ke peretas Tiongkok saja?
Saat ini, banyak laporan menyebut
eksploitasi awal datang dari grup China-nexus.
Namun, setelah PoC publik beredar,
grup lain kemungkinan akan ikut memakai eksploit yang sama.
10.5 Apa langkah paling realistis yang bisa saya lakukan hari ini untuk menghindar Peretas Tiongkok?
-
Audit semua app React / Next.js di environment-mu.
-
Prioritaskan patch untuk yang rentan dan ber-internet.
-
Tambahkan WAF rule sementara,
terutama di depan app Next.js. -
Aktifkan logging dan pantau anomali proses di server.
11. Penutup: Dari React2Shell ke Maturity KeamananPeretas TiongkokPeretas Tiongkok
Sebagai penutup,
insiden React2Shell dan eksploitasi oleh peretas Tiongkok
menggambarkan realita baru:
-
jendela patch sangat pendek,
-
PoC cepat berubah menjadi serangan nyata,
-
dan stack JavaScript modern
sekarang berada di garis depan serangan RCE.
Karena itu, langkah yang masuk akal sekarang:
-
jangan tunda audit dan patch,
-
kombinasikan patch dengan WAF dan deteksi runtime,
-
jadikan pelajaran React2Shell
sebagai pemicu peningkatan maturity keamanan aplikasi web di tim kamu.