Memahami PHP2Shell, Celah Kritis PHP dan Kenapa Anda Harus Segera Melakukan Sesuatu

Jika website Anda berjalan di PHP, kabar ini menyangkut Anda. Dalam beberapa hari terakhir, dunia keamanan siber ramai membicarakan satu nama PHP2Shell.

Namanya memang terdengar seperti alat peretas. Padahal bukan. PHP2Shell adalah sebutan untuk dua celah keamanan di dalam mesin PHP itu sendiri, yaitu CVE-2026-109618 dan CVE-2026-109619. Keduanya dinilai kritis dengan skor 9,2 dari 10. Penyerang yang berhasil memanfaatkannya berpotensi menjalankan kode di server Anda tanpa perlu login sama sekali.

Skalanya membuat kabar ini serius. PHP menjalankan sekitar 70% website yang bahasa pemrogramannya dapat diidentifikasi. Di antaranya ada WordPress, Laravel, Joomla, Drupal, dan Magento. Karena celahnya ada di mesin PHP, bukan di aplikasinya, situs yang kodenya rapi dan pluginnya selalu diperbarui pun tetap bisa terdampak.

Situasinya juga bergerak cepat. Detail celah bocor pada 20 Oktober, sebelum tambalan siap. PHP lalu merilis perbaikan pada 21 Oktober. Namun percobaan serangan sudah tercatat sejak 17 Oktober, empat hari sebelum tambalan ada. Di Eropa, beberapa pemerintah sampai menurunkan situs resminya dari internet sebagai langkah berjaga-jaga. Di Indonesia, BSSN ikut mengeluarkan peringatan kepada pemilik dan pengelola website pada 22 Oktober.

Karena itu, artikel ini tidak berhenti pada nasihat “perbarui PHP”. Kita akan membahas apa yang sebenarnya terjadi, siapa yang terdampak, dan mengapa waktu kini jadi faktor terpenting. Setelah itu, kita masuk ke langkah praktis yang disesuaikan dengan cara PHP Anda dijalankan, mulai dari VPS, shared hosting, sampai Docker.

Apa itu PHP2Shell?

PHP2Shell merujuk pada dua celah, yaitu CVE-2026-109618 dan CVE-2026-109619. Keduanya berpotensi memungkinkan eksekusi kode jarak jauh tanpa autentikasi, dengan hak akses akun web server, dan sama-sama dinilai kritis dengan skor CVSS v4.0 9,2.

Artinya sederhana. Penyerang tidak perlu login dan tidak perlu akun. Ia cukup bisa menjangkau server Anda lewat internet.

Kedua celah punya akar masalah yang berbeda:

• CVE-2026-109618 muncul saat PHP kehabisan memori di tengah penyiapan sebuah request. Data internal tertinggal setengah jadi, lalu kode pembersihan memperlakukannya seolah valid.
• CVE-2026-109619 terjadi karena status internal masih hidup padahal memori request yang ditunjuknya sudah dibebaskan. Request berikutnya yang ditangani worker PHP yang sama bisa bertindak atas data sisa itu.

Satu hal lagi patut dicatat. Peneliti juga memperagakan pembocoran memori worker PHP tanpa autentikasi, yang bisa membuka kata sandi, token autentikasi, dan kunci API. Jadi dampaknya tidak berhenti pada pengambilalihan server. Rahasia dari request pengguna lain pun bisa ikut bocor.

Mengapa ini jadi begitu ramai?

Alasan pertama adalah skalanya. PHP dipakai oleh sekitar 70,8% website yang bahasa pemrogramannya diketahui, termasuk WordPress, Laravel, Joomla, dan Magento. Celah ini ada di mesin PHP, bukan di aplikasinya. Menurut Sansec, toko online berbasis Magento, Shopware, dan WooCommerce ikut terdampak meski kodenya sendiri bersih.

Alasan kedua adalah bocornya informasi sebelum waktunya. Rangkaian kejadiannya kira-kira begini:

