PHP2Shell Adalah: Celah Kritis di PHP dan Cara Mengamankan Server Anda

Rabu, 21 Oktober 2026, tim PHP merilis PHP 8.5.12, 8.4.27, 8.3.36, dan 8.2.35 di luar jadwal rilis rutinnya. Keempat versi itu menambal dua celah yang kini dikenal dengan nama PHP2Shell, yaitu CVE-2026-109618 dan CVE-2026-109619. Lewat celah ini, penyerang bisa menjalankan kode di server tanpa perlu login. Percobaan eksploitasinya bahkan sudah terekam empat hari sebelum patch keluar, jadi pemilik server PHP tidak punya banyak waktu untuk menunda.

Dua Bug di Inti PHP

Kedua bug ini berada di runtime PHP, di bagian yang mengurus memori selama sebuah request diproses. Tim keamanan PHP memberi keduanya skor 9.2 pada CVSS v4.0. Dalam praktiknya, satu request yang dirakit khusus bisa membuat PHP menjalankan kode milik penyerang dengan hak akses yang sama seperti user web server. Di kebanyakan server, user ini bisa membaca source code aplikasi dan file .env, lengkap dengan password database dan API key di dalamnya.

Celah ini ditemukan oleh peneliti dari Calif, OpenAI, dan Wiz, yang memakai model AI untuk membantu mengaudit source code PHP. Menurut tulisan teknis Calif, kode yang bermasalah sudah ada sejak PHP 5.4, versi yang dirilis tahun 2012.

Kode Aplikasi yang Rapi Tidak Banyak Menolong

Selama ini, celah keamanan di ekosistem PHP umumnya datang dari aplikasinya: query yang tidak di-escape, plugin WordPress yang lama tidak diperbarui, atau form upload yang terlalu longgar. PHP2Shell berbeda. Advisory resminya menyebut semua instalasi PHP yang melayani request web ikut terdampak, entah lewat PHP-FPM, mod_php di Apache, php-cgi, FrankenPHP, maupun LiteSpeed.

Konfigurasi paling berisiko adalah mod_php. Tim PHP menyebut sudah ada exploit yang terbukti berjalan di sana, dan serangannya terjadi sebelum kode aplikasi sempat dieksekusi. Artinya, aplikasi Laravel yang ditulis dengan disiplin dan website PHP lama yang tak pernah disentuh berada di posisi yang sama selama binary PHP-nya belum diperbarui.

Kronologi Singkat

• 17 Oktober: honeypot milik Amazon merekam percobaan eksploitasi pertama.
• 20 Oktober: tim PHP mengumumkan akan merilis update keamanan darurat. Di hari yang sama, detail celahnya mulai beredar sebelum jadwal pengumuman resmi.
• 21 Oktober: patch dirilis sehari lebih cepat dari rencana. CISA mengeluarkan peringatan, Cloudflare memasang aturan WAF dan melaporkan serangan awal, dan Amazon kemudian menyebut celah ini sudah dieksploitasi secara luas.
• 23 Oktober: tim PHP menerbitkan advisory tambahan untuk CVE-2026-115560, jalur serangan terkait yang jauh lebih jarang ditemui.

Sejak kabar ini menyebar, beredar pula berbagai kode yang diklaim sebagai exploit PHP2Shell. PHP Foundation menyatakan belum menemukan exploit publik yang benar-benar berfungsi saat patch dirilis, dan kode dari sumber yang tidak jelas kerap disisipi malware. Untuk mengetahui apakah server Anda rentan, mengecek versi PHP jauh lebih aman daripada mencoba kode semacam itu.

Mengecek Versi PHP yang Dipakai Web Server

Kebanyakan orang langsung mengetik php -v. Hasilnya belum tentu menggambarkan kondisi sebenarnya, karena perintah itu menampilkan versi PHP untuk command line. Web server bisa saja memakai binary lain, terutama di server yang memasang beberapa versi PHP sekaligus. Periksa binary yang benar-benar melayani request, misalnya dengan php-fpm8.3 -v, atau buat halaman phpinfo sementara dan hapus begitu versinya terbaca.

Lakukan pengecekan ini di semua server, termasuk staging, panel admin lama, dan microsite kampanye yang mungkin sudah tidak jelas lagi siapa pengelolanya. Tabel berikut merangkum versi yang sudah aman untuk tiap cabang.

