PHP2Shell: Dua Celah RCE Kritis PHP Bocor Sebelum Patch Rilis, Ini yang Perlu Dilakukan

Kalau kemarin timeline keamanan siber Anda mendadak ramai, kemungkinan besar penyebabnya PHP2Shell. Dua celah remote code execution (RCE) di inti PHP bocor sebelum jadwal disclosure resmi, dan patch-nya akhirnya dirilis dipercepat satu hari.

Karena PHP masih menjalankan sebagian besar web di internet, ini bukan berita yang boleh dilewatkan, termasuk oleh yang merasa “saya kan cuma pakai WordPress”. Tulisan ini merangkum apa yang terjadi, siapa yang terdampak, dan apa yang perlu dikerjakan hari ini. Semua fakta saya ambil dari advisory resmi PHP dan laporan media serta vendor keamanan. Daftar rujukannya ada di bagian akhir.

Catatan: situasinya masih bergerak cepat. Jika ada detail yang berbeda dengan advisory resmi PHP, ikuti advisory resmi.

Apa itu PHP2Shell?

PHP2Shell adalah nama yang dipakai peneliti dan media untuk dua kerentanan kritis di interpreter inti PHP. Nama dan nomor CVE-nya berasal dari peneliti dan unggahan yang bocor, bukan dari penamaan resmi PHP.

Keduanya dinilai CVSS v4.0 9.2 (Critical) dan memungkinkan RCE tanpa autentikasi. Unggahan yang bocor sempat mengklaim skor 10.0, tetapi PHP menetapkan 9.2.

Kata kuncinya ada di bagian “inti PHP”. Celah ini bukan di WordPress, Laravel, atau Magento, melainkan di mesin PHP-nya. Dalam eksploit yang didemonstrasikan, serangan berjalan sebelum kode aplikasi dieksekusi. Jadi kode aplikasi yang rapi tidak melindungi Anda, dan memperbarui CMS saja tidak cukup.

Menurut laporan SecurityWeek, Wiz menyebut kedua CVE ini mewakili empat masalah keamanan memori, dan masih mungkin ada varian lain yang belum terlacak.

Kronologi singkat

• Agustus 2026: Peneliti dari Wiz, OpenAI, dan Calif menemukan kerentanan ini dan merahasiakannya sambil mengoordinasikan perbaikan. Calif dan OpenAI melaporkan masalah OOM-ke-RCE secara terpisah pada 11 Agustus.
• 20 Oktober: Sebuah unggahan di forum Hacker News menyebut dua celah RCE kritis PHP akan diumumkan 22 Oktober. Unggahan itu dihapus, tetapi tangkapan layarnya sudah menyebar. Peneliti watchTowr mengonfirmasi informasinya nyata dan masih dalam embargo. Pada hari yang sama tim keamanan PHP mengumumkan rilis keamanan di luar jadwal.
• 21 Oktober: PHP merilis patch, lebih cepat dari rencana disclosure. Advisory resmi terbit pada hari yang sama.
• 21 Oktober, hampir bersamaan: Beberapa vendor keamanan melaporkan percobaan eksploitasi, sebagian bahkan sebelum patch tersedia.

Ada juga dua kejadian yang memicu kontroversi, menurut SecurityWeek. Sebuah video yang menampilkan PoC yang berfungsi sempat terpublikasi lebih awal dari jadwal. Lalu Chainguard merilis image berisi perbaikan sekitar enam jam sebelum rilis terkoordinasi. PHP Foundation menilai langkah itu memberi penyerang kesempatan mempelajari perbaikan dalam bentuk biner sebelum pengguna lain sempat menambal.

Siapa yang terdampak?

Hampir semua rilis PHP, mundur sampai PHP 5.4, dan semua cara menjalankan PHP yang melayani request web:

• PHP-FPM
• Apache dengan mod_php (dinilai PHP sebagai yang paling berisiko)
• php-cgi
• FrankenPHP
• LiteSpeed

Aplikasi seperti WordPress, Drupal, Joomla, dan Magento ikut terdampak karena berjalan di atas PHP yang rentan. Wiz memperkirakan celah ini menyentuh sekitar 70% situs web, apa pun CMS-nya. Kedua celah juga bisa dipakai untuk membaca memori proses yang sensitif, yang mungkin berisi kredensial dan API key.

