Mulai dari runtime yang benar
PHP2Shell menyasar runtime PHP yang melayani permintaan web. Karena itu, pemilik situs tidak cukup memeriksa versi CMS, tema, atau plugin. Buat daftar layanan yang memakai PHP, termasuk situs lama, panel internal, aplikasi yang dikelola vendor, dan endpoint yang berada di balik layanan hosting. Tanyakan kepada admin atau penyedia hosting apakah layanan berjalan dengan mod_php, PHP-FPM, php-cgi, FrankenPHP, atau LiteSpeed.
Bandingkan hasil pemeriksaan itu dengan rilis resmi PHP Foundation pada 21 Oktober 2026. Versi yang diperbaiki adalah PHP 8.5.12, 8.4.27, 8.3.36, dan 8.2.35. CISA meminta patch segera, sedangkan PHP Foundation menyebut pembaruan sebagai langkah utama untuk dua CVE tersebut. Cabang 8.1 dan yang lebih lama sudah tidak didukung upstream. Minta penjelasan tertulis dari vendor atau host bila mereka menyediakan backport, dan susun migrasi bila tidak ada perbaikan yang dapat diverifikasi.
Checklist prioritas untuk pemilik situs
Pertama, tambal runtime resmi. Jadwalkan pembaruan secepat mungkin, uji aplikasi pada lingkungan yang menyerupai produksi, lalu pastikan setiap worker PHP benar-benar berjalan pada build yang sudah diperbaiki. BleepingComputer mencatat bahwa patch permanen adalah pertahanan utama, bukan sekadar perubahan pada konfigurasi aplikasi.
Kedua, verifikasi dengan admin atau host. Jika Anda memakai shared hosting, managed WordPress, panel kontrol, container, atau distribusi Linux, tanyakan siapa yang memiliki runtime, kapan patch dipasang, dan bagaimana versi aktif dibuktikan. Jangan menganggap pembaruan panel otomatis memperbarui semua pool PHP.
Ketiga, perlakukan WAF hanya sebagai lapisan sementara. AWS menjelaskan bahwa WAF dapat mengurangi sebagian paparan sambil patch berlangsung, tetapi tidak menggantikan upgrade karena tidak melihat memori worker atau seluruh konfigurasi server. Jangan mengubah aturan WAF tanpa menilai dampaknya pada unggahan yang sah.
Keempat, siapkan pemulihan. Pastikan backup basis data, file aplikasi, dan konfigurasi tersedia dalam salinan yang tidak mudah diubah dari server produksi. Uji bahwa backup dapat dipulihkan. Simpan catatan waktu patch dan siapa yang menyetujuinya.
Kelima, pantau tanda yang relevan. Tinjau log web, proxy, PHP, dan sistem untuk permintaan aneh, proses PHP yang memulai shell atau mengunduh berkas, perubahan file yang tidak direncanakan, error berulang, serta waktu kejadian sebelum 21 Oktober. AWS dalam laporan MadPot menyarankan penyelidikan dimulai setidaknya dari 17 Oktober. Tidak adanya anomali pada satu log bukan bukti bahwa sistem aman.
Jika ada indikasi kompromi
Batasi akses layanan sesuai rencana tanggap insiden dan libatkan admin, host, atau penyedia forensik. Setelah ruang lingkup dipahami, rotasi kredensial aplikasi, akun admin, kunci API, token deploy, dan rahasia database yang mungkin dapat diakses dari server. Aktifkan MFA pada panel hosting, akun CMS, repositori, dan layanan cloud. Jangan menghapus log atau menimpa backup sebelum bukti diamankan.
Infosecurity Magazine melaporkan bahwa eksploitasi setelah disclosure diamati dalam skala luas, sementara The Hacker News dan CNBC menekankan urgensi patch. Untuk konteks keamanan agen yang berbeda, baca artikel komputer.review tentang agen AI; tidak ada klaim bahwa laporan itu berkaitan dengan PHP2Shell.
Pelanggan hosting juga perlu meminta batas tanggung jawab yang jelas. Tanyakan apakah host mengelola binary PHP, konfigurasi pool, image container, atau hanya menyediakan mesin. Minta nomor versi runtime yang benar-benar menerima trafik, bukan versi yang terlihat di dokumentasi lama. Untuk aplikasi yang tersebar di beberapa domain, ulangi pemeriksaan per situs karena satu akun dapat memakai beberapa versi dan beberapa jalur eksekusi.
Sesudah patch, lakukan verifikasi ulang pada lingkungan produksi dan catat waktu restart worker. Periksa dependensi yang dikompilasi bersama PHP serta paket dari vendor distribusi, karena nama versi yang tampil pada panel belum tentu menggambarkan paket yang dipakai proses web. Bila host tidak dapat memberi jawaban yang dapat diverifikasi, perlakukan ketidakpastian itu sebagai risiko dan siapkan pemindahan layanan atau pembatasan akses sampai statusnya jelas.
Yang tidak boleh diasumsikan
WAF, pembatasan unggahan, atau perubahan konfigurasi dapat menurunkan risiko, tetapi bukan pengganti patch resmi. Demikian pula, status “tidak melihat serangan” bukan jaminan bahwa tidak ada kompromi. Prioritas praktisnya tetap jelas: ketahui runtime yang aktif, pasang versi yang diperbaiki, koordinasikan dengan host, lalu simpan bukti pemantauan dan pemulihan.
Sumber rujukan
- PHP Foundation: Today's PHP Security Release, and How We're Strengthening PHP Security
- CISA: Critical Vulnerabilities in PHP Require Immediate Patching
- AWS Security Blog: Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot
- AWS Security Blog: Using AWS WAF to apply mitigations for PHP2Shell RCE vulnerabilities
- BleepingComputer: PHP ships emergency patches for critical PHP2Shell flaws
- Infosecurity Magazine: PHP2Shell Exploitation Attempt Detected Four Days Before Disclosure
- The Hacker News: Someone Tried to Exploit PHP2Shell 4 Days Before the Vulnerabilities Were Publicly Disclosed
- CNBC: PHP2Shell vulnerability: What is it, and is your data at risk?