Satu hal yang sering membingungkan: distro Linux biasanya menambal celah tanpa mengubah nomor versi upstream. Paket PHP di Ubuntu atau Debian bisa saja sudah aman walau masih menampilkan versi yang lebih lama dari tabel di atas. Untuk paket bawaan distro, pegangannya adalah security notice atau changelog paket. Kalau kedua nomor CVE tadi tercantum di sana, paket itu sudah diperbaiki.

Langkah Update di Berbagai Lingkungan

Cara memperbarui PHP bergantung pada bagaimana PHP itu dipasang. Berikut yang paling sering kami temui.

• Ubuntu dan Debian: jalankan apt update, lalu perbarui paket PHP, misalnya dengan apt install --only-upgrade 'php8.3*'. Jika PHP dipasang dari repository ondrej/php, update-nya datang dari repository tersebut, jadi pastikan build yang sudah diperbaiki sudah tersedia di sana.
• RHEL, AlmaLinux, dan Rocky Linux: jalankan dnf upgrade 'php*'. Pengguna repository Remi sebaiknya memeriksa pengumuman di sana untuk build yang sudah diperbaiki.
• Docker: tarik image php resmi yang terbaru dan build ulang semua image turunannya. Tag yang dikunci seperti php:8.3.30-fpm tidak akan berubah dengan sendirinya, jadi versinya perlu dinaikkan secara manual. Setelah deploy, jalankan php -v di dalam container yang sedang berjalan.
• Shared hosting dan cPanel: PHP dikelola oleh penyedia hosting, biasanya lewat EasyApache atau paket alt-php dari CloudLinux. Minta konfirmasi tertulis dari penyedia bahwa build yang sudah diperbaiki terpasang untuk setiap versi PHP yang Anda gunakan.
• Windows: unduh rilis terbaru dari php.net, ganti instalasi lama, lalu restart IIS atau Apache.

Apa pun lingkungannya, urutan kerjanya kurang lebih sama.

1. 1Buat daftar semua sistem yang menjalankan PHP dan dahulukan yang bisa diakses dari internet. Container, staging, perangkat yang membawa PHP di dalamnya, dan aplikasi lama yang jarang dipakai juga masuk daftar ini.
2. 2Perbarui PHP di setiap sistem, lalu catat siapa yang mengerjakan dan kapan.
3. 3Restart semua proses PHP, jangan hanya web server-nya: systemctl restart php8.3-fpm untuk PHP-FPM, atau systemctl restart apache2 (httpd di keluarga RHEL) untuk mod_php. Worker yang belum di-restart masih menjalankan kode lama dari memori.
4. 4Cek ulang versi dari sisi web server, lalu pastikan queue worker dan proses PHP lain yang berjalan lama ikut di-restart.
5. 5Hapus halaman phpinfo sementara jika sempat dibuat, dan biarkan session upload progress tetap nonaktif sampai rilis PHP rutin berikutnya.

Jika Update Belum Bisa Dilakukan Hari Ini

Ada kalanya update tidak bisa langsung dijalankan, misalnya karena aplikasi lama belum diuji di versi terbaru atau server dikelola pihak lain. Untuk kondisi seperti ini, tim PHP mencantumkan beberapa pengaturan yang menutup jalur serangan yang sudah terkonfirmasi. Mereka juga menegaskan bahwa pengaturan ini tidak membuat server aman sepenuhnya. Dalam pengumuman rilisnya, tim PHP menulis:

Tidak ada mitigasi yang lengkap. Update adalah satu-satunya pilihan yang aman.