Yang sering terlewat:

• PHP yang ikut terpasang di dalam aplikasi vendor atau appliance
• Panel hosting seperti cPanel dan Plesk
• Binary Windows php.exe dan php-cgi.exe
• Base image container yang sudah lama tidak di-rebuild

Status eksploitasi

Menurut SecurityWeek, watchTowr mulai melihat percobaan eksploitasi di internet sekitar waktu patch rilis, tetapi belum mengamati eksploitasi yang berhasil. Hadrian melaporkan eksploitasi dalam skala besar beberapa jam sebelum patch rilis, sebagian besar lewat fitur session upload progress PHP. Patchstack dan Cloudflare juga melaporkan percobaan sejak awal 21 Oktober. Arctic Wolf menambahkan bahwa mereka melihat aktivitas pemindaian dan percobaan eksploitasi yang mengunduh binary ELF dan Golang lewat wget, yang terkait malware komoditas.

Dengan PoC publik yang beredar, anggap saja masa tenggang sudah habis.

Solusi utama: update PHP

PHP menyatakan hanya satu cara yang benar-benar aman, yaitu memperbarui. Rilis perbaikannya:

Sebelum patch rilis, beberapa laporan sempat menyebut cabang 8.1 ke bawah tidak mendapat perbaikan sama sekali. Advisory resmi kemudian menyebut adanya minimal source backport untuk 7.4, 8.0, dan 8.1. Distro dan vendor LTS juga sudah menerima patch lebih dulu.

Langkah praktis

1. Inventarisasi dulu. Cari semua tempat PHP berjalan, termasuk yang tidak terpikir.

# Ubuntu / Debian
dpkg -l | grep php

# RHEL / Rocky / AlmaLinux / CentOS
rpm -qa | grep php

# Alpine (container)
apk info | grep php

2. Update dari sumber yang benar. Pakai paket distro atau vendor Anda, atau rilis dari php.net. Prioritaskan server yang menghadap internet.

Distro sering menambal tanpa mengubah nomor versi, jadi nomor yang tampak lama belum tentu rentan. Pastikan dengan memeriksa changelog paket:

# Ubuntu / Debian
apt changelog php8.3-cli | grep -E "CVE-2026-109618|CVE-2026-109619"

# RHEL / Rocky / AlmaLinux
rpm -q php-cli --changelog | grep -E "CVE-2026-109618|CVE-2026-109619"

3. Restart semuanya. Menginstal paket saja tidak cukup, karena worker lama masih memakai kode lama di memori. Restart PHP-FPM, Apache, dan worker aplikasi.

4. Rebuild container. Menambal container yang sedang berjalan membuat image-nya tetap rentan. Bangun ulang image dari base yang sudah dipatch, lalu deploy ulang.

5. Catat buktinya. Simpan versi terpasang, referensi advisory, waktu restart, dan hasil verifikasi untuk tiap host atau image. Ini berguna untuk audit dan insiden berikutnya.

Mitigasi sementara jika belum bisa update

Bagian ini penting dibaca dengan benar: ini bukan pengganti patch. Catatan rilis PHP sendiri menyatakan tidak ada mitigasi yang lengkap. Langkah di bawah hanya mengurangi sebagian jalur serangan, dan saya ambil dari panduan Arctic Wolf yang merujuk advisory PHP.

Untuk CVE-2026-109618 (OOM):

• Setel memory_limit=-1 dengan cara yang tidak bisa ditimpa aplikasi, misalnya php_admin_value di pool FPM atau konfigurasi Apache.
• Turunkan post_max_size, misalnya 8M jika tidak ada fitur unggah dan 32M jika ada. Jaga upload_max_filesize tetap di bawahnya.
• Terapkan batas ukuran request, jumlah field, dan header di web server atau reverse proxy.
• Jangan memakai RLIMIT_AS atau RLIMIT_DATA, karena justru bisa memicu kegagalan alokasi memori yang rentan itu.

Untuk CVE-2026-109619 (stale state):