1. Agustus 2026. Peneliti dari Calif menemukan beberapa jalur RCE, lalu melaporkan bug pertama ke PHP pada 11 Agustus. Wiz Research melaporkan celah yang sama secara terpisah pada 24 Agustus.
2. 17 Oktober. Amazon Threat Intelligence menemukan percobaan eksploitasi lewat telemetri MadPot, empat hari sebelum pengungkapan publik.
3. 20 Oktober. Detail celah bocor ke publik. PHP lalu mengumumkan rilis keamanan darurat tanpa menyebut nomor CVE.
4. 21 Oktober. PHP merilis perbaikan, sedikit lebih awal dari jadwal. Pada hari yang sama, honeypot milik watchTowr mengamati eksploitasi kedua celah di dunia nyata.

Jadi serangan sudah berjalan sebelum tambalan tersedia. Pola seperti ini biasanya diikuti pemindaian massal terhadap server yang belum diperbarui.

Versi PHP mana yang terdampak?

Jawaban singkatnya hampir semua. Setiap instalasi PHP yang melayani request web terdampak, baik lewat PHP-FPM, Apache mod_php, php-cgi, LiteSpeed, maupun FrankenPHP. Risiko tertinggi ada pada mod_php, karena serangan bisa berhasil sebelum kode aplikasi apa pun dijalankan.

Tabel berikut merangkum status per cabang:

(Sumber tabel: rangkuman watchTowr atas advisory PHP.)

Contoh kasus toko online UMKM di VPS

Mari kita pakai ilustrasi agar jelas. Misalkan Anda mengelola toko online WooCommerce di VPS Ubuntu dengan Apache dan mod_php. Anda memeriksa versi dan hasilnya PHP 8.3.30.

Cabang 8.3 baru aman di versi 8.3.36. Karena 8.3.30 lebih rendah, server ini rentan. Dan karena memakai mod_php, ia berada di kategori risiko tertinggi. Server seperti ini harus ditangani paling dulu.

Sekarang bandingkan dengan blog pribadi di shared hosting yang PHP-nya diatur lewat cPanel. Anda tidak punya akses ke server, jadi langkahnya berbeda. Anda perlu memeriksa versi PHP di panel, lalu menghubungi penyedia hosting. Tanyakan apakah mereka sudah memasang versi yang diperbaiki.

Langkah penanganan yang benar

1. Cek versi PHP yang benar-benar melayani web

Ini jebakan yang sering terlewat. Binary PHP di command line bisa berbeda versi dari PHP-FPM atau Apache yang melayani web. Jadi php -v saja tidak cukup. Periksa juga versi service-nya:

php -v
php-fpm8.3 -v        # sesuaikan dengan cabang Anda
apache2ctl -M | grep php   # cek apakah mod_php aktif

Anda juga bisa melihat versi lewat halaman phpinfo(). Hapus file itu segera setelah selesai, sebab halaman tersebut membocorkan banyak informasi server.

2. Simpan bukti sebelum mengubah apa pun

Sebelum memperbarui, simpan log PHP dan web server, snapshot konfigurasi, serta file mencurigakan. Bukti ini penting seandainya server ternyata sudah disusupi.

3. Perbarui PHP

Di Ubuntu atau Debian, perintah dasarnya:

sudo apt update
sudo apt upgrade

Satu catatan penting. Distribusi Linux sering menambal tanpa menaikkan nomor versi upstream. Karena itu, php -v bisa tetap menampilkan angka lama padahal paketnya sudah diperbaiki. Pastikan lewat changelog paket atau halaman pelacak keamanan distribusi Anda, misalnya:

apt changelog php8.3-fpm | grep -i "CVE-2026-10961"

Untuk PHP 8.1 ke bawah, gunakan paket dari distribusi atau vendor LTS, atau backport minimal dari tim keamanan PHP. Jika Anda masih di PHP 7.3 atau lebih lama, tidak ada tambalan. Satu-satunya jalan adalah migrasi ke versi yang didukung.