• Untuk CVE-2026-109619, set session.upload_progress.enabled=0 di php.ini atau konfigurasi pool FPM, lalu restart semua worker. Pengaturan lewat ini_set() atau .user.ini tidak berlaku untuk kasus ini. Di PHP 8.5, tambahkan juga fatal_error_backtraces=0.
• Untuk CVE-2026-109618, set memory_limit=-1 dengan cara yang tidak bisa diubah aplikasi, misalnya lewat php_admin_value di pool FPM. Pasangkan dengan batas memori di level container atau cgroup supaya satu request tidak menghabiskan RAM server. Hindari RLIMIT_AS dan RLIMIT_DATA, karena keduanya justru bisa memicu jalur yang rentan.
• Turunkan post_max_size ke 8M untuk aplikasi tanpa fitur upload, atau 32M jika ada upload. Pastikan upload_max_filesize lebih kecil dari angka itu, dan batasi ukuran serta jumlah field request di Nginx, Apache, atau load balancer.
• Letakkan aplikasi di belakang WAF yang sudah memiliki aturan untuk PHP2Shell, misalnya Cloudflare. Perlindungannya hanya berlaku untuk trafik yang melewati WAF, jadi pastikan server origin tidak bisa diakses langsung.
• Jika semua langkah di atas tidak memungkinkan, matikan sementara sistem yang terbuka ke internet atau batasi aksesnya lewat VPN sampai update selesai. CISA dan CERT-EU memberikan saran yang sama.

Advisory 23 Oktober menambahkan satu kasus khusus. Aplikasi yang mengatur session.serialize_handler ke php_binary atau php_serialize, lalu menggantinya ke php lewat ini_set() sebelum memanggil session_start(), masih bisa diserang melalui session upload progress. Kombinasi ini jarang dipakai, dan menonaktifkan session upload progress sudah cukup untuk menutupnya. Itu sebabnya tim PHP menyarankan pengaturan tersebut tetap dipakai sampai rilis berikutnya.

Server dengan PHP 8.1 atau Lebih Lama

PHP 8.1 ke bawah sudah tidak lagi mendapat rilis dari tim PHP. Mengingat seriusnya celah ini, tim keamanan PHP tetap menerbitkan backport minimal untuk 7.4, 8.0, dan 8.1, tetapi bentuknya source code yang harus di-compile sendiri. Bagi kebanyakan perusahaan, pilihan yang realistis adalah memakai paket yang sudah diperbaiki dari distro atau vendor LTS, atau naik ke PHP 8.2 ke atas. Jika aplikasinya belum bisa berjalan di versi yang masih didukung, ini saat yang tepat untuk mulai merencanakan migrasinya. Celah kritis berikutnya belum tentu disertai backport.

Setelah Update, Periksa Jejak Penyusup

Patch mencegah serangan baru, tetapi tidak membersihkan apa pun yang sudah telanjur masuk. Karena percobaan eksploitasi sudah terlihat sejak 17 Oktober, server PHP yang terbuka ke internet sebaiknya diperiksa untuk tanda-tanda berikut.

• File PHP yang muncul atau berubah sejak 17 Oktober di folder upload atau folder yang bisa ditulis web server, seperti wp-content/uploads, storage, atau public/uploads. Perintah find /var/www -name '*.php' -newermt 2026-10-17 bisa dipakai sebagai pemeriksaan awal.
• Cron job, service systemd, atau SSH key baru milik user web server.
• Akun admin di aplikasi yang tidak dikenali tim Anda.
• Koneksi keluar ke alamat yang tidak dikenal, atau pemakaian CPU yang terus tinggi tanpa sebab jelas. Keduanya sering menandakan cryptominer.
• Lonjakan crash worker PHP-FPM atau segmentation fault di log, terutama jika berbarengan dengan request yang janggal di access log.

Jika ada temuan, perlakukan server tersebut sebagai server yang sudah disusupi. Ganti semua secret yang bisa dibaca user web, termasuk password database, API key, dan application key. Setelah itu, bangun ulang server dari image yang bersih. Menghapus file mencurigakan yang kebetulan ditemukan tidak menjamin penyusupnya sudah pergi.

Catatan untuk Pemilik Bisnis

Insiden seperti PHP2Shell sering memperlihatkan masalah yang sifatnya organisasi, bukan teknis. Banyak perusahaan tahu siapa yang membangun aplikasinya, tetapi tidak tahu siapa yang bertanggung jawab memperbarui PHP di server, terutama setelah vendor awalnya tidak lagi terlibat. Daftar sederhana yang berisi lokasi PHP berjalan, versinya, cara update-nya, dan nama penanggung jawabnya sudah cukup untuk membuat rilis darurat berikutnya jauh lebih mudah ditangani.

Jika Anda butuh bantuan untuk memeriksa atau memperbarui server PHP, tim managed service kami bisa membantu dari pengecekan versi sampai pemeriksaan pasca-update.