PHP2Shell: server sudah di-patch, tapi apakah sempat dibobol?

Jawaban singkat

Patch menutup celahnya, tapi tidak menghapus apa pun yang mungkin sudah masuk sebelum patch dipasang (Kompas Tekno). Jadi setelah update, pertanyaannya berubah dari "apakah saya rentan?" menjadi "apakah saya sempat kena?".

Tidak ada yang bisa menjawabnya dari luar. Anda perlu memeriksa log, file, proses dan akun di server Anda sendiri, mulai dari 17 Oktober 2026, tanggal percobaan eksploitasi paling awal yang diketahui (AWS). Halaman ini berisi apa yang perlu dicari, dari sumber mana, dan apa yang dilakukan jika menemukan sesuatu.

Belum yakin server Anda sudah di-patch? Mulai dari Apakah website saya terdampak PHP2Shell?. Versi paket distro bisa terlihat lama padahal sudah di-patch, jadi cek di tracker distro Anda, jangan hanya membandingkan angka versi.

Sudah ada yang benar-benar kena?

Yang pasti: ada banyak percobaan serangan. Amazon mencatat percobaan pertama di honeypot-nya pada 17 Oktober, empat hari sebelum pengumuman, dan menyebut PHP2Shell kini menghadapi "broad exploitation attempts in the wild". Untuk percobaan sebelum pengumuman, Amazon menulis bahwa belum jelas apakah ada yang akan berhasil di sistem sungguhan (AWS).

Soal serangan yang berhasil, per 21 Oktober watchTowr mengatakan belum melihat satu pun, sambil memperkirakan itu tidak akan bertahan lama (SecurityWeek). Kami belum menemukan sumber publik yang mengonfirmasi website tertentu dibobol lewat PHP2Shell.

Di Indonesia, sebuah postingan Threads pada 23 Oktober ramai dibicarakan: penulisnya mengecek server sendiri setelah pengumuman PHP dan menemukan server itu sudah kena root compromise. Postingan itu tidak menyebut bahwa PHP2Shell penyebabnya. Pelajarannya tetap sama: cek dulu, jangan berasumsi.

Rincian kronologi dan mitos yang beredar ada di PHP2Shell: mitos dan fakta.

Sebelum mulai: simpan log dulu

Perusahaan teknologi PXL, yang dikutip Kompas Tekno, menyarankan langkah pertama berupa menyimpan log akses dan log error server sebelum log terhapus atau server diubah (Kompas Tekno). Huntress juga menyarankan menyimpan log web server dan log PHP (Huntress). Salin log ke tempat lain sebelum Anda mulai membersihkan apa pun.

Langkah 1: cari jejak request serangan

Amazon menyarankan mencari request POST yang memuat string PHP_SESSION_UPLOAD_PROGRESS di form upload, dan meninjau log web server untuk aktivitas mencurigakan (AWS).

Perhatikan: string itu ada di isi form, sedangkan format log akses standar hanya mencatat baris request (metode, path, protokol), bukan isi request (dokumentasi Apache). Jadi log akses biasa kemungkinan besar tidak memuatnya. Cari di log yang merekam isi request, misalnya log WAF, jika Anda punya.

Amazon juga menerbitkan alamat IP yang terlihat dalam percobaan serangan (AWS):

Menurut Amazon, alamat-alamat ini termasuk infrastruktur anonimisasi yang dipakai bersama, jadi tidak khusus untuk serangan ini. Amazon menyarankan menyelidiki setiap kemunculannya, bukan memblokirnya (AWS). Artinya, kalau salah satunya muncul di log Anda, itu alasan untuk memeriksa lebih jauh, bukan bukti bahwa server sudah dibobol.

Contoh pencarian di VPS (sesuaikan path log dengan server Anda):

grep -E '103\.216\.220\.92|31\.223\.184\.166|37\.19\.200\.5|134\.209\.159\.64|103\.114\.163\.188|95\.217\.98\.37' /var/log/nginx/access.log* /var/log/apache2/access.log*

Untuk log yang sudah dikompres (.gz), pakai zgrep dengan pola yang sama.

Langkah 2: proses yang dijalankan PHP

Amazon menyarankan mengecek eksekusi proses yang tidak terduga di server aplikasi web (AWS). Huntress lebih spesifik: waspadai worker PHP yang menjalankan shell, interpreter atau alat unduh (Huntress).

Di VPS, lihat proses yang berjalan sebagai user web server beserta induknya:

ps -ef --forest | less       # cari shell, curl, wget, python atau perl di bawah php-fpm, apache2 atau httpd
ps -u www-data -f            # ganti www-data dengan user web server Anda (mis. apache, nginx)

Perintah ini hanya menunjukkan proses yang sedang berjalan sekarang, bukan yang sudah selesai.

Advisory PHP menggambarkan dampak celah ini sebagai eksekusi kode dengan hak akses worker web (GHSA-6wmf). Jadi periksa juga apa saja yang bisa dibaca dan diubah oleh user tersebut.

Langkah 3: file baru atau berubah

• Amazon: cek modifikasi file yang tidak terduga di server aplikasi web (AWS).

• Huntress: cari webshell dan file baru di web root (Huntress).

• PXL, dikutip Kompas Tekno: cari file PHP asing, terutama di folder wp-content/uploads pada WordPress, dan file yang baru diubah sejak 20 Oktober 2026 (Kompas Tekno).

