Pada 21 Oktober 2026, tiga pengumuman keamanan keluar dalam waktu berdekatan: dua celah PHP dengan skor 9,2, satu celah GitLab dengan skor 10,0, dan satu rilis Node.js yang memperbaiki celah High termasuk decoder Brotli. Kalau kamu satu-satunya orang yang mengurus server hari itu, urutan kerja menentukan apakah kamu selesai sebelum sore atau panik sampai malam.

Panduan ini menyusun urutan yang bisa dieksekusi dalam 30 menit untuk satu orang, dengan asumsi kamu sudah punya akses ke server dan daftar layanan yang kamu kelola.

Menit 0–5: Ukur Dulu, Jangan Langsung Patch

Sebelum menyentuh apa pun, kumpulkan empat angka. Ini yang nanti menentukan urutan:

  1. Versi PHP di setiap server (jalankan php -v di shell, atau lihat halaman phpinfo di lingkungan uji).
  2. Versi Node.js (node -v).
  3. Versi GitLab, kalau kamu menjalankan yang self-managed (buka halaman Help di instalasimu, atau cat /opt/gitlab/version-manifest.txt).
  4. Mana dari layanan itu yang bisa dijangkau internet tanpa VPN.

Tulis keempatnya di satu tempat. Tanpa daftar ini, 30 menit berikutnya akan habis untuk mencari tahu apa yang sebenarnya kamu punya.

Menit 5–15: Patch yang Paling Terbuka Lebih Dulu

Urutan berdasarkan paparan, bukan berdasarkan skor:

1. PHP di server publik dengan mod_php. Ini yang paling mendesak, karena eksploitasi pada mod_php bisa terjadi sebelum kode aplikasi berjalan. Kalau kamu memakai PHP-FPM, tetap patch, tapi urutannya setelah mod_php. Untuk pengguna shared hosting, langkahnya berbeda: cek panel hosting dan lihat versi PHP yang aktif. Detailnya ada di artikel PHP2Shell.

2. GitLab self-managed yang punya jalur login publik. Celahnya tanpa autentikasi, jadi tidak perlu akun untuk mencoba. Perhatikan bahwa versi 19.4.3 dan 19.3.6 menjalankan migrasi basis data yang butuh downtime di single-node. Backup dulu, baru upgrade. Rincian versi perbaikan dan aturan deteksinya ada di artikel GitLab CVE-2026-110264.

3. Node.js. Naik ke 26.12.1, 24.22.1, atau 22.23.4 sesuai jalur. Ini biasanya paling cepat karena cukup mengubah tag image atau versi di build config.

Menit 15–25: Verifikasi, Bukan Anggap Selesai

Bagian ini yang paling sering dilewati, dan yang paling sering membuat orang mengira sudah aman padahal belum. Untuk setiap layanan, lakukan tiga cek:

Cek nomor versi setelah service restart. Jalankan ulang perintah versi. Pada PHP, pastikan php -v menunjukkan versi patch. Pada container, pastikan container baru benar-benar jalan, bukan image lama yang gagal diganti. Pada GitLab, buka halaman Help dan baca versinya di sana, bukan dari catatan upgrade.

Cek satu alur nyata. Buka halaman utama, coba login, kirim satu form. Untuk aplikasi Node.js yang menerima payload terkompresi, uji satu request dengan header Accept-Encoding: br dan pastikan responsnya normal.

Cek log error. Setelah patch, ada dua pola yang perlu dicari: error baru yang belum pernah muncul sebelumnya, dan crash proses yang berulang. Crash worker pada GitLab bahkan punya aturan deteksi khusus ("Onigmo native worker crash") yang bisa kamu pasang.

Menit 25–30: Catat dan Komunikasikan

Buat satu catatan singkat berisi: nama layanan, versi sebelum, versi sesudah, waktu eksekusi, dan siapa yang mengerjakan. Catatan ini terasa sepele, tetapi tiga hal bergantung padanya:

Terakhir, kabari pengguna kalau ada downtime, sekecil apa pun. Satu pesan singkat "server diperbarui 10 menit, sudah normal kembali" jauh lebih baik daripada pengguna menemukan sendiri halaman error-nya.

Kalau 30 Menit Tidak Cukup

Realistis, tiga layanan sekaligus sering butuh lebih dari 30 menit, apalagi kalau ada migrasi basis data. Kalau itu kasusmu, pakai aturan ini: kerjakan yang paling terbuka sampai selesai dan terverifikasi, jangan mengerjakan tiga-tiganya setengah jalan. Server yang versinya sudah berubah dan sudah diuji jauh lebih berharga daripada tiga server yang sedang dalam proses upgrade bersamaan saat jam sibuk.

Untuk urutan prioritas yang lebih ringkas bagi tim satu orang, lihat Tim kecil: urutan patch kalau waktu cuma satu jam.

Pertanyaan yang Sering Muncul

Apakah harus patch hari ini juga? Untuk PHP dengan mod_php yang terbuka ke internet, ya. Untuk GitLab dan Node.js, prioritaskan yang bisa dijangkau publik, lalu selesaikan dalam 24–48 jam.

Apakah perlu mematikan layanan selama patch? PHP dan Node.js biasanya bisa tanpa downtime kalau kamu punya lebih dari satu instance. GitLab dengan migrasi basis data di single-node butuh downtime terencana.

Bagaimana kalau patch membuat aplikasi error? Rollback ke versi sebelumnya, lalu perbaiki di lingkungan uji. Jangan biarkan server tetap di versi rentan sambil menunggu perbaikan aplikasi; pindahkan dulu ke konfigurasi yang paparannya lebih kecil.

Penutup

Tiga pengumuman dalam dua hari bukan hal aneh, dan ke depan akan makin sering. Yang membuat perbedaan bukan keberanian mengambil risiko, tapi punya urutan yang sudah dipikirkan sebelum panik. Ukur lima menit, patch sepuluh menit berdasarkan paparan, verifikasi sepuluh menit, catat lima menit. Selesai, dan besok kamu masih punya waktu untuk pekerjaan lain.