Next.js Kena RCE Lagi, dan Kenapa Kami Pindah ke TanStack

Minggu ini lumayan ramai soal security issue. Ada php-shell, ada RCE di Node.js (tepatnya Next.js), ada juga RCE di GitLab. Untuk yang PHP saya tidak terlalu ambil pusing, karena hampir tidak ada klien atau proyek kami yang dibangun di atas PHP.

GitLab sebenarnya juga serius. CVE-2026–97229 ini integer overflow di CI/CD Regular Expression Compiler, skornya CVSS 10, dan sudah dipatch di versi 19.4.2, 19.3.5 dan 19.2.8 sejak 12 Oktober 2026. PoC-nya juga sudah beredar. Jadi buat teman-teman yang menggunakan GitLab self-managed, sebaiknya segera upgrade.

Tapi yang bikin saya agak was-was itu Next.js. Hampir semua frontend kami dibangun di atas Next.js, dan kami punya sejarah yang kurang enak dengan framework ini.

React2Shell

React2Shell. CVE-2025–55182. Celahnya diumumkan oleh Meta dan Vercel tanggal 3 Desember 2025, dengan skor CVSS 10. Waktu itu Next.js sempat mendapatkan CVE sendiri, CVE-2025–66478, tapi akhirnya dibatalkan karena ternyata celahnya sama persis dengan yang ada di React. Jadi kalau teman-teman menemukan dua nomor ini di berbagai artikel, sebenarnya itu celah yang sama.

Supaya gampang membayangkannya, React Server Components (RSC) itu memungkinkan sebagian komponen React dirender di server, lalu hasilnya dikirim ke browser dalam format khusus bernama Flight. Saat browser memanggil Server Function atau Server Action, datanya dikirim ke server dalam format yang mirip, lalu server membongkarnya (deserialize) menjadi objek JavaScript.

Di bagian membongkar inilah masalahnya. Penyerang cukup mengirim satu HTTP request yang dipasang khusus ke endpoint Server Function, dan saat React men-deserialize-nya, kode penyerang ikut jalan di server. Tidak perlu login, tidak perlu akun. Dari situ penyerang bisa memanggil fungsi bawaan Node.js seperti child_process.execSync untuk menjalankan perintah shell. Makanya namanya React2Shell, dari React langsung ke shell.

Yang terdampak adalah React 19.0, 19.1.0, 19.1.1 dan 19.2.0 pada paket react-server-dom-webpack, react-server-dom-parcel dan react-server-dom-turbopack. Next.js dengan App Router otomatis ikut terkena karena memakai paket-paket ini di dalamnya, dan konfigurasi default-nya pun sudah rentan.

Eksploitasinya juga cepat sekali. Serangan mulai muncul hampir segera setelah celahnya diumumkan, dan CISA memasukkan CVE-2025–55182 ke katalog Known Exploited Vulnerabilities. Jumlah PoC exploit yang beredar bahkan disebut hampir menyentuh 100, angka yang jarang sekali terjadi. Belum selesai di situ, riset lanjutan terhadap RSC menemukan celah-celah baru: CVE-2025–55184 dan CVE-2025–67779 untuk DoS, dengan yang terakhir dianggap sebagai bypass dari patch React2Shell yang pertama, serta CVE-2025–55183 yang bisa membocorkan sebagian source code. Jadi patch-nya pun harus diulang lebih dari sekali.

Dan kami termasuk yang kena. Akhir 2025 itu server kami dibobol lewat celah ini.

Waktu itu kami menambalnya sambil di perjalanan ke PyCon Indonesia 2025 di Jakarta. Saya berangkat bareng Bang Bus, dan kebetulan FE waktu itu memang dipegang oleh Bang Bus. Jadi sepanjang jalan kami sibuk cek versi, update dependency, build ulang, deploy, lalu cek apa saja yang sempat disentuh. Bukan pengalaman perjalanan yang ingin saya ulangi, wkwk.

Advisory 14 Oktober 2026

Minggu lalu Next.js merilis security update di luar jadwal. Patch-nya tersedia di v16.4.1 (Active LTS) dan v15.5.28 (Maintenance LTS). Isinya ada 3 celah:

RCE di fungsi use cache (Critical, GHSA-673q-mjm6-r5xr). Terjadi di aplikasi App Router dengan Cache Components, saat fungsi use cache mengembalikan beberapa typed array, misalnya Uint8Array. Celah ini punya advisory pasangan di React (GHSA-xqc2-xf4c-x3h3). Polanya mirip React2Shell, masalahnya ada di jalur serialisasi data antara React dan server.
RCE di Image Optimization lewat SVG (Critical, CVE-2026–96889). Asalnya dari bug memori di library upstream yang dipakai untuk optimasi gambar, yaitu sharp, dan berdampak kalau Next.js jalan di Linux berbasis glibc. Ubuntu dan Debian termasuk, yang justru paling umum dipakai di VPS.
DoS lewat Server Actions (High, GHSA-p3m5–59mp-jv5r). Request khusus ke aplikasi App Router yang punya minimal satu Server Action membuat CPU naik dan memblokir request lain di proses yang sama. Aplikasi Pages Router atau yang tidak memakai Server Actions tidak terkena dampak.

Untuk kami yang menjalankan Next.js di VPS dengan PM2, nomor 3 ini cukup terasa. Kalau instance-nya sedikit, satu proses macet saja sudah bisa bikin situs tidak bisa diakses.

Kalau diperhatikan, dua dari tiga celah ini, dan React2Shell sebelumnya, ada di area yang sama, batas antara React dan server, yang semuanya diurus otomatis oleh framework.

Pindah ke TanStack

Setelah pengalaman di tahun 2025 dan ada celah terbaru(sebelum kena tentunnya), kami memutuskan untuk tidak lanjut di Next.js. Ada sekitar 3 web dan app yang masih berjalan di atas Next.js, dan semuanya kami tulis ulang diatas TanStack.

TanStack sendiri adalah kumpulan library open source untuk aplikasi web, seperti TanStack Query untuk data fetching dan caching, TanStack Router untuk routing yang type-safe, TanStack Table, TanStack Form, dan lain-lain. Di atasnya ada TanStack Start, framework full-stack yang dibangun di atas TanStack Router. Start menambahkan SSR, streaming, server functions yang type-safe, server routes dan middleware. Versi 1.0-nya baru rilis tanggal 13 Oktober 2026 kemarin.

TanStack menyebut Start ini client-first, server-capable. Kita menulis aplikasi React seperti biasa, dan jika butuh kode yang jalan di server, kita buat sendiri secara eksplisit lewat createServerFn.

Kenapa TanStack? Ada beberapa alasan:

Batas server lebih jelas. Di TanStack Start, setiap pemanggilan ke server harus dibuat sebagai RPC eksplisit lewat createServerFn, lengkap dengan validasi input. Kami bisa lihat endpoint mana saja yang terbuka, tidak ada yang jalan secara ajaib.
RSC sifatnya opsional. Next.js App Router berdiri di atas React Server Components, sementara di TanStack Start dukungan RSC masih di balik API eksperimental. Kalau tidak butuh, ya tidak kami jalankan.
Cocok dengan arsitektur kami. Logika bisnis dan data sudah ada di backend Go/Rust, frontend kami pada dasarnya cuma klien yang memanggil API. Model client-first ini cocok dengan cara kerja kami.
Type safety dari route sampai komponen. Tipe TypeScript berjalan dari route, loader, server function, sampai komponen. Ini penting waktu porting dibantu AI, karena kesalahan AI lebih cepat ketahuan oleh compiler.
Ramah untuk AI. Paket npm TanStack Start sudah menyertakan file SKILL.md untuk topik seperti server functions, middleware dan deployment, jadi AI lebih gampang mengikuti pola resminya.
Tidak terikat ke Vercel. Aplikasi kami berjalan sebagai pod di Kubernetes, dan TanStack Start yang berbasis Vite dan Nitro bisa di-deploy di mana saja.

Lalu pertanyaannya, kalau dari awal kami pakai TanStack, apakah kami tetap kena React2Shell?

Jawabannya, waktu itu tidak. React2Shell ada di paket React Server Components (react-server-dom-webpack, react-server-dom-parcel dan react-server-dom-turbopack), dan framework yang terdampak adalah yang memakai RSC, seperti Next.js, RedwoodSDK, React Router RSC preview, serta plugin RSC untuk Vite dan Parcel. Celah ini cuma mengenai React 19 yang memakai RSC. TanStack Start saat itu belum memakai RSC sama sekali, jadi jalur serangannya memang tidak ada.