4. Restart semua proses PHP

Langkah ini sering dilupakan, padahal krusial. Proses yang sedang berjalan tetap memakai kode lama di memori sampai di-restart. Ini terutama penting untuk CVE-2026-109619, yang mengeksploitasi state request yang terbawa saat worker PHP dipakai ulang.

sudo systemctl restart php8.3-fpm
sudo systemctl restart apache2   # atau nginx, sesuai setup Anda

5. Periksa tanda-tanda penyusupan

Jika server Anda terbuka ke internet sejak 17 Oktober, jangan langsung menganggap aman setelah memperbarui. Tambalan menutup pintu, tetapi tidak mengusir penyusup yang sudah masuk. Periksa hal-hal ini:

• Web shell baru. Cari file PHP yang berubah belakangan: find /var/www -name "*.php" -mtime -7
• Cron job asing pada user web server.
• Akun baru di sistem atau di panel admin aplikasi.
• Koneksi keluar dari proses PHP yang tidak bisa Anda jelaskan.
• Pola di log. Waspadai request multipart yang tidak wajar besar atau bersarang dalam, worker PHP yang crash atau mencapai batas memori, dan file baru di web root.

Jika menemukan indikasi penyusupan, anggap kunci API, kata sandi database, dan token sesi sudah bocor. Gantilah semuanya setelah server bersih.

6. Jika belum bisa memperbarui sekarang

Batasi akses internet ke server tersebut sampai tambalan terpasang. NCSC Inggris bahkan menyarankan mempertimbangkan untuk mematikan sistem yang tidak bisa diperbarui atau dimitigasi tepat waktu. Langkah sementara seperti aturan WAF memang membantu. Cloudflare, misalnya, memasang aturan WAF sementara sebagai penahan awal. Namun itu hanya penyangga, bukan solusi.

Jebakan “mitigasi” lewat konfigurasi

Anda mungkin menemukan saran untuk mematikan fitur tertentu, seperti session.upload_progress.enabled=0. Sebagian vendor memang menyebutnya sebagai langkah sementara. Tetapi sumber lain lebih tegas. PHP menyatakan tidak ada perubahan konfigurasi yang menutup celah ini sepenuhnya. Fitur Session Upload Progress hanyalah salah satu jalur yang terkonfirmasi, bukan satu-satunya.

Perlakukan perubahan konfigurasi sebagai tambahan, bukan pengganti pembaruan.

“Katanya PoC-nya tidak jalan di instalasi default”

Kabar ini memang beredar. Seorang peneliti yang menguji PoC publik menemukan bahwa exploit tersebut tidak bekerja pada instalasi PHP default. Jangan jadikan itu alasan untuk menunda. PoC publik yang gagal tidak membuktikan celahnya aman. Bisa jadi PoC itu hanya belum sempurna. Pada saat yang sama, watchTowr sudah mengamati eksploitasi nyata terhadap kedua celah.

PHP2Shell mengingatkan kita pada satu hal. Keamanan website bukan hanya soal plugin atau tema yang rutin diperbarui. Lapisan di bawahnya, yaitu runtime PHP, sama pentingnya.

Ringkasannya, ada tiga hal yang perlu diingat. Pertama, cek versi PHP yang sebenarnya melayani web. Kedua, perbarui ke versi aman dan restart semua proses. Ketiga, periksa apakah server sudah telanjur disusupi.

Jika Anda memakai shared hosting, hubungi penyedia hosting hari ini dan minta konfirmasi tertulis bahwa server Anda sudah ditambal.

Sumber rujukan: advisory resmi PHP (GitHub Security Advisory GHSA-w8hw-w9fx-j79w dan GHSA-6wmf-4rv5-p3rp), watchTowr, Sophos, Sansec, Qualys, Recorded Future, dan SecurityWeek.