Setelah pengumuman PHP2Shell, pertanyaan yang paling sering muncul dari pemilik situs bukan "apa itu CVE", melainkan "situs WordPress saya kena atau tidak". Jawaban singkatnya: CMS tidak menentukan. Yang menentukan adalah versi PHP yang menjalankan situs itu di belakang layar.
WordPress, Drupal, dan Joomla semuanya ditulis dalam PHP dan dijalankan oleh PHP. Kalau versi PHP di servermu rentan, situsmu rentan, apa pun CMS dan apa pun plugin yang kamu pakai. Sebaliknya, kalau PHP sudah dipatch, situsmu aman dari celah ini meski belum update plugin.
Versi PHP yang Rentan dan yang Aman
Perbaikan resmi dari tim PHP tersedia di empat cabang:
- 8.5.x → aman mulai 8.5.12
- 8.4.x → aman mulai 8.4.27
- 8.3.x → aman mulai 8.3.36
- 8.2.x → aman mulai 8.2.35
Kalau situsmu masih di PHP 7.4 sampai 8.1, tidak ada rilis resmi untuk cabang itu. Tim PHP hanya menerbitkan backport kode sumber, dan memasangnya butuh kerja teknis. Untuk pemilik situs, jalur paling realistis adalah naik ke cabang yang masih didukung.
Kalau versinya 5.4 sampai 7.3, cabangnya sudah end-of-life dan tidak ada perbaikan. Situs dengan PHP segitu bukan hanya rentan pada celah ini, tapi juga pada celah lain yang sudah lama diketahui publik.
Cara Cek Tanpa Akses Root
Banyak pemilik situs tidak punya akses SSH. Ada tiga cara yang bisa dipakai:
1. Panel hosting. Buka cPanel, Plesk, atau panel penyedia hostingmu. Hampir semuanya menampilkan pemilih versi PHP per domain. Ini cara tercepat dan paling bisa diandalkan.
2. Bantuan internal WordPress. Di dasbor WordPress, buka menu Site Health (Alat → Site Health → Info) lalu cari bagian Server. Versi PHP biasanya tercantum di sana. Di beberapa versi, informasinya ada di halaman Site Health → Info → Server.
3. Berkas info PHP sementara. Kalau kamu punya akses file manager, unggah satu file berisi <?php phpinfo(); ?>, buka di browser, catat versinya, lalu hapus segera. File ini membocorkan banyak informasi server, jadi jangan dibiarkan lebih dari beberapa menit.
Kalau Kamu di Shared Hosting
Ini kasus paling umum untuk situs kecil dan menengah, dan paling sering membuat orang salah paham. Kamu tidak bisa memperbarui PHP sendiri; penyedia yang menentukannya.
Langkah yang bisa kamu lakukan:
- Pilih versi PHP tertinggi yang tersedia di panel. Kalau panel menawarkan 8.4 atau 8.5, pindahkan ke sana.
- Setelah pindah versi, buka situsmu dan uji halaman penting: beranda, halaman produk, form kontak, halaman checkout.
- Kalau ada plugin yang error setelah pindah versi, itu masalah kompatibilitas plugin, bukan alasan kembali ke versi rentan. Cari plugin pengganti atau minta pengembangnya memperbaiki.
- Kalau panel belum menyediakan versi yang dipatch, kirim tiket ke penyedia dan minta jadwal tertulis.
Kalau penyedia tidak bisa memberi kepastian, pertimbangkan memindahkan situs. Ini keputusan bisnis, bukan keputusan teknis: situs yang tidak bisa dipatch adalah risiko yang menumpuk setiap bulan.
Untuk Drupal dan Joomla
Prinsipnya sama, dan pengecekannya juga sama. Drupal sejak versi 8 mensyaratkan PHP yang cukup baru, jadi instalasi Drupal modern biasanya berada di cabang yang masih didukung. Yang perlu diperiksa justru instalasi lama yang masih berjalan di PHP 7.x karena "masih jalan baik-baik saja".
Joomla punya rentang dukungan PHP yang lebih lebar, sehingga lebih mudah tertinggal di versi lama. Cek juga status dukungan versi Joomla-mu; versi Joomla yang sudah end-of-life biasanya juga menahanmu di PHP lama, karena versi PHP baru butuh Joomla baru.
Yang Tidak Menyelesaikan Masalah
Beberapa hal sering diusulkan tetapi tidak menutup celah ini:
- Mengganti password admin. Celah ini terjadi sebelum aplikasi berjalan; tidak ada kredensial yang dicek.
- Memasang plugin keamanan. Plugin berjalan di dalam PHP. Kalau PHP-nya sudah diambil alih, plugin tidak bisa menolong.
- Mengaktifkan CDN. CDN membantu menahan sebagian lalu lintas, tapi tidak memperbaiki kode di servermu.
- Menonaktifkan XML-RPC atau file tertentu. Celah ini di inti bahasa, bukan di fitur aplikasi.
Satu-satunya perbaikan yang menutup celah ini adalah versi PHP yang dipatch. Sisanya hanya mengurangi paparan.
Urutan Praktis untuk Pemilik Situs
- Cek versi PHP hari ini lewat panel hosting.
- Kalau di bawah versi patch dan panel menyediakan versi lebih baru, pindahkan sekarang.
- Uji empat halaman penting setelah pindah.
- Catat versi sebelum dan sesudah.
- Kalau tidak tersedia, buka tiket ke penyedia dan simpan nomor tiketnya.
Untuk penjelasan teknis celahnya, baca PHP2Shell: dua celah kritis PHP. Kalau istilah seperti RCE dan mod_php masih terasa asing, ada panduan istilah keamanan sederhana. Kalau kamu mengelola beberapa situs sekaligus, urutan kerja yang lebih luas ada di panduan patch 30 menit.
Pertanyaan yang Sering Muncul
Situs saya kecil, apakah tetap perlu? Pemindaian berjalan otomatis dan tidak memilih ukuran situs. Situs kecil sering jadi target justru karena jarang dipantau.
Apakah pindah versi PHP merusak tampilan? Bisa, kalau ada plugin atau tema yang memakai fungsi yang sudah dihapus. Uji dulu di lingkungan uji kalau tersedia; kalau tidak, siapkan langkah rollback lewat panel.
Bagaimana kalau hosting mengunci versi PHP? Minta alasan tertulis dan jadwal. Kalau tidak ada, itu sinyal untuk mempertimbangkan pindah penyedia.
Apakah WordPress akan merilis perbaikan sendiri? Tidak ada yang bisa mereka tambal, karena celahnya ada di PHP, bukan di WordPress.
Komentar 0