Cara Mengecek Server Terdampak PHP2Shell: Panduan Patch untuk Admin dan Pengguna Hosting

Cara cek PHP2Shell di server Anda dimulai dari satu pertanyaan sederhana: versi PHP mana yang benar-benar melayani permintaan web? Panduan ini membantu admin dan pengguna hosting menemukan PHP yang terdampak CVE-2026-109618 dan CVE-2026-109619, menambalnya, lalu memastikan patch benar-benar aktif. Informasi per 29 Oktober 2026.

Ringkasan: apa yang sedang dicek pada PHP2Shell

PHP2Shell adalah dua celah kritis di mesin PHP yang dapat berujung pada eksekusi kode jarak jauh tanpa autentikasi. Celah ini sudah dieksploitasi dan masuk katalog CISA KEV pada 26 Oktober 2026. Versi yang diperbaiki adalah 8.5.12, 8.4.27, 8.3.36 dan 8.2.35. Penjelasan lengkap tentang celahnya ada di artikel PHP2Shell: celah kritis PHP dan cara mengamankannya. Di sini kita fokus pada pemeriksaan praktis.

Cara cek PHP2Shell langkah demi langkah

Langkah 1: temukan semua PHP, bukan hanya satu

Banyak organisasi menjalankan lebih dari satu runtime PHP tanpa sadar. Catat semuanya:

• PHP di server web utama (Apache mod_php, PHP-FPM, php-cgi, FrankenPHP, LiteSpeed).
• PHP di dalam container dan image Docker lama yang masih berjalan.
• PHP yang dibawa panel hosting, misalnya cPanel atau Plesk, yang punya jalur pembaruan sendiri.
• Aplikasi yang membundel PHP, seperti perangkat jaringan atau appliance. Palo Alto Networks, misalnya, menyatakan semua versi PAN-OS dan Panorama terdampak per 22 Oktober dan belum ada rilis perbaikan saat itu. Cek advisori vendor terbaru.
• Server staging, server lama, dan situs kampanye yang terlupakan.

Prioritaskan yang menghadap internet. Kerangka kerjanya sama dengan patch management berbasis risiko: aset yang terpapar dan sudah dieksploitasi didahulukan.

Langkah 2: periksa versi yang melayani web

Versi pada perintah php -v (CLI) bisa berbeda dari versi yang dipakai PHP-FPM atau Apache. Periksa keduanya. Contoh perintah umum di Linux, dijalankan di server milik Anda sendiri:

php -v
php-fpm -v        # nama binary dapat berbeda, misalnya php-fpm8.3
apachectl -M | grep -i php
dpkg -l | grep -i php     # Debian dan Ubuntu
rpm -qa | grep -i php     # RHEL dan turunannya

Pada Windows, build ulang tanggal 26 Oktober diberi akhiran -1 (misalnya 8.4.27-1) dan memuat perbaikan tambahan untuk celah Brotli, sedangkan versi runtime PHP-nya tidak berubah, menurut pengumuman PHP. Bandingkan hasil dengan versi perbaikan di atas. PHP 8.1 dan yang lebih lama tidak lagi menerima pembaruan dari proyek PHP, sehingga tidak ada rilis resmi untuk cabang 7.4, 8.0 dan 8.1. Tim keamanan PHP hanya menyediakan backport source minimal untuk ketiga cabang itu bagi yang mengompilasi sendiri; selebihnya gunakan paket backport dari distribusi atau vendor LTS, atau pindah ke cabang yang didukung. PHP 7.3 dan lebih lama tidak punya perbaikan dari proyek PHP.

Langkah 3: waspadai backport distribusi

Distribusi Linux sering menambal tanpa menaikkan nomor versi, sehingga PHP bisa tampak tua padahal sudah aman. Sebaliknya, pemeriksaan berbasis header HTTP tidak bisa melihat backport. Pemindaian eksternal terhadap situs pemerintah Indonesia yang dilaporkan media memiliki keterbatasan yang sama. Jadi jangan menyimpulkan dari nomor versi saja. Periksa changelog paket dari vendor distribusi Anda dan cari referensi CVE-2026-109618 dan CVE-2026-109619, atau baca advisori keamanan distribusi tersebut. Repositori pihak ketiga juga bisa tertinggal: repositori Remi (rpms.remirepo.net) belum memiliki pembaruan pada 21 Oktober, menurut Help Net Security. Cek status terbarunya sebelum mengandalkannya.

Langkah 4: untuk pengguna shared hosting dan cPanel

Jika Anda tidak punya akses root, Anda tidak bisa mengganti PHP sendiri. Yang bisa dilakukan:

1. Tanyakan kepada penyedia hosting secara tertulis: apakah PHP di server saya sudah diperbarui untuk CVE-2026-109618 dan CVE-2026-109619, dan kapan.
2. Jika panel menyediakan pemilih versi PHP per domain, pilih cabang yang masih didukung dan sudah diperbarui, lalu uji situs Anda.
3. Simpan salinan cadangan situs dan basis data di luar server hosting.
4. Pantau situs Anda: file baru yang tidak dikenal, akun admin baru, atau perubahan konten mencurigakan.

Langkah 5: WAF sebagai penahan sementara, bukan solusi

Aturan WAF dapat mengurangi risiko selagi Anda menjadwalkan patch. Cloudflare menyediakan aturan awal untuk semua paket, tetapi hanya melindungi lalu lintas yang melewati Cloudflare. Server yang bisa diakses langsung lewat IP-nya tetap terbuka. CISA menyebut WAF hanya mungkin memberi sebagian perlindungan, dan meminta sistem berbasis PHP yang belum bisa diperbarui dimatikan sampai diperbarui. Lihat peringatan CISA untuk rincian resminya.

Langkah 6: patch, restart, lalu verifikasi

• Terapkan pembaruan dari repositori distribusi atau vendor Anda.
• Restart semua worker. Paket baru tidak mengubah proses yang sudah berjalan. Muat ulang PHP-FPM dan Apache, atau bangun ulang dan deploy ulang container.
• Verifikasi. Pastikan proses worker dimulai setelah waktu pembaruan paket, dan versi yang dilaporkan runtime web sesuai. Jangan membiarkan halaman phpinfo terbuka untuk publik.
• Catat regresi. PHP 8.4.27 dan 8.5.12 dilaporkan bisa membuat sebagian aplikasi pengguna SimpleXML crash. Jangan turun versi. Pantau log, dan pasang rilis perbaikan saat tersedia.
• Periksa tanda kompromi. Patch tidak menghapus web shell. Cari file baru di web root, proses PHP yang menjalankan shell atau membuat koneksi keluar, akun dan cron job baru, serta request multipart yang tidak wajar. Server yang terbuka sejak 17 Oktober layak diperiksa lebih dalam. Panduan hardening server Linux membantu menyusun ulang konfigurasi yang lebih ketat.

Cek PHP2Shell juga di container, CI, dan sistem bayangan

Image container yang dibangun bulan lalu tetap membawa PHP lama sampai dibangun ulang, sekalipun host-nya sudah diperbarui. Periksa juga registry internal, pipeline CI yang memakai image PHP sebagai runner, dan environment staging yang sengaja dibiarkan terbuka. Cara paling andal adalah membuat satu daftar aset PHP bersama pemiliknya, mencatat versi dan tanggal patch tiap aset, lalu meninjau ulang daftar itu setiap kali rilis keamanan PHP terbit. Daftar seperti ini juga mempercepat Anda ketika celah berikutnya muncul.

Baca juga: FortiBleed dan Bypass SSO FortiCloud: Langkah Wajib bagi Pengguna Fortinet.

Pertanyaan yang Sering Diajukan

Bolehkah saya memindai server pihak lain untuk mengecek PHP2Shell?

Tidak tanpa izin tertulis. Pindai hanya aset milik Anda sendiri atau yang ada dalam lingkup pengujian yang disepakati. Akses atau percobaan akses ilegal dapat dipidana berdasarkan Pasal 332 KUHP yang berlaku sejak 2 Januari 2026.

Versi PHP saya sudah 8.3.36. Apakah masih perlu restart?

Ya, bila pembaruan baru terpasang. Worker yang berjalan sebelum pembaruan tetap memakai kode lama sampai di-restart.

Apakah pengaturan memory_limit atau upload_progress cukup?

Tidak. Advisori PHP menyebut pengaturan seperti memory_limit=-1 dan session.upload_progress.enabled=0 hanya mengurangi jalur serangan tertentu, dan menegaskan tidak ada perubahan konfigurasi yang menutup celah sepenuhnya. Perbaikan lengkapnya adalah pembaruan.

Kesimpulan

Memeriksa PHP2Shell bukan sekadar menjalankan satu perintah: temukan semua runtime, bandingkan dengan versi perbaikan atau backport distribusi, patch, restart, lalu periksa tanda kompromi. Bila Anda butuh bantuan memetakan aset PHP atau memverifikasi hasil patch, tim Linuxhackingid menyediakan asesmen lewat halaman layanan kami.