Inti artikel
12 CVE PHP dan Node.js dirilis 21 Okt 2026, termasuk CVE-2026-109618, CVE-2026-109619, CVE-2026-111497. Versi perbaikan dan cara kami menjaga situs.
Setiap minggu ada celah keamanan baru yang diumumkan untuk PHP, Node, dan paket-paket di sekitarnya. Kebanyakan tidak berdampak ke situs kita. Tetapi satu yang terlewat bisa cukup untuk membuka data mitra dan pelanggan, dan penyerang tidak menunggu kita siap.
Tim engineer Life Future tidak mengandalkan keberuntungan. Di bawah ini cara kami bekerja: apa itu CVE, kenapa PHP dan Node perlu perhatian khusus, apa yang kami lakukan begitu sebuah celah diumumkan, dan enam kebiasaan yang kami jalankan terus supaya celah itu tidak sempat jadi masalah.

21 Oktober 2026: PHP dan Node.js merilis tambalan keamanan di hari yang sama
Pada 21 Oktober 2026 proyek PHP dan Node.js sama-sama merilis pembaruan keamanan. Berikut ringkasan dari pengumuman resmi keduanya, lengkap dengan nomor CVE supaya mudah dicari dan dicocokkan dengan sistem yang kamu kelola.
PHP: dua celah kritis
- CVE-2026-109618 (GHSA-w8hw-w9fx-j79w): kerusakan memori setelah PHP kehabisan memori, yang dapat berujung pada eksekusi kode dari jauh. Skor CVSS v4 9.2, tingkat Critical.
- CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp): data global dari satu permintaan terbawa ke permintaan berikutnya, yang juga dapat berujung pada eksekusi kode dari jauh. Skor CVSS v4 9.2, tingkat Critical.
Versi PHP di bawah 8.2.35, 8.3.36, 8.4.27, dan 8.5.12 terdampak. Perbaikannya ada di empat versi itu.
Node.js: sepuluh CVE, empat di antaranya High
- CVE-2026-111497 (High): penulisan di luar batas pada dekoder Brotli yang dapat berujung pada eksekusi kode dari jauh.
- CVE-2026-105482 (High):
dns.resolvememotong nama host yang mengandung karakter NUL. - CVE-2026-105483 (High): pemeriksaan nama host pada sertifikat TLS dapat dilewati bila IP ditulis dengan angka lebar penuh.
- CVE-2026-106069 (High): pemeriksaan nama host pada sertifikat TLS dapat dilewati bila host terbaca longgar sebagai alamat IP.
- CVE-2026-105481, CVE-2026-106072, CVE-2026-106074 (Medium): soket keep-alive, validasi sertifikat untuk alamat IPv4 tidak baku, dan nilai acak yang berulang pada snapshot.
- CVE-2026-106070, CVE-2026-106071, CVE-2026-106073 (Low): ZipFile, serta dua celah pada Permission Model.
Perbaikannya ada di Node.js 22.23.4, 24.22.1, dan 26.12.1. Rilis ini juga memperbarui OpenSSL, c-ares, Undici, SQLite, dan daftar sertifikat CA (setelah penarikan sertifikat perantara eMudhra). Node.js 20 tidak termasuk dalam rilis ini.
Hasil pemeriksaan kami: layanan PHP dan Node.js di server produksi utama kami sudah berjalan di versi yang memuat perbaikan. Kami memeriksanya langsung di server yang sedang berjalan, bukan dari catatan konfigurasi.
Kalau kamu mengelola server sendiri: jalankan php -v dan node -v, lalu bandingkan dengan versi di atas. Paket dari distro Linux sering mempertahankan nomor versi lama setelah perbaikan diterapkan, jadi periksa juga catatan keamanan penyedia paketmu. Kalau aplikasi berjalan di dalam container, bangun ulang image-nya agar mengambil basis yang baru, jangan hanya mengganti nomor versi.
Sumber resmi: Node.js Security Releases, 21 Oktober 2026, advisori GHSA-w8hw-w9fx-j79w, dan advisori GHSA-6wmf-4rv5-p3rp.
Apa itu CVE, dan kenapa jumlahnya tidak pernah berhenti
CVE adalah singkatan dari Common Vulnerabilities and Exposures, yaitu daftar publik celah keamanan. Setiap celah yang diketahui mendapat satu nomor unik, dengan format CVE-tahun-nomor, sehingga semua orang di industri membicarakan celah yang sama.
Hampir setiap CVE juga diberi skor keparahan dari 0 sampai 10. Skor tinggi tidak otomatis berarti situs kita dalam bahaya. Yang menentukan ada dua hal: apakah kami memakai bagian yang bermasalah, dan apakah bagian itu bisa dijangkau dari internet. Karena itu pertanyaan pertama tim kami saat ada pengumuman selalu sama: apakah kami terdampak, dan bisakah dijangkau dari luar?
Kenapa PHP dan Node perlu perhatian khusus
Keduanya dipakai oleh jutaan situs, jadi menarik bagi penyerang: satu celah bisa dicoba ke ribuan sasaran sekaligus. Keduanya juga punya ekosistem paket yang sangat besar. Satu paket yang kita pasang biasanya membawa puluhan paket lain, sehingga celah bisa datang dari pustaka yang tidak pernah kita pilih sendiri.
Ditambah lagi, situs web terbuka ke internet 24 jam sehari. Celah yang belum ditambal bisa dicoba kapan saja, termasuk tengah malam dan akhir pekan.

