Celah Bypass Middleware Next.js CVE-2025-29927 dan Solusinya

Bayangkan dashboard admin tokomu dibangun dengan Next.js dan berjalan di VPS sendiri. Halaman /admin dilindungi middleware: kalau belum login, pengunjung dialihkan ke halaman masuk. Semuanya terlihat rapi, sampai ada yang mengirim permintaan dengan satu header tambahan dan langsung melihat isi dashboard tanpa login.

Itulah inti CVE-2025-29927. Celah ini memungkinkan penyerang melewati middleware Next.js sepenuhnya dengan menambahkan header internal x-middleware-subrequest. Advisori resmi di GitHub memberi skor CVSS 9.1 (kritis) dan mengategorikannya sebagai otorisasi yang tidak tepat (CWE-285). Celah ini sudah ditambal sejak Maret 2025 dan, per 4 November 2026, tidak tercantum di katalog KEV CISA. Tapi itu bukan alasan untuk melewatkannya: aplikasi self-hosted yang jarang diperbarui masih bisa berjalan di versi rentan.

Kenapa satu header bisa melewati middleware?

Next.js memakai header x-middleware-subrequest secara internal untuk mendeteksi rekursi, yaitu agar middleware tidak memanggil dirinya sendiri berulang kali. Bila header itu ada, Next.js menganggap permintaan berasal dari dalam dan melewati middleware.

Masalahnya, header ini tidak didokumentasikan dan tidak dibedakan antara yang datang dari internal dan yang dikirim pengguna dari luar. Penyerang cukup menebak nilai header yang tepat, lalu permintaannya langsung menuju halaman tujuan. Kalau middleware adalah satu-satunya tempat kamu memeriksa login, peran pengguna, atau pembatasan wilayah, semua pemeriksaan itu ikut terlewati.

Menurut postmortem Vercel, laporan pertama masuk pada 27 Februari 2025 lewat pelaporan privat GitHub. Laporan tambahan pada 1 Maret 2025 memperluas cakupan ke versi yang lebih baru. Nomor CVE terbit 18 Maret 2025 dan celah diumumkan ke publik pada 21 Maret 2025.

Versi terdampak dan versi perbaikan

Advisori GHSA-f82v-jwr5-mffw merinci rentang versi berikut.

Versi 14.2.25 rilis 17 Maret 2025 dan 15.2.3 rilis 18 Maret 2025. Patch untuk 13.5.9 dan 12.3.5 menyusul pada 22 dan 23 Maret 2025 sebagai pengecualian kebijakan dukungan. Pengguna 11.x tidak mendapat patch dan diarahkan ke solusi sementara.

Perlu diingat, versi di atas hanya menutup celah ini. Next.js kemudian merilis perbaikan untuk celah lain, termasuk celah React Server Components yang dibahas di artikel React2Shell CVE-2025-55182. Jadi targetnya bukan sekadar "minimal 15.2.3", melainkan patch terbaru di jalur rilis yang kamu pakai.

Siapa yang sebenarnya terdampak?

Tidak semua aplikasi Next.js rentan. Vercel menjelaskan bahwa aplikasi yang di-deploy di Vercel tidak terdampak karena logika routing-nya berjalan di sistem terpisah. Netlify dan Cloudflare Workers juga dipastikan tidak terdampak dengan alasan serupa. Aplikasi yang memakai static export pun aman, karena middleware memang tidak tersedia tanpa server.

Yang terdampak adalah aplikasi self-hosted yang dijalankan dengan next start atau dibangun dengan output: 'standalone'. Pola ini umum di bisnis yang menaruh aplikasi di VPS, sering di belakang Nginx atau di dalam container Docker. Kalau kamu tidak yakin bagaimana aplikasimu dijalankan, cek package.json (skrip start) dan next.config.js (opsi output).

Reverse proxy di depan aplikasi juga tidak otomatis melindungi. Nginx, Apache, atau load balancer pada umumnya meneruskan header dari pengguna apa adanya, termasuk x-middleware-subrequest, kecuali kamu sengaja menghapusnya. Jadi aplikasi self-hosted di belakang proxy tetap dianggap terdampak sampai versinya diperbarui atau header itu diblokir.

Cara memeriksa dan menambal aplikasi self-hosted

Langkah pertama adalah memastikan versi yang terpasang. Jalankan npm ls next di folder proyek, atau lihat versi next di package-lock.json. Jangan hanya melihat package.json, karena rentang seperti ^14.1.0 belum tentu mencerminkan versi yang benar-benar terpasang di server.

Kalau versinya masuk rentang terdampak, perbarui ke patch terbaru di jalur rilismu, jalankan build ulang, lalu deploy. Setelah itu uji di lingkungan staging: kirim permintaan ke halaman yang dilindungi middleware dengan header x-middleware-subrequest, dan pastikan kamu tetap dialihkan ke halaman login. Uji ini cukup dilakukan pada aplikasimu sendiri, jangan pada sistem milik orang lain.

Bila upgrade belum memungkinkan, advisori resmi menyarankan solusi sementara: blokir permintaan dari luar yang membawa header x-middleware-subrequest sebelum sampai ke aplikasi. Di Nginx, misalnya, kamu bisa menolak atau menghapus header itu di blok location yang meneruskan ke Next.js. WAF di depan aplikasi juga bisa diberi aturan serupa, seperti dijelaskan di apa itu WAF.

Langkah terakhir sering terlupa: periksa log akses untuk melihat apakah ada permintaan ke halaman terlindungi yang membawa header tersebut sebelum patch dipasang. Kalau ada dan berhasil, anggap ada kemungkinan data sudah diakses, lalu ganti kredensial yang tampil di halaman admin. Simpan juga salinan log itu sebelum terhapus oleh rotasi log, karena bisa dibutuhkan bila nanti ada pertanyaan dari pelanggan atau mitra.

Pelajaran desain: jangan taruh semua kunci di satu pintu

Celah ini menunjukkan risiko menaruh seluruh otorisasi hanya di middleware. Middleware cocok untuk pengalihan cepat dan pemeriksaan awal, tapi data sensitif sebaiknya juga dilindungi di lapisan berikutnya: pemeriksaan sesi di route handler, server action, atau API yang mengambil data. Dengan begitu, kalau satu lapisan bocor, lapisan lain masih menahan.

Prinsip yang sama berlaku di server. Aplikasi yang berjalan di VPS sebaiknya tidak terbuka langsung ke internet tanpa reverse proxy, akses SSH sebaiknya memakai kunci, dan pembaruan dependensi dijadwalkan rutin. Daftar dasarnya ada di cara mengamankan VPS baru.

Kalau hanya ada waktu untuk tiga hal hari ini: cek versi next yang benar-benar terpasang, blokir header x-middleware-subrequest di proxy bila belum bisa upgrade, lalu tandai halaman mana saja yang otorisasinya hanya bergantung pada middleware.