Pengantar
Meta description: Pelajari ancaman PHP2Shell, risiko Remote Code Execution, dan langkah praktis untuk melindungi server PHP melalui patch, pembatasan akses, serta pemantauan keamanan.
Mengenal PHP2Shell, Ancaman Serius bagi Server PHP
PHP2Shell menjadi perhatian dunia keamanan siber setelah ditemukannya dua kerentanan kritis pada PHP yang berpotensi memungkinkan penyerang menjalankan perintah pada server dari jarak jauh. Kedua kerentanan tersebut dilaporkan memiliki skor CVSS 9,2 dari 10, yang menunjukkan tingkat keparahan tinggi.
PHP merupakan bahasa pemrograman yang banyak digunakan untuk membangun website dan aplikasi web. Platform seperti WordPress, Drupal, dan berbagai aplikasi berbasis PHP bergantung pada runtime PHP agar dapat berjalan.
Jika kerentanan pada runtime ini berhasil dieksploitasi, dampaknya dapat meluas ke aplikasi yang berjalan di atasnya. Penyerang berpotensi memperoleh akses ke data sensitif, mengubah file website, atau menjalankan perintah dengan hak akses proses PHP yang berhasil dikompromikan.
Dua kerentanan yang dikaitkan dengan PHP2Shell dilaporkan menggunakan identitas CVE-2026-109618 dan CVE-2026-109619. Informasi mengenai versi terdampak dan status perbaikannya harus diperiksa melalui pengumuman resmi PHP serta vendor sistem operasi yang digunakan.
Apa Itu Remote Code Execution?
Remote Code Execution atau RCE adalah jenis kerentanan yang memungkinkan penyerang menjalankan kode atau perintah pada sistem dari jarak jauh.
Bayangkan sebuah server website seperti komputer yang melayani pengunjung selama 24 jam. Dalam kondisi normal, server hanya menjalankan instruksi yang memang diperlukan oleh aplikasi.
Namun, ketika terdapat kerentanan RCE, penyerang mungkin dapat membuat server menjalankan instruksi yang tidak seharusnya diizinkan.
Dampaknya bergantung pada konfigurasi server dan hak akses proses yang berhasil dieksploitasi. Beberapa risiko yang dapat muncul antara lain:
- Pencurian data atau kredensial yang dapat diakses proses aplikasi.
- Perubahan halaman website tanpa izin.
- Pemasangan malware atau web shell.
- Penyalahgunaan server untuk menyerang sistem lain.
- Gangguan layanan yang menyebabkan website tidak dapat diakses.
Karena itu, RCE pada komponen yang digunakan banyak aplikasi harus ditangani dengan cepat.
Mengapa Menonaktifkan Session Upload Progress Tidak Cukup?
Setelah informasi PHP2Shell beredar, sejumlah pihak menyarankan administrator untuk menonaktifkan konfigurasi session.upload_progress.enabled pada PHP.
Fitur Session Upload Progress digunakan untuk mencatat kemajuan proses pengunggahan file. Informasi tersebut dapat digunakan aplikasi untuk menampilkan persentase atau status upload kepada pengguna.
Namun, perubahan konfigurasi ini tidak boleh dianggap sebagai solusi menyeluruh untuk PHP2Shell.
Dalam laporan The Hacker News pada 21 Oktober 2026, GMO Flatt Security memperbarui rekomendasinya dan menyatakan bahwa pengaturan tersebut saja tidak cukup untuk mengatasi kerentanan. Perwakilan proyek PHP juga menegaskan pentingnya memperbarui PHP ke versi yang telah diperbaiki.
Selain itu, pada saat laporan tersebut diterbitkan, akar masalah dan detail teknis lengkap belum dikonfirmasi secara resmi oleh tim PHP.
Artinya, administrator tidak boleh berasumsi bahwa satu perubahan konfigurasi sudah membuat server aman. Menonaktifkan fitur yang tidak diperlukan dapat menjadi bagian dari pengurangan risiko, tetapi tidak menggantikan pembaruan keamanan resmi.
Langkah Melindungi Server Sebelum Patch Diterapkan
Jika server belum dapat diperbarui, ada beberapa langkah yang dapat dilakukan untuk mengurangi risiko.
1. Inventarisasi Seluruh Instalasi PHP
Mulailah dengan mendata seluruh server dan aplikasi yang menggunakan PHP. Jangan hanya memeriksa website utama.
Periksa juga aplikasi internal, container Docker, server staging, panel hosting, serta perangkat lunak pihak ketiga yang menyertakan runtime PHP.
Catat versi PHP, sistem operasi, metode eksekusi PHP, dan sumber paket yang digunakan. Informasi ini membantu menentukan pembaruan yang tepat.
Perlu diingat bahwa hasil perintah php -v hanya menunjukkan versi PHP CLI. Versi yang melayani website melalui PHP-FPM atau modul Apache dapat berbeda.
2. Batasi Akses ke Aplikasi yang Berisiko
Jika patch belum tersedia atau belum dapat diterapkan, pertimbangkan untuk membatasi akses publik ke aplikasi yang berisiko.
Pilihan yang dapat digunakan antara lain:
- Membatasi akses melalui VPN.
- Mengizinkan akses hanya dari alamat IP tertentu.
- Menempatkan aplikasi di belakang kontrol akses yang sesuai.
- Mengisolasi sementara aplikasi dari jaringan publik jika risiko tidak dapat dikendalikan.
Keputusan ini perlu mempertimbangkan kebutuhan operasional dan dampak terhadap pengguna. Jika aplikasi tidak dapat diamankan sementara, penghentian akses publik mungkin menjadi pilihan yang lebih aman.
3. Siapkan Pembaruan PHP
Jangan menunggu sampai serangan berhasil terjadi untuk menyiapkan proses pembaruan.
Administrator sebaiknya memeriksa pengumuman keamanan resmi PHP, paket yang disediakan distribusi Linux, serta informasi dari penyedia hosting.

