Patch RCE Next.js 2026: Update Dulu, Baru Kunci CSP

Lima hari lalu gue bangun tidur terus liat security advisory di inbox, dan perut gue langsung mules dikit. Vercel baru aja ngumumin dua kerentanan remote code execution kritis di Next.js, yang notabene framework yang jalanin hampir semua production apps gue. Gak perlu login, gak perlu interaksi user, cukup satu request yang udah dirancang khusus. Gue tutup laptop sebentar, tarik napas, terus buka tiga terminal sekaligus buat cek semua project yang lagi jalan.

Panik itu berujung jadi hardening pass yang serius. Bukan cuma bump versi kayak yang diminta advisory-nya, tapi juga jadi kesempatan buat akhirnya benerin sesuatu yang udah gue tunda berbulan-bulan, Content Security Policy yang masih ngizinin unsafe-inline soalnya kalau dihapus, script analytics gue selalu error. Ini semua yang gue lakuin, urutannya beneran kepake.

Key Takeaways

Next.js ngumumin dua kerentanan RCE kritis tanpa autentikasi tanggal 25 Agustus 2026, kena versi 13.4 sampai 15.5.23 dan 16.0 sampai 16.3.2. Update ke 16.3.3 di Active LTS atau 15.5.24 di Maintenance LTS sekarang juga, soalnya kedua patch itu juga otomatis matiin AVIF image optimization sebagai mitigasi tambahan. Setelah update, manfaatin momen ini buat hapus unsafe-inline dari CSP script-src lo, tapi cuma setelah semua inline script di halaman lo dipindah ke file eksternal dulu, soalnya dua perubahan ini saling bergantung dan kalau urutannya kebalik, bisa jadi lubang keamanan tetap kebuka atau analytics lo mati diam diam.

Sebenarnya Apa Sih yang Kejadian di Kerentanan RCE Next.js Agustus 2026?

Vercel ngumumin dua kerentanan kritis terpisah yang sama sama bisa dieksploitasi tanpa autentikasi buat remote code execution di server production Next.js. Menurut rilis security resmi Next.js bulan Agustus 2026, yang pertama itu CVE-2026-75604, celah path traversal yang khusus nyerang filesystem Windows. Ini kena aplikasi yang pake Pages Router maupun App Router tanpa Cache Components, dan skor CVSS-nya 9.0. Deployment di Linux dan macOS gak kena celah spesifik ini, penting banget kalau lo deploy di host Windows atau lewat CI runner berbasis Windows.

Yang kedua itu kerentanan di image optimization AVIF, akarnya ada di libheif, library pemroses gambar yang dipake Next.js buat fitur image optimization bawaannya. Kalau aplikasi lo ngoptimasi gambar AVIF yang dikontrol attacker, misalnya yang diupload lewat form publik atau diambil dari URL yang diinput user, celah ini bisa dipicu tanpa autentikasi sama sekali. Liputan dari The Hacker News mastiin dua isu ini dipatch di siklus rilis yang sama, artinya Vercel nganggep dua duanya sama urgentnya.

Rentang versi yang kena lumayan luas. Mulai dari 13.4 sampai 15.5.23, dan terpisah 16.0 sampai 16.3.2, semuanya rawan. Kalau lo udah lama gak sentuh versi Next.js, anggap aja project lo masuk rentang itu sampai lo cek sendiri.

Also Read: Ngatasin Next.js Docker Build OOM Kill di CI

Gimana Cara Patch Kerentanan RCE Next.js Ini?

Update ke Next.js 16.3.3 kalau lo di jalur Active LTS, atau 15.5.24 kalau project lo terkunci di Maintenance LTS. Kedua rilis patch itu otomatis matiin AVIF optimization secara default sebagai mitigasi keamanan, di atas fix untuk isu libheif-nya, jadi lo gak perlu matiin apa apa manual.

# cek dulu versi yang lagi lo pake
npx next --version

# buat project di jalur 16.x
npm install next@16.3.3

# buat project yang terkunci di jalur maintenance 15.x
npm install next@15.5.24

Setelah update, restart dev server lo, dan yang lebih penting, redeploy production sekarang juga. Ini bukan patch yang bisa lo tunda ke sprint depan. Changelog Netlify buat rilis ini secara eksplisit nandain sebagai action item hari itu juga buat siapapun yang masih pake versi kena celah, dan gue setuju banget sama cara pandang itu. RCE tanpa autentikasi yang nangkring di production bukan backlog item, itu insiden yang tinggal nunggu waktu.

Kalau tim lo deploy di infrastruktur Windows, double check dulu apakah CVE-2026-75604 spesifiknya udah kecover sama versi yang lo update, soalnya celah ini yang spesifik ke platform tertentu, bukan yang universal.

Kenapa Lo Perlu Hapus unsafe-inline dari CSP?

Soalnya unsafe-inline di script-src bikin seluruh tujuan punya Content Security Policy melawan serangan script injection jadi percuma. Content Security Policy itu header HTTP response yang ngasih tau browser sumber sumber mana aja buat script, style, dan resource lain yang boleh jalan di halaman lo. Kalau script-src masih ada unsafe-inline, browser bakal seneng hati ngejalanin inline script tag apapun yang dia temuin, termasuk yang berhasil disisipin attacker lewat celah XSS di bagian lain aplikasi lo. Header CSP-nya ada di atas kertas, tapi sebenarnya gak beneran ngeblok serangan yang harusnya dia cegah.

