Node.js Project mengumumkan akan menerbitkan versi baru untuk tiga jalur rilis sekaligus pada Rabu, 11 November 2026: 26.x, 24.x, dan 22.x. Yang membuat pengumuman ini penting adalah tingkat keparahannya, karena isu dengan severity HIGH muncul di ketiga jalur tersebut. Artinya, hampir semua aplikasi Node.js produksi yang masih dirawat saat ini berpotensi perlu dipatch dalam hitungan hari setelah rilis tersedia.

Pengumuman resmi memang belum menyebutkan CVE, komponen yang terdampak, maupun detail teknis lainnya. Itu normal: Node.js Project baru membuka detail kerentanan bersamaan dengan dirilisnya versi perbaikan, supaya tidak ada jendela eksploitasi sebelum patch tersedia. Jadi tulisan ini tidak akan menebak-nebak isi celahnya, dan yang bisa kita lakukan sekarang adalah menyiapkan jalur upgrade agar hari-H tidak jadi panik.

Apa yang sudah pasti dari pengumuman resmi

• Rilis menyasar tiga jalur sekaligus, yaitu 26.x, 24.x, dan 22.x, dengan severity tertinggi HIGH di masing-masing jalur.
• Rilis tersedia "on or shortly after" Rabu, 11 November 2026; dalam praktik Node.js biasanya tepat hari itu atau bergeser beberapa jam.
• Versi yang sudah End-of-Life tetap terkena dampak, tetapi tidak akan menerima patch, sehingga satu-satunya jalan adalah naik ke jalur yang masih didukung.

Kenapa tiga jalur sekaligus?

Node.js menganut model rilis berjadwal, di mana versi genap menjadi LTS dan dirawat panjang sedangkan versi ganjil historisnya hanya berumur pendek. Saat ini jajaran yang aktif adalah Node.js 26 "Lithium" (LTS, rilis perdana Mei 2026), Node.js 24 "Krypton" (LTS, rilis perdana Mei 2025), dan Node.js 22 "Jod" (LTS, rilis perdana April 2024). Karena ketiganya masih dalam masa dukungan, perbaikan keamanan harus dikirim ke semuanya.

Ada perubahan penting bagi tim yang merencanakan upgrade jangka panjang: mulai Node.js 27, siklus rilis menjadi tahunan. Setiap versi mayor akan melewati fase Current enam bulan, lalu enam bulan Alpha, kemudian masuk LTS dengan total masa dukungan sekitar 30 bulan. Node.js 27 sendiri baru berstatus Alpha (rilis 29 Oktober 2026), jadi belum layak produksi. Implikasinya bagus untuk perencanaan karena lompatan mayor tidak lagi sesering dulu, tetapi fase transisinya tetap harus dijadwalkan, bukan ditunda sampai terpaksa.

Langkah 1: Petakan versi di semua lingkungan

Sebelum patch dirilis, kumpulkan dulu fakta. Yang sering terlewat bukan server utama, melainkan runner CI, image Docker lama, dan environment staging yang dibiarkan menua.

node -v && npm -v
grep -n '"engines"' -A3 package.json
grep -rn "^FROM node:" Dockerfile* 2>/dev/null

Kalau aplikasi berjalan di runtime terkelola seperti layanan serverless, panel hosting, atau container platform, catat juga versi runtime yang dipilih di dasbor. Runtime terkelola biasanya menyediakan patch beberapa hari sampai beberapa minggu setelah rilis resmi, dan itu perlu dipantau, bukan diasumsikan otomatis.

Langkah 2: Siapkan jalur upgrade sebelum CVE dibuka

Kalau tim memakai version manager, uji perintah upgrade sekarang di staging agar hari-H tinggal menjalankannya. Contoh dengan nvm:

nvm install 24 && nvm use 24
node -v
npm ci && npm test

Untuk aplikasi yang masih di Node.js 22, pertimbangkan sekalian naik ke 24 atau 26 selama masa transisi ini. Memang dua kali kerja, tetapi menghindari upgrade terburu-buru di kemudian hari ketika jalur lama benar-benar ditutup.

Langkah 3: Perbaiki Dockerfile dan image

Ini sumber masalah paling umum, karena tag seperti node:24 atau node:latest membuat versi yang berjalan berbeda antar-build sehingga sulit membuktikan bahwa patch sudah terpasang. Pin ke versi patch eksplisit dan rebuild setelah rilis keamanan keluar.

FROM node:24.22.3-alpine
WORKDIR /app
COPY . .
RUN npm ci --omit=dev
CMD ["node", "server.js"]

Perhatikan bahwa angka 24.22.3 di atas hanyalah contoh bentuk penulisan, sebab versi patch sebenarnya baru diketahui setelah rilis. Yang penting adalah kebiasaannya: satu angka eksplisit, bukan tag mengambang. Setelah image baru dibangun, jalankan ulang container dan pastikan node -v di dalamnya menunjukkan versi yang benar.

Langkah 4: Uji, lalu rilis bertahap

• Jalankan test suite penuh dengan npm ci, bukan npm install, supaya lockfile benar-benar dihormati.
• Uji minimal satu alur kritis seperti login, transaksi, atau endpoint yang paling sering dipakai.
• Deploy ke satu instance atau satu node dulu, amati error rate dan latensi, baru lanjut ke sisanya.
• Siapkan rollback ke image sebelumnya, karena patch keamanan tetap perubahan versi dengan risiko regresi kecil yang bukan nol.

Langkah 5: Pantau sumber resmi, bukan grup chat

Ikuti mailing list nodejs-sec yang bersifat announcement-only, atau pantau halaman blog vulnerability Node.js tempat detail CVE akan muncul bersamaan dengan rilis. Sebaliknya, waspadai "bocoran" yang beredar di grup WhatsApp atau kanal Telegram sebelum tanggal rilis. Informasi setengah jadi seperti itu lebih sering menyesatkan daripada menolong.

Kalau aplikasi masih di Node.js 20 atau 25

Node.js 20 dan 25 sudah berstatus End-of-Life, jadi tidak akan menerima patch dari rilis 11 November ini. Selama masih berjalan, aplikasi tersebut menanggung risiko yang tidak lagi diperbaiki oleh proyek hulu. Untuk konteks instansi dan UMKM yang aplikasinya berjalan bertahun-tahun, ini biasanya titik di mana biaya menunda upgrade jauh lebih besar daripada biaya mengerjakannya.

Kesimpulan

Rilis 11 November 2026 adalah rutinitas yang sehat dari proyek yang masih aktif dirawat, bukan alarm. Yang membedakan tim yang tenang dan tim yang panik adalah persiapan: tahu versi apa yang berjalan di mana, punya jalur upgrade yang sudah diuji, dan tidak memakai tag image mengambang. Tiga hal itu bisa diselesaikan hari ini, sebelum patch-nya sendiri tersedia.

Sumber: Node.js — Wednesday, November 11, 2026 Security Releases, Node.js Releases (jadwal dan status LTS), Node.js Security Policy.