PHP2Shell: Dua Celah Kritis di Mesin PHP, Penyerang Tanpa Akun Bisa Jalankan Kode di Server

Pada 21 Oktober 2026, tim PHP merilis PHP 8.5.12, 8.4.27, 8.3.36, dan 8.2.35. Empat versi itu menambal dua celah yang sekarang dikenal sebagai PHP2Shell, tercatat sebagai CVE-2026-109618 dan CVE-2026-109619. Masing-masing punya skor CVSS v4.0 9.2. Penyerang tanpa akun, tanpa interaksi pengguna, bisa menjalankan kode di server yang menjalankan PHP. Celahnya bukan di kode WordPress atau plugin, tapi di mesin PHP-nya sendiri.

Jadwal rilis ini sebenarnya Kamis, 22 Oktober. Pengumuman resmi di php.net menyebut rilis dimajukan sehari karena dua nomor CVE sudah beredar di forum dan media sosial sejak Selasa sore, lengkap dengan informasi yang salah soal jam rilis dan tingkat keparahannya. Tim PHP memilih mengumumkan lebih cepat daripada membiarkan rumor berjalan tanpa patch.

Siapa yang menemukannya

Tiga organisasi menemukan celah ini secara terpisah antara Agustus dan September 2026: Calif, Wiz, dan OpenAI. Quarkslab ikut tercatat sebagai pelapor pada CVE pertama. Ketiganya memakai model AI frontier untuk menggali kode sumber PHP. Wiz menyebut Gemini 4 Argon dan GPT-5.6 Sol sebagai alat utama mereka, sementara PHP Foundation menyebut pemindaian awal dilakukan dengan Claude Mythos lewat program Alpha-Omega, lalu dilanjutkan dengan OpenAI Daybreak Red untuk memvalidasi laporan dan exploit.

Ini bagian yang paling sering dilewatkan orang. Celahnya sudah ada di sana selama lebih dari satu dekade. Yang berubah bukan kodenya, tapi kemampuan menemukan dan mengeksploitasinya. Wiz menulis bahwa membangun exploit untuk bug ini butuh rantai beberapa cacat sekaligus dan penyesuaian terhadap tata letak memori tiap target. Sebelum era AI, pekerjaan itu di ambang batas kemampuan manusia.

Kenapa ini bukan masalah WordPress

Kedua celah hidup di bagian PHP yang disentuh hampir setiap request: manajemen memori dan penanganan error. Karena itu, aplikasi yang kodenya bersih pun tetap terpapar. Wiz mendemonstrasikan eksekusi kode jarak jauh tanpa autentikasi pada WordPress, Drupal, dan Joomla memakai image container terbaru saat pengujian. Sansec menambahkan daftar yang lebih panjang: Magento 2.4.9, MediaWiki 1.46.2, Roundcube 1.7.4, phpMyAdmin 5.2.3, Nextcloud 35.0.1, Laravel 13.11, Symfony 8.1, dan WHMCS.

Angka yang beredar soal pangsa pasar PHP cukup konsisten. Wiz menyebut 70 persen dari seluruh website di dunia, Imperva mengutip 69 persen situs yang bahasa server-side-nya diketahui, dan Cloudflare memakai angka hampir 70 persen merujuk data W3Techs. Yang menopang angka itu bukan situs kecil saja. Wikipedia berjalan di MediaWiki. Sebagian besar toko online berjalan di WooCommerce dan Magento. Blog, portal berita, sistem sekolah, sampai panel admin hosting.

Wiz menyebut setiap versi PHP yang dirilis dalam sepuluh tahun terakhir terpengaruh oleh setidaknya satu dari dua celah ini, mundur sampai versi 5.4.0. Pada Apache dengan mod_php, request tanpa autentikasi bisa memicu jalur serangan sebelum satu baris pun kode aplikasi dijalankan. Eksploitasi penuh juga dikonfirmasi lewat PHP-FPM, meski harus melewati jalur kode di level aplikasi.

Versi yang wajib dipasang

• PHP 8.5 ke 8.5.12
• PHP 8.4 ke 8.4.27
• PHP 8.3 ke 8.3.36
• PHP 8.2 ke 8.2.35

PHP 8.1 dan yang lebih lama sudah di luar dukungan resmi, jadi tidak ada rilis rutin untuk cabang itu. Tim keamanan PHP tetap menyediakan backport sumber minimal untuk 7.4, 8.0, dan 8.1 di repositori php-src, khusus untuk yang membangun sendiri dari source atau tidak punya akses ke vendor LTS. Distribusi Linux dan vendor LTS sudah menerima patch lebih dulu, jadi paket dari Ubuntu, Red Hat, Debian, atau Alpine kemungkinan membawa nomor versi upstream yang lebih tua dengan perbaikan yang sudah di-backport.