• Setel session.upload_progress.enabled=0 di php.ini, atau di konfigurasi pool FPM atau server yang berlaku sebelum request diparsing, lalu restart semua worker. Ini hanya menutup jalur sesi yang sudah terkonfirmasi, bukan varian lain.
• Di PHP 8.5, setel fatal_error_backtraces=0 lalu restart semua worker.
• Perbaiki fatal error dan execution timeout yang bisa dipicu dari luar.

Lapisan tambahan di jaringan:

• Aktifkan proteksi IPS atau WAF dengan signature terbaru dalam mode prevent. Ini mengurangi risiko, tetapi bukan pengganti update PHP.
• Batasi egress dari web server hanya ke tujuan yang memang diperlukan, supaya shell yang berhasil masuk sulit mengunduh payload.
• Jika sebuah aplikasi PHP yang menghadap internet benar-benar tidak bisa ditambal, CERT-EU menyarankan mengisolasinya, misalnya di belakang VPN atau kontrol akses, atau menurunkannya sementara.

Cek apakah sudah telanjur disusupi

Karena percobaan eksploitasi sudah terjadi sebelum patch rilis, jangan berhenti di update. Periksa juga:

• Web shell atau file .php baru di webroot, terutama folder upload, cache, dan tmp
• Proses web server (php-fpm, httpd, www-data) yang memanggil sh, bash, curl, wget, python, atau nc
• Crash atau restart mendadak pada worker PHP (segfault di log)
• POST multipart/form-data yang besar atau tidak wajar, terutama ke endpoint yang tidak menerima unggahan
• Koneksi keluar baru dari web server ke host asing sesaat setelah request masuk
• Cron job, scheduled task, atau akun baru yang tidak dikenal

Jika ada tanda mencurigakan, isolasi server, amankan log web server dan PHP, lalu telusuri persistensi dan pergerakan lateral. Karena celah ini juga bisa membocorkan isi memori, rotasi kredensial dan API key di server yang terpapar sebelum patch.

Pelajaran yang bisa dibawa pulang

Beberapa hal yang menurut saya layak dicatat dari kejadian ini:

1. Inventaris aset adalah fondasi. Pertanyaan pertama saat insiden seperti ini selalu “di mana saja kita pakai PHP?”. Tim yang sudah punya jawabannya akan jauh lebih cepat.
2. Embargo itu rapuh. Satu unggahan forum dan satu rilis image yang terlalu awal cukup untuk mempersempit jendela patch. Proses patching harus siap kapan saja, tidak hanya menunggu jadwal.
3. Software EOL adalah utang keamanan. Cabang 8.1 ke bawah tidak lagi mendapat rilis resmi dan hanya bergantung pada backport. Menunda migrasi punya harga yang akhirnya ditagih.
4. Defense in depth tetap penting. Pembatasan egress, deteksi proses mencurigakan, dan WAF tidak menggantikan patch, tetapi memberi waktu dan visibilitas saat patch belum bisa diterapkan.

PHP Foundation juga mencatat ada 15 CVE PHP baru sejak 1 Juli, dan menyebut AI ikut membantu menemukan lebih banyak kerentanan. Jadi ritme patch semacam ini kemungkinan akan makin sering. Sebaiknya proses update PHP di tim Anda dibuat rutin dan otomatis, bukan hanya jadi respons darurat.

Semoga bermanfaat. Silakan bagikan ke teman atau tim yang masih menjalankan PHP di production.

Sumber

• Security advisory PHP: Critical remote code execution vulnerabilities, update now (php.net, 21 Oktober 2026)
• Advance notice PHP security release (php.net, 20 Oktober 2026)
• GHSA-w8hw-w9fx-j79w (CVE-2026-109618) dan GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
• PHP2Shell Patches Land as First Exploitation Attempts Hit Sensors (SecurityWeek)
• PHP2Shell: Mass Exploitation Looms for Leaked Critical PHP Flaws (SecurityWeek)
• Critical PHP Vulnerabilities Leaked Ahead of Scheduled Security Patch (Infosecurity Magazine)
• Patch Now: php2shell, What We Know About the Leaked Critical PHP Vulnerabilities (Check Point)
• Finding, Prioritizing, and Patching PHP2Shell Exposure (Arctic Wolf Labs)