Empat Peringatan Keamanan dalam Sebulan: Cara Kami Memilah Mana yang Harus Di-patch

Satu Minggu, Empat Kabar Buruk

Bagi siapa pun yang mengelola aplikasi web, Oktober 2026 adalah bulan yang sibuk. Hanya dalam sekitar satu minggu, empat proyek perangkat lunak yang banyak dipakai aplikasi bisnis menerbitkan peringatan keamanan (security advisory):

• 15 Oktober — kernel Linux di Ubuntu: CVE-2026-98432, celah kritis pada koneksi TCP.
• 19 Oktober — Laravel: dua advisory, CVE-2026-114509 dan CVE-2026-114508.
• 21 Oktober — PHP: dua celah remote code execution kritis, CVE-2026-109618 dan CVE-2026-109619.
• 21 Oktober — Node.js: rilis keamanan yang memperbaiki sepuluh CVE, dengan CVE-2026-111497 sebagai yang paling serius.

Berita seperti ini biasanya memancing salah satu dari dua reaksi: panik, atau menganggap pasti ada orang lain yang sudah mengurusnya. Keduanya sama-sama tidak melindungi aplikasi. Yang melindungi adalah proses yang tenang dan bisa diulang: pastikan advisory mana yang relevan, tangani yang relevan, lalu buktikan bahwa penanganannya berhasil.

Tulisan ini menceritakan bagaimana kami melewati bulan tersebut. Rincian teknis setiap celah dan perintah yang dijalankan sudah kami terbitkan di qadrlabs, platform belajar kami, dan tautannya ada di bagian akhir. Di sini kami fokus pada keputusan yang diambil, karena itulah yang semestinya bisa Anda harapkan dari pihak yang memelihara sistem Anda.

Bukan Langsung Patch, tetapi Mencocokkan Dulu

Pertanyaan pertama untuk setiap advisory selalu sama: apakah ini menyentuh sesuatu yang benar-benar kami jalankan?

Untuk menjawabnya dibutuhkan inventaris stack yang selalu diperbarui: sistem operasi dan kernel, web server, runtime bahasa beserta versinya, framework beserta versinya, dan runtime lain seperti Node.js. Tanpa inventaris itu, tim hanya punya dua pilihan buruk: menambal semuanya tanpa arah, atau menganggap tidak ada yang perlu ditangani.

Untuk proyek-proyek yang kami kelola, hasil pencocokan terbagi menjadi tiga kelompok:

Setiap baris butuh jenis pekerjaan yang berbeda. Memperlakukan keempatnya dengan cara yang sama akan membuang tenaga di satu sisi dan meninggalkan celah di sisi lain.

PHP: Memasang Patch Justru Bagian yang Paling Mudah

Tim PHP memberi pemberitahuan lebih awal pada 20 Oktober, sesuatu yang jarang mereka lakukan, bahwa dua celah kritis dengan skor CVSS v4 9.2 akan diperbaiki keesokan harinya. Pada 21 Oktober rilis perbaikannya keluar: PHP 8.5.12, 8.4.27, 8.3.36, dan 8.2.35.

Server produksi kami menjalankan Ubuntu 24.04 dengan Nginx dan PHP-FPM, dengan PHP 8.4 dan 8.5 terpasang berdampingan. Proses upgrade-nya sendiri hanyalah update paket biasa. Pekerjaan yang sesungguhnya justru datang setelahnya.

Memeriksa PHP yang benar-benar melayani pengunjung

Perintah php -v hanya menunjukkan versi PHP untuk command line. Sementara itu, website dilayani oleh PHP-FPM, yang bisa saja berupa binary lain atau bahkan versi lain. Karena itu kami memeriksanya satu per satu: PHP CLI, setiap layanan PHP-FPM, dan versi mana yang benar-benar dituju Nginx. PHP CLI yang sudah ter-patch belum membuktikan apa-apa.

Menemukan masalah lain yang tidak terkait CVE