Contoh di VPS (ganti /var/www dengan folder website Anda). Kami pakai 17 Oktober supaya rentang AWS dan PXL sama-sama tercakup:

# file yang diubah sejak 17 Oktober 2026
find /var/www -type f -newermt '2026-10-17' -ls

# file PHP di folder upload WordPress (biasanya tidak ada)
find /var/www -path '*wp-content/uploads*' -name '*.php' -ls

Opsi -newermt membandingkan waktu modifikasi file dengan tanggal yang Anda tulis (manual find). Hasilnya juga akan memuat file yang Anda ubah sendiri, misalnya saat update. Periksa satu per satu file yang tidak Anda kenali.

Langkah 4: akun, cron dan kunci SSH

• Huntress: cron job, scheduled task dan akun baru (Huntress).

• PXL, dikutip Kompas Tekno: akun administrator yang tidak dikenal, tugas terjadwal, dan kunci SSH baru (Kompas Tekno).

Yang bisa dicek:

crontab -l -u www-data              # cron milik user web server
ls -la /etc/cron.d /var/spool/cron* # cron sistem
cat /root/.ssh/authorized_keys /home/*/.ssh/authorized_keys

Di aplikasi, cek daftar admin. Di WordPress: Pengguna, lalu saring peran Administrator.

Langkah 5: tanda lain

PXL juga menyarankan mewaspadai penggunaan CPU atau lalu lintas keluar server yang tiba-tiba naik (Kompas Tekno). Grafik monitoring dari penyedia VPS Anda bisa menunjukkan lonjakan ini sejak 17 Oktober.

Di shared hosting

Di shared hosting, Anda biasanya tidak bisa melihat proses atau log sistem. Yang masih bisa Anda lakukan sendiri lewat file manager dan dashboard aplikasi: cari file PHP di folder upload, file yang berubah sejak 17 Oktober, dan admin yang tidak dikenal (Langkah 3 dan 4). Untuk sisanya, minta ke penyedia hosting:

"Apakah server akun saya menerima request dari alamat IP yang diterbitkan Amazon untuk PHP2Shell (103.216.220.92, 31.223.184.166, 37.19.200.5, 134.209.159.64, 103.114.163.188, 95.217.98.37) sejak 17 Oktober 2026? Apakah ada request POST dengan string PHP_SESSION_UPLOAD_PROGRESS, atau proses PHP yang menjalankan shell di akun saya? Mohon kirimkan log akses dan error akun saya sejak 17 Oktober."

Jika Anda menemukan tanda kompromi

1. Isolasi server dan simpan log web server serta log PHP (Huntress).

2. Jangan hanya menghapus file asing. Menurut PXL, sistem perlu diperiksa dan dibersihkan menyeluruh, kata sandi dan kunci akses diganti, dan website dipulihkan dari cadangan yang bersih (Kompas Tekno). Peretas bisa memasang akses tersembunyi untuk masuk lagi meski celahnya sudah ditambal (sumber yang sama).

3. Cari backdoor. NCSC Inggris menyarankan memeriksa tanda kompromi dan mencari backdoor yang dipasang penyerang. Jika Anda tidak yakin bisa melakukannya sendiri, gunakan penyedia layanan respons insiden (NCSC).

4. Baru setelah itu, pastikan PHP sudah di-patch dan semua worker di-restart: langkahnya di sini.

Jika Anda tidak menemukan apa-apa

Itu kabar baik, tapi bukan jaminan. PXL mengingatkan bahwa PHP2Shell bisa dipakai untuk membaca data sensitif di memori tanpa meninggalkan file atau akun baru (Kompas Tekno). Peneliti Wiz menyebut memori itu bisa berisi password, token autentikasi, API key dan sertifikat (Wiz).

Karena itu, menurut rangkuman Kompas Tekno dari PXL dan Malwarebytes, pengelola yang masih memakai PHP rentan setelah 20 Oktober disarankan mengganti password database, kunci keamanan dan API key (Kompas Tekno).

Satu hal lagi: tim PHP menyarankan session.upload_progress.enabled=0 tetap dipasang sampai rilis reguler berikutnya, karena ada celah terkait yang jarang terjadi, CVE-2026-115560 (php.net). Cara memasangnya ada di halaman cek terdampak.

Ingin kami yang cek dan patch?

Kami sudah mengecek dan mem-patch host PHP yang kami kelola untuk klien (website WordPress, WooCommerce dan Moodle). Untuk server Anda, kami mengecek versi PHP, SAPI dan paket, lalu melakukan patch, upgrade atau backport (PHP 7.4–8.1), me-restart worker, dan mengecek tanda kompromi: proses PHP atau web server yang menjalankan shell, file baru atau webshell di folder web, serta cron job dan akun baru. Di shared hosting, kami pindahkan versi PHP jika panel hosting mengizinkan. Jika tidak, PHP-nya milik penyedia hosting, dan kami kirimkan permintaan yang persis ke penyedia hosting Anda. Laporan tertulis berisi temuan Anda terima di hari yang sama Anda mengirim permintaan. Jika cek kompromi menemukan tanda masalah, kami tulis di laporan dan kita bicarakan langkah berikutnya secara terpisah. Untuk server yang kami patch sendiri, status akhirnya kami tulis apa adanya: dicek dan di-patch.

Lihat cakupan dan ajukan cek & patch →