Pastikan juga tersedia prosedur untuk melakukan backup, pengujian aplikasi, persetujuan perubahan darurat, dan pemulihan jika terjadi masalah setelah pembaruan.
Pembaruan harus diterapkan pada runtime yang benar-benar melayani permintaan web, bukan hanya pada aplikasi seperti WordPress atau Laravel.
4. Batasi Hak Akses Proses PHP
Proses PHP sebaiknya tidak berjalan dengan hak administrator atau root jika tidak diperlukan.
Gunakan prinsip least privilege, yaitu memberikan hak akses minimum yang diperlukan agar aplikasi dapat beroperasi.
Batasi pula akses proses PHP terhadap file konfigurasi, kredensial, direktori sensitif, dan layanan internal yang tidak dibutuhkan. Langkah ini dapat mengurangi dampak jika suatu aplikasi berhasil dikompromikan.
5. Gunakan WAF sebagai Lapisan Tambahan
Web Application Firewall atau WAF dapat membantu memfilter permintaan web yang mencurigakan sebelum mencapai aplikasi.
Penyedia layanan keamanan tertentu telah mengumumkan aturan darurat untuk mengurangi risiko eksploitasi PHP2Shell. Namun, aturan tersebut harus dipandang sebagai perlindungan sementara.
Aturan WAF dapat memiliki keterbatasan, termasuk kemungkinan permintaan berbahaya tidak terdeteksi atau permintaan normal ikut terblokir. Karena itu, pengujian perlu dilakukan sebelum aturan diterapkan secara luas.
WAF bukan pengganti patch PHP.
Cara Memantau Aktivitas Mencurigakan
Selain mengurangi paparan, administrator perlu memantau aktivitas server untuk mengetahui kemungkinan percobaan eksploitasi atau kompromi.
Beberapa indikator yang patut diperiksa adalah:
- Proses PHP-FPM, PHP-CGI, atau Apache yang tiba-tiba menjalankan shell atau program yang tidak biasa.
- Lonjakan permintaan HTTP yang tidak wajar, khususnya pada endpoint yang tidak seharusnya menerima unggahan file.
- Perubahan file website yang tidak sesuai dengan aktivitas deployment.
- Munculnya file, akun, atau tugas terjadwal yang tidak dikenal.
- Error atau crash pada proses PHP yang berkaitan dengan permintaan mencurigakan.
Simpan log web server dan sistem operasi secara aman agar dapat digunakan dalam investigasi.
Jika ditemukan indikasi kompromi, jangan hanya menghapus file yang terlihat mencurigakan. Isolasi sistem sesuai prosedur penanganan insiden, pertahankan bukti, identifikasi kemungkinan akses yang telah diperoleh penyerang, dan lakukan pemulihan dari sumber yang tepercaya.
Tidak adanya indikator yang terlihat juga tidak menjamin bahwa server belum pernah dikompromikan.
Apa yang Harus Dilakukan Ketika Patch Resmi Tersedia?
Pembaruan keamanan merupakan langkah terpenting untuk menangani kerentanan yang telah diperbaiki oleh vendor.
Ketika rilis keamanan tersedia, lakukan langkah berikut:
- Periksa advisory resmi untuk mengetahui versi yang terdampak dan versi yang telah diperbaiki.
- Pastikan paket pembaruan sesuai dengan cabang PHP dan distribusi Linux yang digunakan.
- Prioritaskan server yang dapat diakses langsung dari internet.
- Perbarui runtime PHP yang melayani permintaan web.
- Mulai ulang atau muat ulang layanan jika diperlukan oleh proses pembaruan.
- Verifikasi versi dan status patch melalui informasi vendor.
- Uji fungsi website, terutama fitur unggah file dan aplikasi yang bergantung pada PHP.
- Periksa log setelah pembaruan dan lanjutkan investigasi jika ada indikasi kompromi.
Untuk PHP yang sudah berakhir masa dukungannya, administrator perlu mempertimbangkan migrasi ke cabang yang masih didukung atau solusi keamanan dari vendor yang menyediakan pembaruan tambahan.
Jangan menganggap suatu server telah aman hanya karena nomor versinya terlihat lebih baru. Distribusi Linux tertentu dapat memberikan perbaikan melalui backport, sehingga status paket dan advisory vendor perlu diperiksa.
Checklist Keamanan PHP2Shell
Administrator dapat menggunakan daftar berikut untuk memastikan langkah penanganan telah dilakukan.
- [ ] Seluruh instalasi PHP telah diinventarisasi.
- [ ] Versi runtime dan sumber paket telah diperiksa.
- [ ] Aplikasi yang berisiko telah dibatasi atau diisolasi bila diperlukan.
- [ ] Pembaruan keamanan resmi telah disiapkan.
- [ ] PHP yang melayani permintaan web telah diperbarui ke paket yang sesuai.
- [ ] WAF dan kontrol akses digunakan sebagai lapisan tambahan bila diperlukan.
- [ ] Log dan proses server telah diperiksa.
- [ ] Indikasi kompromi telah ditindaklanjuti.
- [ ] Aplikasi telah diuji setelah pembaruan.
- [ ] Status keamanan dan tindakan lanjutan telah didokumentasikan.
Kesimpulan
PHP2Shell menunjukkan bahwa kerentanan pada runtime dapat menimbulkan risiko besar bagi website dan aplikasi yang bergantung pada PHP.
Mengubah satu konfigurasi PHP saja tidak cukup untuk menjamin keamanan. Administrator perlu menggabungkan inventarisasi aset, pembatasan akses, pengurangan hak akses proses, pemantauan log, dan penerapan pembaruan keamanan resmi.
Jika patch belum dapat diterapkan, kurangi paparan server dan pertimbangkan isolasi sementara sesuai tingkat risiko. Setelah pembaruan tersedia, verifikasi bahwa runtime yang melayani website benar-benar telah diperbaiki.
Prinsip terpentingnya adalah jangan mengandalkan workaround sebagai pengganti patch resmi. Pemantauan advisory vendor dan kesiapan merespons insiden menjadi bagian penting dalam menjaga keamanan server PHP.






