Celah RCE di Next.js ImageResponse: Jangan Tunda Update ke 16.3.6

Kalau aplikasi kamu jalan di Next.js 16.2.0 sampai 16.3.5 dan memakai ImageResponse versi Node.js untuk membuat gambar Open Graph, jangan tunggu sprint berikutnya. Versi 16.3.6 sudah rilis dan memuat perbaikannya. Alasannya sederhana tapi serius: celah yang ditemukan memungkinkan eksekusi kode dari jarak jauh tanpa autentikasi apa pun. Tidak perlu akun, tidak perlu korban mengklik sesuatu, dan tidak perlu waktu pengguna di situs Anda. Penyerang hanya perlu mengirim data yang sudah dirakit khusus ke rute gambar yang terbuka untuk publik.

Ribuan aplikasi produksi memakai Next.js hari ini, dari situs korporat kecil sampai platform besar. ImageResponse, yang biasa dipakai untuk membuat gambar pratinjau otomatis saat tautan dibagikan ke WhatsApp, Slack, atau X, sering dianggap fitur ringan yang jarang diaudit. Padahal, di sinilah letak masalahnya.

Sumber masalahnya bukan Next.js sendiri

Celah ini tercatat resmi dengan kode CVE-2026-94545 dan advisory GHSA-vcvr-r3jv-pc5j. Menariknya, akar masalahnya bukan murni dari kode Next.js. Yang bermasalah adalah Satori, pustaka pihak ketiga yang dipakai Next.js untuk menghasilkan output SVG di dalam ImageResponse.

Satori tidak melakukan escaping karakter dengan benar. Artinya, teks yang seharusnya diperlakukan sekadar tulisan biasa bisa dibaca sebagai markup SVG. Ketika markup itu dieksekusi sebagai bagian dari proses pembuatan gambar, kode berbahaya bisa ikut masuk dan berjalan di server. Perlu dipahami bahwa SVG bukan format datar seperti PNG. Ia bisa memuat elemen aktif, dan kalau pustaka yang mengelolanya lengah, ruang lingkup masalah membengkak dari tugas membuat gambar menjadi pintu masuk ke server.

Skenario yang paling sering dijumpai seperti ini: aplikasi mengambil data dari parameter URL, isi formulir, nama profil pengguna, atau konten dari CMS, lalu langsung memasukkannya ke gambar yang dibuat ImageResponse. Rute OG image memang jarang dilindungi autentikasi karena memang harus terbuka untuk publik, sehingga siapa pun bisa mengirim payload. Kombinasi itu membuat jalur serangannya praktis dan otomatis.

Kenapa tingkat keparahannya digolongkan kritis

GitHub menilai kerentanan ini kritis berdasarkan standar CVSS v4. Faktor penilinya: vektor serangan berbasis jaringan, tingkat kesulitan eksploitasi rendah, tidak memerlukan hak akses khusus, dan tidak memerlukan interaksi pengguna. Terjemahan praktisnya, satu permintaan jaringan sudah cukup sebagai pemicu. Untuk penyerang, celah semacam ini sangat menarik karena bisa dijadikan target pemindaian massal.

Coba dibandingkan dengan celah yang membutuhkan pengguna login lalu mengklik tautan. Di sana, peluang eksploitasi terbatas. Di sini, penyerang bisa menyusun daftar domain, mengirim muatan ke rute OG image yang umum dipakai, dan tinggal menunggu yang rentan merespons. Karena tidak ada indikasi serangan yang terlihat oleh pengguna akhir, eksploitasi bisa berlangsung lama sebelum terdeteksi.

Cek apakah aplikasi Anda terdampak

Tidak semua pengguna Next.js otomatis berisiko. Ada tiga syarat yang harus terpenuhi bersamaan. Pertama, aplikasi menjalankan Next.js 16.2.0 sampai 16.3.5. Kedua, ImageResponse dipakai lewat implementasi Node.js, bukan Edge. Ketiga, rute gambar memproses input yang tidak tepercaya, misalnya parameter URL atau data dari pengunjung.

Pengembang yang memakai implementasi Edge pada ImageResponse dipastikan aman dari celah ini. Netlify pun menyatakan pandangan serupa: situs yang tidak menaruh input pengguna ke dalam gambar yang dihasilkan ImageResponse dinyatakan tidak terdampak. Jadi langkah pertama adalah identifikasi versi, lalu lacak di mana ImageResponse digunakan dan apa datanya berasal.

Langkah yang sebaiknya dilakukan

