Siapa yang perlu memeriksa
Pemeriksaan ini relevan untuk hampir semua situs. Situs PHP adalah kelompok terbesar dan paling mendesak, karena celah PHP2Shell menyerang interpreter itu sendiri. Situs Next.js dan Node.js menyusul, lalu situs yang memakai perkakas Python, runtime Java, dan platform seperti GitLab atau SAP. Jika Anda tidak yakin teknologi apa yang dipakai situs Anda, tanyakan kepada pengembang atau penyedia hosting Anda. Ketidakpastian adalah alasan untuk memeriksa, bukan alasan untuk menunda.
Checklist PHP, yang utama
- Versi PHP: bandingkan versi yang berjalan dengan garis perbaikan 8.2.35, 8.3.36, 8.4.27, atau 8.5.12, sesuai lini versi yang dipakai.
- Restart pekerja: setelah pembaruan, restart semua pekerja PHP, karena pekerja lama yang masih berjalan tetap menjalankan kode yang rentan.
- Matikan session.upload_progress: set session.upload_progress.enabled=0, karena fitur lama ini adalah salah satu jalur masuk yang terkonfirmasi ke CVE-2026-109619, dan mematikannya menutup jalur tersebut bahkan pada sistem yang sudah diperbaiki.
- Situs lama: PHP 8.1 dan yang lebih lama tidak mendapat perbaikan resmi. Rencanakan peningkatan versi atau backport, dan perlakukan situs tersebut sebagai berisiko sampai saat itu.
- Tanda penyusupan: periksa pengguna admin, plugin, dan berkas yang tidak Anda tambahkan, terutama bila situs terekspos sebelum 21 Oktober, karena serangan awal sudah terlihat sebelum perbaikan tersedia.
Checklist JavaScript: Next.js dan Node.js
- Versi Next.js: bandingkan dengan garis perbaikan 16.4.1 atau 15.5.28, sesuai lini versi yang dipakai.
- Versi Node.js: periksa runtime yang dipakai di produksi, bukan hanya di laptop pengembang, dan bandingkan dengan 26.12.1, 24.22.1, atau 22.23.4.
- Runtime hosting: bila situs dihosting di platform terkelola, konfirmasikan runtime apa yang benar-benar berjalan, karena platform bisa memakai versi yang berbeda dari yang Anda kira.
- Setelah pembaruan: bangun ulang dan terbitkan ulang situs, lalu periksa kembali versinya, karena pembaruan yang tidak sampai ke produksi sama dengan tidak diperbarui.
Checklist Python dan Java
- Python: perbarui pip ke 26.2.2 atau lebih baru, bersama certifi dan toko kepercayaan, agar kunci eMudhra yang lemah tidak lagi dipercaya.
- SAP Cloud SDK for Python: bila memakai SAP BTP, pastikan SDK berada pada versi 0.45.2 atau lebih baru, tempat pemeriksaan validasi subdomain sudah ada.
- LiteLLM: bila rilis 1.107.0 sempat berjalan, pasang ulang versi 1.106.2 dan putar semua kredensial yang bisa dijangkau, karena rilis tersebut mencuri kredensial.
- Java: terapkan pembaruan triwulanan Oracle bulan Oktober, dan perbarui toko kepercayaan Java untuk tidak lagi mempercayai kunci eMudhra.
- SAP: terapkan catatan keamanan Oktober untuk NetWeaver dan komponen manufaktur, termasuk celah otorisasi pada server aplikasi Java.
Checklist rantai pasok dan kredensial
- GitLab self-managed: periksa terhadap CVE-2026-110264 dan terapkan perbaikan keamanan 21 Oktober.
- Paket npm: bila tensorlake 0.5.144 sempat berjalan, kembali ke 0.5.143 dan bangun ulang mesin yang terdampak.
- CLI OVHcloud: hapus binari versi 0.11.0 sampai 0.15.0, pasang 0.16.0, dan putar kredensial cloud serta kunci SSH.
- WordPress: periksa jendela unduhan Rank Math PRO 3.0.123, dan bila memakai UpdraftCentral, hapus kunci UpdraftCentral lalu periksa plugin dan pengguna admin yang tidak Anda tambahkan.
- Platform: ikuti pemberitahuan vendor untuk Railway, Zeabur, OpenCode, dan ConnectWise, dan putar semua variabel lingkungan, kunci, dan kredensial yang disebut dalam pemberitahuan tersebut.
Jika pembaruan tidak bisa langsung dilakukan
Kadang pembaruan tertunda karena alasan yang sah: ketergantungan yang belum kompatibel, jendela perubahan yang terbatas, atau proses persetujuan. Dalam situasi itu, yang terpenting adalah kejujuran tentang statusnya: catat bahwa situs masih berada di bawah garis perbaikan, batasi paparan yang tidak perlu, dan tetapkan tanggal pasti untuk pembaruan. Untuk PHP, badan keamanan Inggris NCSC bahkan menyarankan mempertimbangkan menonaktifkan sistem sampai perbaikan penuh bisa dilakukan.
Yang tidak boleh dilakukan adalah menganggap masalah selesai karena belum terjadi apa-apa. Kerentanan yang sudah diumumkan publik tidak menjadi lebih aman hanya karena belum dieksploitasi di situs Anda.
Setelah checklist selesai
Simpan hasil pemeriksaan ini. Catat versi sebelum dan sesudah, tanggal pembaruan, dan siapa yang memverifikasinya. Dokumentasi singkat ini berguna dua kali: saat ada audit berikutnya, dan saat gelombang berikutnya datang, karena gelombang berikutnya pasti datang.
Jika Anda tidak memiliki akses ke proyek atau hosting situs Anda, teruskan checklist ini kepada pihak yang memilikinya. Pertanyaan yang tepat, diajukan kepada orang yang tepat, sering kali adalah seluruh perbaikan yang dibutuhkan.