Tapi sekarang ceritanya sedikit beda. Sejak April 2026 TanStack Start sudah mendukung RSC, dan di sana RSC itu ya React Flight stream juga. Sementara React2Shell sendiri asalnya dari deserialisasi yang tidak aman di protokol Flight. Artinya, kalau kami menyalakan RSC di TanStack, kami memakai mesin yang sama, dan celah sejenis di React upstream bisa ikut terbawa.

Jadi yang membuat kami aman dari kelas celah seperti React2Shell bukan nama frameworknya, tapi keputusan untuk tidak memakai RSC. Untuk sekarang, RSC tidak kami jalankan.

Tapi saya juga tidak mau naif. [@tanstack/react-start](https://blog.logrocket.com/?p=214242) juga pernah kena celah DoS, dan tim TanStack sendiri mengingatkan supaya server functions tetap diperlakukan seperti API biasa diautentikasi, divalidasi, dan dependency-nya rajin di-update. Jadi tujuan kami lebih ke memperkecil area yang harus dijaga, dan membuatnya lebih termapping.

Rewrite dengan AI

Menulis ulang 3 aplikasi itu pekerjaan yang lumayan, jadi sebagian besar porting kami kerjakan dengan bantuan AI. Masalahnya, jika AI dibiarkan bebas, hasilnya sering terlihat benar tapi tidak konsisten antar halaman dan susah diaudit.

Caranya, kami membuat aturan yang lumayan ketat untuk AI, struktur folder, pola routing, cara memanggil API, tidak boleh menambah dependency sembarangan, dan bagian mana yang boleh atau tidak boleh disentuh. Aturan ini digunakan di setiap sesi supaya hasilnya seragam.

Playwright

Satu bagian yang tidak kami serahkan ke AI adalah testing. Test Playwright kami tulis manual. Alasannya sederhana, kalau kode dan test-nya ditulis oleh AI yang sama, test-nya cenderung cuma membuktikan apa yang AI anggap benar.

Test ini kami perlakukan seperti kontrak. Isinya perilaku aplikasi lama dari sisi pengguna, seperti login, alur utama, form dan navigasi. Versi TanStack baru dianggap selesai jika semua test itu lolos.

Paralel, 3 Hari

Ketiga web dan app ini kami kerjakan secara paralel, tidak satu per satu. Hasilnya, semuanya selesai dalam 3 hari.

Jujur saya sendiri awalnya tidak menyangka bisa secepat itu. Tapi jika dipikir-pikir lagi, paralel ini memungkinkan karena dua hal tadi. Aturan untuk AI-nya sama di semua proyek, jadi hasil porting dari satu aplikasi ke aplikasi lain polanya seragam dan gampang di-review. Lalu test Playwright yang ditulis manual jadi patokan yang jelas, sehingga kami tidak perlu menebak-nebak apakah sebuah halaman sudah benar atau belum. Selama test-nya pass kami lanjut ke halaman berikutnya.

Penutup.

Setelah React2Shell, kami sebenarnya bisa saja terus mengikuti ritme yang sama: advisory keluar, cek versi, patch, deploy, lalu menunggu advisory berikutnya. Tapi dua kali kena di area yang sama membuat saya berpikir ulang. Daripada terus mengejar patch di bagian yang tidak benar-benar kami pegang, lebih baik kami pindah ke stack yang batas server-nya bisa kami lihat dan atur sendiri.

Apakah TanStack menjamin kami aman? Tidak juga. Celah akan selalu ada, di framework mana pun. Yang berubah adalah area yang harus kami jaga jadi lebih kecil, RSC tidak kami jalankan, dan setiap endpoint ke server kami tulis sendiri.

Pelajaran lain yang saya dapat dari migrasi ini adalah soal AI. AI sangat membantu untuk kecepatan, sampai 3 aplikasi bisa selesai dalam 3 hari. Tapi kecepatan itu baru berguna jika ada pagarnya: aturan yang ketat, dan test yang ditulis oleh manusia. Tanpa itu, saya rasa kami hanya akan memindahkan masalah dari satu framework ke framework lain.

Semoga tulisan ini bermanfaat, terutama untuk teman-teman yang masih menimbang apakah perlu bertahan di Next.js atau pindah. Jika ada yang punya pengalaman serupa, saya senang sekali jika bisa ngobrol dan bertukar cerita.