1. 1Update ke Next.js 16.3.6 segera. Hasil upgrade memuat perbaikan pustaka Satori. Jalankan perintah penambahan dependensi seperti biasa, lalu pastikan versi yang tercatat sudah benar di lockfile.
2. 2Untuk lini 15.x, upgrade opsional tapi tetap disarankan ke 15.5.26. Lini 15 tidak terdampak RCE ini, rilis tsb disiapkan sebagai lapisan pengerasan tambahan, bukan perbaikan celah yang sama.
3. 3Audit setiap rute yang memakai ImageResponse. Cari data dari luar yang masuk ke konten, atribut, atau gaya SVG. Perhatikan tempat paling rawan: parameter URL, nama halaman, judul produk, nama pengguna, dan teks dari CMS.
4. 4Kalau sekarang belum bisa update, pindahkan sementara rute yang rawan ke implementasi Edge. Opsi ini aman dari celah ini, tapi uji dulu supaya tidak mengganggu fungsi lain.
5. 5Jangan andalkan validasi input sebagai satu-satunya penangkal. Selama string yang tidak tepercaya masih bisa terbaca sebagai markup, celahnya tetap ada. Validasi tetap perlu, tetapi ia melengkapi, bukan menggantikan, perbaikan versi.

Yang menarik dari pola serangan ini

Peristiwa ini jadi pengingat murah tentang kerentanan rantai pasokan pustaka. Framework yang dipakai jutaan orang tetap saja mengandalkan pustaka lain, dan pustaka itu tetap bisa punya cacat escaping yang memicu masalah besar. Sebagian besar pengembang jarang memantau dependensi di luar paket utama yang ada di barisan pertama package.json.

Untuk tim yang punya proses review keamanan, ada satu poin praktis yang bisa diambil: rute yang terbuka untuk publik dan memproses data dari pengguna layak diperlakukan sebagai zona rawan tinggi, bukan sebagai sesuatu yang aman secara asumsi. Kalau fitur ImageResponse hanya dipakai dengan teks statis, ruang risikonya kecil. Tapi begitu ada bagian dinamis, biasanya sudah terlambat untuk diaudit.

Kalau kamu membangun situs klien, ini relevan dua arah

Bagi yang mengerjakan website untuk UMKM atau bisnis kecil, celah seperti ini punya dua sisi yang perlu dipikirkan. Sisi pertama teknis: apakah situs yang kamu deploy memakai versi yang terdampak. Sisi kedua relasi: seberapa siap kamu memberi tahu klien bahwa ada masalah dan bagaimana penyelesaiannya.

Yang membedakan tim yang rapi dan tim yang panik biasanya bukan kecepatan mereka menulis kode, melainkan seberapa jelas prosedur mereka saat ada insiden. Daftar sederhana yang bisa disiapkan: siapa yang memutuskan untuk update, ke mana rollback dilakukan, bagaimana mengomunikasikan status ke klien, dan alat apa yang dipakai untuk mengetahui bahwa sistem sudah normal. Kalau daftar itu belum ada, hari ini waktu yang tepat untuk membuatnya.

Untuk klien yang situsnya menggunakan generator gambar sosial otomatis, tambahkan pertanyaan baru ke daftar audit rutin: data apa yang mengalir ke generator itu. Satu kolom nama toko yang bisa diubah pemilik lewat dasbor mungkin sudah termasuk input yang perlu diperlakukan sebagai tidak sepenuhnya tepercaya.

Deteksi dini dan pemantauan

Selain memperbaiki versi, pemantauan yang baik membantu memastikan celah yang sudah ditutup benar-benar tidak terekspos. Beberapa langkah praktis yang murah dilakukan dan tetap bernilai:

• Kunci versi di lockfile supaya upgrade tidak berjalan sendiri tanpa terlihat di review.
• Pantau advisory GitHub untuk paket utama yang dipakai. Notifikasi ini gratis dan bisa dibaca lewat halaman keamanan repositori.
• Tandai rute yang memproses input publik dengan komentar di kode atau entri dokumentasi internal, supaya reviewer tahu mana yang perlu dilihat lebih teliti.
• Simpan riwayat upgrade beserta tanggalnya. Ketika tim keamanan atau klien bertanya, jawabannya tidak perlu ditebak.
• Kalau memakai dependabot atau renovate, set pengingat manual sekali waktu untuk dependensi transitive yang tidak selalu tercakup pemindaian otomatis.

Pemantauan semacam ini tidak terdengar keren, tetapi justru pekerjaan rutin seperti ini yang menyelamatkan reputasi saat celah berikutnya diumumkan. Celah keamanan berikutnya pasti datang, tinggal menunggu di paket mana dan di fitur apa.

Penutup

Untuk yang memakainya sebagai kerangka kerja utama, cek versinya hari ini. Kalau nomornya jatuh di rentang terdampak, jangan tunda. Menunda satu hari berarti membuka jendela eksploitasi massal yang tidak membutuhkan apa-apa selain satu permintaan jaringan.