Yang terjadi sejak sebuah celah diumumkan
Kami punya urutan kerja yang sama setiap kali, supaya tidak ada langkah yang terlewat saat sedang terburu-buru:
- Membaca pengumumannya dan memahami bagian mana yang terdampak.
- Memeriksa apakah kami memakai bagian itu. Karena versi kami dikunci, jawabannya bisa didapat dengan cepat, bukan menebak.
- Menaikkan versi sebagai satu perubahan tersendiri.
- Menjalankan pengujian otomatis.
- Mengirimnya ke produksi lewat jalur yang sama dengan perubahan lain.
- Memeriksa langsung bahwa versi baru benar-benar berjalan di server, bukan hanya percaya pada laporan "berhasil".
- Mencatat apa yang berubah, supaya orang berikutnya tahu.
Menambal itu hanya separuh cerita. Separuh lainnya adalah membuat sistem yang tetap aman bahkan ketika tambalannya belum ada. Itu yang dilakukan enam kebiasaan berikut.

1. Versi dikunci, bukan "yang terbaru saja"
Setiap runtime dan komponen kami tulis dengan versi yang pasti. Kalau versi bisa berganti diam-diam, kami tidak tahu persis apa yang sedang berjalan, dan tidak bisa menjawab pertanyaan terpenting saat ada pengumuman celah: apakah kami terdampak?
Versi yang dikunci juga membuat hasil kerja bisa diulang. Build hari ini dan build bulan depan memakai bagian yang sama persis, jadi tidak ada perubahan yang masuk tanpa kami sadari. Kalau sebuah pembaruan bermasalah, kami tahu persis versi mana yang harus dikembalikan.
2. Rilis keamanan dikerjakan sendiri
Saat PHP, Node, atau komponen di bawahnya merilis perbaikan keamanan, kami menaikkan versinya sebagai satu perubahan tersendiri. Tidak digabung dengan fitur baru, supaya kalau ada masalah, penyebabnya jelas dan mudah dibatalkan.
Contoh nyatanya: ketika sebuah komponen server kami merilis versi keamanan, kami memasangnya tanpa membawa perubahan lain, menjalankan seluruh pengujian, lalu mengirimnya. Satu perubahan, satu alasan.
3. Semua yang datang dari luar dianggap tidak aman
Ada tiga jenis serangan yang paling sering kami jaga. Injeksi, yaitu menyisipkan perintah lewat isian formulir. Script lintas situs atau XSS, yaitu menanam skrip di halaman yang nanti dilihat orang lain. Dan SSRF, yaitu memancing server kami untuk mengakses alamat internal miliknya sendiri.
Karena itu isian formulir, tautan, file yang diunggah, dan alamat yang dimasukkan pengguna diperiksa sebelum disimpan. Konten dibersihkan dari skrip berbahaya saat disimpan, dan setiap permintaan keluar ke alamat yang bisa dipengaruhi pengguna melewati penjaga yang menolak tujuan internal. Lapisan ini melindungi kami bahkan ketika sebuah celah baru diumumkan dan tambalannya belum tersedia.

4. Akses dibatasi sejak awal
Prinsipnya: kalau sesuatu bocor, batasi seberapa jauh kerusakannya. Setiap orang hanya memegang izin yang ia butuhkan. Editor menyiapkan draf, hanya yang berwenang yang bisa mengubah tampilan live, dan pengaturan sensitif hanya untuk admin.
Kunci integrasi dan rahasia lain disimpan terenkripsi, hanya bisa ditulis dan tidak bisa dibaca ulang lewat sistem, dan tidak pernah dicatat di log atau pesan error. Perubahan yang berdampak ke tampilan live juga meninggalkan catatan audit.
5. Ada penjaga di depan situs
Banyak serangan dimulai dengan hal yang kasar: mencari berkas rahasia seperti salinan konfigurasi atau cadangan, memeriksa pintu masuk panel admin sistem lain, mencoba menyusup lewat alamat, menyisipkan perintah, memakai alat pemindai dan alat serangan, atau membanjiri situs dengan permintaan.
Permintaan seperti itu ditolak atau dibatasi sebelum sampai ke aplikasi. Setiap pengunjung punya jatah permintaan per menit. Saat banjir terdeteksi, situs bisa beralih sendiri ke pemeriksaan browser selama satu jam, lalu kembali normal. Semuanya bisa dilihat di dasbor, jadi kami tahu apa yang sedang mencoba masuk.
6. Dipantau, dan bisa dibatalkan
Error di produksi langsung masuk ke pemantauan, jadi masalah terlihat saat itu juga dan bukan seminggu kemudian dari keluhan pengguna. Rilis kami kecil dan sering, sehingga setiap perubahan mudah dipahami.
Versi sebelumnya tetap tersimpan. Kalau sebuah perubahan ternyata bermasalah, kami bisa menariknya kembali dengan cepat, tanpa perlu menulis ulang apa pun di tengah tekanan.
Aturan keamanan punya pengujian
Setiap aturan keamanan yang kami tulis punya pengujian otomatis. Kalau sebuah perubahan tanpa sengaja melonggarkannya, build gagal sebelum sampai ke produksi. Dengan begitu perlindungan yang sudah ada tidak hilang diam-diam saat kode berubah.
Apa artinya untuk kamu
Sebagai mitra atau pelanggan, kamu tidak perlu mengubah apa pun. Yang kamu rasakan adalah situs yang tetap cepat dan tersedia, dan data yang tidak sampai ke tangan yang salah. Semua kebiasaan di atas ada supaya hal itu tidak perlu kamu pikirkan.
Yang tidak bisa kami janjikan
Tidak ada sistem yang kebal, dan celah baru akan terus muncul. Yang bisa kami lakukan adalah memperpendek jarak antara pengumuman dan tambalan, membatasi dampak kalau ada yang lolos, dan jujur soal apa yang kami ketahui.