Saat menelusuri asal paket PHP, kami mendapati ada dua sumber paket (repository) yang tumpang tindih di server. Versi yang sudah diperbaiki sebenarnya sudah terpasang, jadi ini bukan celah keamanan. Namun ketidakrapian seperti ini membuat update berikutnya lebih rumit. Kami menanganinya sebagai pekerjaan maintenance tersendiri: perubahan disimulasikan dulu, baru diterapkan, sampai seluruh paket berasal dari satu sumber.

Memisahkan kedua pekerjaan ini penting. Target keamanannya sudah tercapai begitu versi yang aman berjalan. Merapikan repository adalah pekerjaan bersih-bersih, dan direncanakan serta diuji sebagaimana mestinya.

Verifikasi ulang setelah restart

Update yang sama juga memasang kernel baru, sehingga server perlu di-restart. Setelah server menyala kembali, kami memeriksa lagi: Nginx dan kedua layanan PHP-FPM berjalan, versi PHP sesuai, tidak ada layanan yang masih memakai binary lama, dan aplikasi publik merespons dengan normal.

Pesan "berhasil" dari installer bukanlah bukti. Bukti yang sebenarnya adalah layanan yang berjalan, versi yang tepat, dan aplikasi yang menjawab permintaan pengguna.

Laravel: Perbaikannya Sudah Ada Sebelum Diumumkan

Pola advisory Laravel berbeda. Perbaikannya sudah dirilis pada 25 Agustus 2026 di Laravel 12.68.0, 13.27.0, dan 13.29.0, sebagai bagian dari update versi biasa. Rincian keamanannya baru diumumkan pada 19 Oktober.

• CVE-2026-114509 berstatus kritis (CVSS v4 9.2). Celah ini menyerang aplikasi yang memakai guard autentikasi berbasis token bawaan Laravel dengan database MySQL atau MariaDB, dan bisa membuat proses login dilewati.
• CVE-2026-114508 berstatus sedang (CVSS v3.1 6.5). Namun dampaknya adalah penghapusan data tanpa izin, dan tidak ada pemilik bisnis yang akan menganggapnya "sedang" kalau itu menimpa datanya.

Kami memperbarui framework di aplikasi Laravel yang kami kelola ke rilis yang sudah memuat kedua perbaikan, lalu memastikan aplikasinya tetap berjalan seperti seharusnya.

Linimasa ini menyimpan pelajarannya sendiri. Aplikasi yang rutin memperbarui dependensinya sudah terlindungi hampir dua bulan sebelum ada yang tahu masalahnya. Aplikasi yang dependensinya dibekukan justru langsung terbuka begitu detail celahnya dipublikasikan. Update rutin memang tidak terlihat istimewa, tetapi sering kali itulah alasan sebuah advisory berlalu tanpa drama.

Node.js: Memutuskan Tidak Perlu Bertindak Juga Sebuah Keputusan

Rilis keamanan Node.js pada 21 Oktober memperbaiki sepuluh celah di semua jalur rilis yang masih didukung, dengan versi perbaikan 26.12.1, 24.22.1, dan 22.23.4. Yang paling serius, CVE-2026-111497, berpotensi memungkinkan eksekusi kode jarak jauh melalui proses dekompresi Brotli.

Node.js tidak termasuk runtime proyek-proyek yang kami kelola, jadi tidak ada yang perlu di-patch. Namun itu tidak berarti advisory-nya diabaikan. Advisory tersebut dibaca, dicocokkan dengan inventaris, lalu dicatat sebagai tidak relevan beserta alasannya.

Catatan itu berguna. Kalau klien bertanya apakah sistemnya terdampak, jawabannya sudah tertulis. Kalau suatu saat Node.js ditambahkan ke sebuah proyek, catatan itu langsung mengingatkan bahwa keputusan ini perlu ditinjau ulang.

Kernel Ubuntu: Ketika Patch-nya Belum Ada