Bagaimana celahnya bekerja

PHP memakai mekanisme bailout berbasis longjmp() untuk menghentikan pemrosesan request ketika terjadi kondisi fatal, termasuk saat memori menembus batas memory_limit. Masalahnya muncul ketika bailout terjadi setelah PHP mempublikasikan sebuah pointer atau mengalokasikan slot cache, tapi sebelum pembersihannya berjalan. Hasilnya adalah state setengah jadi yang masih bisa diakses.

Pada deployment berbasis worker, satu proses melayani banyak request berurutan. Request berikutnya yang masuk ke worker yang sama bisa menemukan pointer ke memori yang sudah dibebaskan request sebelumnya. Di sinilah use-after-free terjadi, dan dari situ penyerang bisa menaruh data yang dia kendalikan di ruang memori tersebut.

Wiz memecahnya jadi empat bug. Pertama, use-after-free pada unserializer upload-progress, yang jadi primitif utama untuk rantai eksekusi kode. Kedua, kebocoran memori proses lewat cookie PHPSESSID, yang bekerja bahkan kalau aplikasi tidak pernah memanggil session_start(). Ketiga, use-after-free pada backtrace fatal error yang disimpan di EG(last_fatal_error_backtrace). Keempat, type confusion pada OPcache yang melibatkan frontier bersama antar worker.

Bug kedua layak diberi perhatian sendiri. Tanpa perlu mengeksekusi kode, penyerang bisa membaca sebagian memori worker PHP yang sedang hidup. Isinya bisa berupa password, token autentikasi, API key, dan sertifikat milik request lain atau milik server itu sendiri. Bagi pemilik aplikasi, ini mimpi buruk yang tidak meninggalkan jejak di log aplikasi.

Pengungkapan yang berantakan

PHP Foundation menulis blog yang isinya tidak biasa: mereka mengkritik Chainguard, perusahaan keamanan supply chain, karena dianggap membocorkan embargo. Menurut kronologi resmi, pada 21 Oktober pukul 07:41 UTC, lebih dari enam jam sebelum rilis terkoordinasi, Chainguard menerbitkan image yang sudah berisi perbaikan. Padahal mereka menerima patch lebih awal dengan syarat yang sama seperti distributor lain: agar pengguna bisa update tepat saat pengumuman keluar.

CEO Chainguard Dan Lorenc tidak menyangkal urutan waktunya. Dia membantah kalau perusahaannya disebut membocorkan celah. Kepada The Register dia menjelaskan bahwa pada Jumat malam timnya menemukan sendiri kerentanan memory corruption yang sama, memakai harness AI mereka dan sebuah model frontier. Petunjuk yang dipakai sesederhana prompt "find bad vulnerabilities in PHP". Sabtu mereka mulai bekerja dengan maintainer PHP dan membantu menguji patch.

Lorenc beralasan bahwa pada Selasa malam sudah ada bukti eksploitasi di lapangan dan proof of concept beredar di media sosial, sehingga dia memutuskan mengirim perbaikan lebih cepat. "Kami ambil keputusan itu," katanya. Ditanya apakah akan melakukan hal berbeda, jawabannya tidak. Honeypot Chainguard sendiri menangkap IP dari Tiongkok dan Rusia yang membidik celah ini pada Rabu.

Yang menarik, PHP Foundation juga mengakui kesalahan sendiri dengan bahasa yang cukup keras. Mereka menyebut penundaan perbaikan selama bertahun-tahun sebagai kegagalan struktural, akibat proses pengambilan keputusan tim keamanan yang berbasis konsensus dan kurangnya sumber daya. Persoalan OOM ini sudah ditemukan sejak audit Quarkslab pada 2024, tapi jalur eksploitasinya baru terbukti sekarang.

Bukti serangan sudah ada

Cloudflare menyatakan proteksi WAF untuk php2shell sudah aktif sejak 21 Oktober pukul 03:02 UTC, sekitar sembilan jam sebelum pengungkapan resmi. Artinya trafik serangan sudah terlihat sebelum patch tersedia untuk umum. Sansec mencatat serangan awal pada 07:43 UTC di hari yang sama, sementara jadwal rilis resmi jatuh sekitar 14:00 UTC.