Gue punya celah persis kayak gini lebih lama dari yang mau gue akuin. CSP gue keliatan cukup ketat di permukaan, ngebatesin sebagian besar tipe resource cuma ke domain sendiri, tapi script-src masih bawa unsafe-inline soalnya itu default yang dibawa banyak starter template, dan tiap kali gue hapus, script Google Analytics sama Microsoft Clarity gue langsung error, soalnya dua duanya nangkring sebagai inline script tag langsung di layout gue.

Kenapa Gak Bisa Langsung Hapus unsafe-inline Terus Selesai?

Soalnya halaman lo hampir pasti masih punya inline script tag yang bakal ditolak browser begitu policy-nya diketatin, termasuk analytics lo. Ini dependency yang sering kelewatan di banyak tutorial. Lo gak bisa benerin CSP secara terpisah. Kalau lo hapus unsafe-inline dari script-src sementara inline script tag masih nangkring di HTML lo, semua script itu berhenti jalan diam diam. Gak ada error console yang keliatan jelas nyambung, cuma dashboard analytics yang tiba tiba sepi dan gak ada yang sadar sampe seminggu kemudian.

Solusinya, pindahin semua inline script ke file eksternal dulu, baru ketatin CSP-nya belakangan. Ini contoh yang gue lakuin buat tag Google Analytics sama Clarity gue.

Sebelum, nangkring langsung di halaman sebagai inline script:

<script>
    window.dataLayer = window.dataLayer || [];
    function gtag() {
        dataLayer.push(arguments);
    }
    gtag("js", new Date());
    gtag("config", "G-XXXXXXXXXX");
</script>

Sesudah, dipindah ke public/scripts/analytics.js dan dimuat sebagai file eksternal:

<script src="/scripts/analytics.js" async></script>

// public/scripts/analytics.js
window.dataLayer = window.dataLayer || [];
function gtag() {
    dataLayer.push(arguments);
}
gtag("js", new Date());
gtag("config", "G-XXXXXXXXXX");

Begitu semua inline script tag di halaman udah hilang, ngetatin header-nya jadi aman.

Sebelum, dengan celah yang masih kebuka:

Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline' https://www.googletagmanager.com;

Sesudah, dengan celah yang udah ketutup:

Content-Security-Policy: default-src 'self'; script-src 'self' https://www.googletagmanager.com;

Also Read: Rilis Next.js 16: Startup Lebih Cepat & Build Makin Stabil

Apa Sebaiknya Lo Pake Nonce Aja Daripada Pindahin Script?

Iya, kalau lo punya script pihak ketiga yang emang gak bisa dipindah ke file eksternal. Nonce itu token acak sekali pakai yang digenerate per request, yang lo tempelin ke header CSP sama inline script tag tertentu yang masih lo butuhin. Browser cuma bakal jalanin inline script yang atribut nonce-nya cocok sama yang dideklarasiin di header buat request itu, artinya script yang disisipin attacker tanpa nonce yang bener ya gak bakal jalan, walaupun policy-nya masih ngizinin sebagian inline execution.

Content-Security-Policy: script-src 'self' 'nonce-r4nd0mVaLu3PerRequest';

<script nonce="r4nd0mVaLu3PerRequest">
    // inline script spesifik ini diizinin jalan
</script>

Pindahin ke file eksternal lebih simpel dan gue rekomendasiin jadi default, selama isi script-nya gak perlu digenerate dinamis per request. Pake nonce cuma kalau vendor pihak ketiga ngotot mau inject inline dan lo gak punya kendali atas itu.

Pertanyaan yang Sering Diajukan

Versi Next.js mana aja yang kena kerentanan RCE Agustus 2026? Versi 13.4 sampai 15.5.23 dan 16.0 sampai 16.3.2 kena salah satu atau dua duanya dari kerentanan RCE kritis tanpa autentikasi yang diumumin tanggal 25 Agustus 2026.

Versi Next.js mana yang udah fix kerentanan RCE-nya? Update ke 16.3.3 di jalur Active LTS atau 15.5.24 di Maintenance LTS. Kedua rilis itu ngefix kerentanannya dan otomatis matiin AVIF image optimization sebagai mitigasi tambahan.

Update Next.js otomatis benerin CSP gue juga gak? Enggak, update versi cuma nge-patch kerentanan RCE-nya. Hapus unsafe-inline dari CSP itu langkah hardening terpisah yang harus lo lakuin sesudahnya, dan itu butuh inline script lo dipindah dulu ke file eksternal.

Hapus unsafe-inline dari CSP bakal ngerusak script analytics gue gak? Iya, kalau script itu masih ditulis sebagai inline script tag. Pindahin isi script-nya ke file eksternal di dalam public directory lo dan panggil pake atribut src sebelum lo ketatin header CSP-nya.

Aplikasi gue kena CVE-2026-75604 gak kalau deploy di Linux? Enggak, CVE-2026-75604 itu celah path traversal yang spesifik ke filesystem Windows. Ini gak ngefek ke deployment Linux atau macOS, tapi kerentanan RCE AVIF optimization yang lain di pengumuman yang sama tetep ngefek ke semua platform.

Nge-patch RCE-nya bagian yang gampang, satu command terus redeploy. Benerin celah CSP-nya makan waktu lebih lama soalnya harus ngurai script analytics yang gue copy paste bertahun tahun lalu tanpa mikir dua kali. Kalau lo cuma mau lakuin satu hal setelah baca ini, update sekarang juga. Kalau mau dua, jadiin redeploy ini alasan buat akhirnya nutup celah unsafe-inline itu juga.