Jenis advisory yang paling sulit adalah yang belum punya perbaikan. CVE-2026-98432 adalah celah kritis (CVSS 9.8) pada cara kernel Linux membangun koneksi TCP. Saat diumumkan, Canonical menandai perbaikan kernel untuk rilis Ubuntu yang masih didukung, termasuk 24.04, sebagai "work in progress". Belum ada laporan celah ini dieksploitasi.

Dalam situasi seperti ini tidak ada yang bisa dipasang, sehingga pekerjaannya berubah menjadi pemantauan. Sejak Oktober kami rutin memeriksa status perbaikannya, supaya kernel yang sudah diperbaiki bisa segera dipasang dan server di-restart begitu Canonical merilisnya. Sampai saat itu tiba, status yang jujur untuk advisory ini adalah "terdampak, perbaikan belum tersedia, sedang dipantau", bukan "sudah beres".

Apa Artinya bagi Pemilik Aplikasi

Anda tidak perlu mengikuti semua milis keamanan sendiri. Yang Anda perlukan adalah keyakinan bahwa ada pihak yang melakukannya untuk Anda, dengan cara kerja yang bisa Anda periksa. Inilah yang menurut kami layak diharapkan dari mitra maintenance mana pun, termasuk dari kami sendiri:

1. Mereka mengenal stack Anda. Mereka bisa menyebutkan sistem operasi, runtime, framework, dan versi yang dipakai aplikasi Anda tanpa menebak.
2. Mereka merespons per advisory, bukan per berita. Setiap advisory dicocokkan dengan stack Anda, lalu dimasukkan ke salah satu dari tiga kelompok: patch, tidak relevan, atau pantau.
3. Mereka memverifikasi, bukan sekadar memasang. Setelah patch, mereka memastikan versi yang benar-benar melayani pengguna, kondisi layanan, dan bahwa aplikasi tetap berfungsi.
4. Mereka memisahkan pekerjaan keamanan dari pekerjaan bersih-bersih. Masalah yang ditemukan di tengah jalan ditangani dengan sengaja, tidak dicampur ke dalam perubahan yang mendesak.
5. Mereka melaporkan apa yang dikerjakan. Laporan singkat berisi setiap advisory, relevansinya bagi Anda, tindakan yang diambil, dan buktinya sudah cukup, termasuk advisory yang ternyata tidak relevan.
6. Mereka menjaga dependensi tetap mutakhir di luar masa genting. Update rutin itulah yang membuat banyak advisory berlalu tanpa insiden.

Kalau Anda belum bisa mendapatkan jawaban yang jelas atas poin-poin ini dari pihak yang memelihara aplikasi Anda sekarang, sebaiknya hal itu dibereskan sebelum bulan sibuk berikutnya datang.

Rincian Teknis di qadrlabs

Untuk administrator dan developer yang ingin membaca detail teknisnya, setiap advisory dibahas lengkap di qadrlabs (dalam bahasa Inggris):

• PHP Critical RCE Vulnerabilities CVE-2026-109618 and CVE-2026-109619: What Happened and How to Protect Your Servers
• How We Patched Critical PHP RCE Vulnerabilities on an Ubuntu 24.04 Server
• Laravel Security Advisories CVE-2026-114509 and CVE-2026-114508
• Node.js October 2026 Security Release: Brotli RCE (CVE-2026-111497) and Nine More Fixes

Penutup

Peringatan keamanan akan terus berdatangan, sering kali beberapa sekaligus. Yang membedakan minggu yang menegangkan dari minggu yang terkendali jarang sekali hanya soal kemampuan teknis. Kuncinya adalah tahu persis apa yang Anda jalankan, memutuskan dengan tenang apa arti setiap advisory bagi sistem itu, lalu memastikan perbaikannya benar-benar terpasang.

Kalau Anda belum yakin bagaimana aplikasi Anda akan menghadapi gelombang advisory berikutnya, kami siap memeriksanya bersama Anda. Hubungi kami dan ceritakan aplikasi Anda berjalan di atas apa; kami akan mulai dari sana.