Cloudflare juga melaporkan bahwa penyerang memutasi payload untuk mencoba melewati aturan mereka, dengan cara melacak volume kecocokan lalu membandingkannya dengan logika rule. Karena itu mereka membangun deteksi berbasis transaksi penuh, yang menggabungkan sinyal dari request dan response dalam satu transaksi HTTP. Proteksi ini berlaku otomatis untuk semua paket WAF, termasuk yang gratis.

Di Belanda, reaksi publiknya cukup dramatis. Tweakers, Tweede Kamer, NCSC, dan Security.NL memilih menurunkan situs mereka sebagai langkah pencegahan pada 21 Oktober. Core developer PHP Gina Peter Banyard sebelumnya menyebut opsi mematikan server sebagai pilihan paling masuk akal sebelum rilis.

Yang harus Anda lakukan sekarang

Urutan tindakannya sederhana, dan tidak ada jalan pintas. Perbaikan hanya datang dari update PHP di server. Mengganti tema, menambal plugin, atau memasang firewall di WordPress tidak menutup celah ini.

1. 1Cek versi PHP di setiap server, bukan hanya di server utama. Jalankan php -v lewat SSH dan periksa juga phpinfo() di subdomain, staging, dan panel admin yang sering terlupakan.
2. 2Update ke 8.5.12, 8.4.27, 8.3.36, atau 8.2.35. Kalau pakai paket distribusi, jalankan upgrade paket dan pastikan service PHP sudah di-restart, bukan hanya paketnya yang terpasang.
3. 3Kalau server dikelola hosting atau agency, kirim tiket sekarang dan minta konfirmasi versi setelah update. Jangan berhenti di jawaban "sudah kami tangani".
4. 4Kalau belum bisa update dalam hitungan jam, set memory_limit=-1 lewat php_admin_value di konfigurasi pool FPM atau Apache, supaya aplikasi tidak bisa menimpanya kembali.
5. 5Batasi post_max_size ke 8M untuk aplikasi tanpa upload, atau 32M kalau upload memang dibutuhkan. Pastikan upload_max_filesize lebih kecil dari post_max_size.
6. 6Blokir request multipart/form-data di web server sebagai langkah sementara. Untuk nginx, tambahkan pengecekan Content-Type dan kembalikan 403. Untuk Apache, pakai RewriteCond pada header Content-Type lalu tandai [F]. Setelah itu uji ulang proses checkout dan upload, karena aturan ini mematikan keduanya.
7. 7Pasang batas ukuran container atau cgroup sebagai pagar ketersediaan, dan aktifkan proteksi WAF dari penyedia yang sudah punya aturan untuk php2shell.
8. 8Kalau server Anda sempat berjalan tanpa patch sejak 21 Oktober, rotasi kredensial yang pernah lewat proses PHP: kredensial database, API key, token sesi, dan secret di file .env.

Tanda server sudah disentuh

Karena eksekusinya terjadi di bawah lapisan aplikasi, log WordPress atau Laravel tidak akan bercerita banyak. Wiz menyarankan pemburu ancaman mencari pola berikut di log web server dan metrik proses:

• Request multipart yang tidak wajar, langsung diikuti error batas memori.
• HTTP 500 yang berulang dalam pola rapat pada endpoint yang sama.
• Cookie PHPSESSID di response yang ukurannya jauh lebih besar dari biasanya atau formatnya rusak.
• Worker PHP yang mati dan diganti terus-menerus tanpa penjelasan, atau lonjakan konsumsi memori yang tidak berhubungan dengan trafik.

Catatan penutup

Bagian yang membuat saya berhenti membaca dua kali bukan soal CVSS 9.2. Bukan juga soal 70 persen web. Ini soal waktu. Celah yang butuh satu dekade untuk dipahami manusia, pada 2026 bisa ditemukan ulang oleh sebuah prompt pendek dan satu model frontier dalam hitungan jam, oleh CEO perusahaan keamanan yang penasaran di malam Jumat.

Kalau penemuan bisa dipercepat seperti itu, eksploitasi juga. Lorenc sendiri menyebut ini sebagai norma baru: orang bisa membangun exploit dalam beberapa jam tanpa tahu persis apa celahnya. Artinya jendela antara "patch tersedia" dan "sistem saya sudah dipatch" jadi jauh lebih mahal daripada sebelumnya. Dulu kita punya beberapa minggu untuk menunda update. Sekarang tidak.

Untuk pemilik website kecil, saran praktisnya cuma satu: buka panel hosting, cek versi PHP, dan update hari ini. Kalau hosting Anda masih menawarkan PHP 7.4 sebagai pilihan default, itu tanda bagus untuk mulai mencari penyedia lain. Bukan karena mereka jahat, tapi karena mereka tidak akan sanggup mengejar ritme pengungkapan celah seperti ini.