PHP2Shell (CVE-2026-109618 & CVE-2026-109619): Celah RCE PHP yang Viral, Cara Cek dan Patch

PHP2Shell adalah sebutan untuk dua celah eksekusi kode jarak jauh (RCE) di inti PHP, CVE-2026-109618 dan CVE-2026-109619, yang bisa dieksploitasi tanpa login dan masing-masing bernilai CVSS v4 9.2. Celahnya berada di runtime PHP, bukan di kode aplikasi, sehingga situs dengan kode yang rapi pun tetap rentan selama versi PHP-nya belum diperbarui.

PHP merilis perbaikan pada 21 Oktober 2026 di versi 8.5.12, 8.4.27, 8.3.36, dan 8.2.35. Lima hari kemudian CISA memasukkan keduanya ke katalog Known Exploited Vulnerabilities (KEV), dan pada 29 Oktober Palo Alto Networks mengonfirmasi eksploitasi aktif. Artikel ini merangkum kronologi, cara kerja kedua celah, cara mengecek server Anda, mitigasi sementara, dan celah lanjutan CVE-2026-115560.

Ringkasan PHP2Shell

Aspek	Detail
CVE	CVE-2026-109618 (korupsi memori saat OOM), CVE-2026-109619 (use-after-free antar-request)
Skor	CVSS v4 9.2 (Critical), masing-masing
Dampak	RCE tanpa autentikasi dengan hak akses proses web worker
Terdampak	Semua instalasi PHP yang melayani request web: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, LiteSpeed
Paling berisiko	Apache mod_php
Versi perbaikan	8.2.35, 8.3.36, 8.4.27, 8.5.12 (rilis 21 Oktober 2026)
Penemu	Peneliti dari Wiz, Calif, dan OpenAI
Status	Masuk CISA KEV 26 Oktober 2026; eksploitasi aktif dikonfirmasi
Paparan	Lebih dari 22,6 juta instance berpotensi rentan menurut telemetri Palo Alto Networks

Kenapa PHP2Shell sempat viral?

Celah ini ramai dibicarakan bahkan sebelum patch keluar. Pada 20 Oktober, sebuah unggahan di Hacker News mengklaim dua celah RCE PHP dengan skor CVSS 10.0 yang memengaruhi versi sejak PHP 5 akan diumumkan pada 22 Oktober. Karena detailnya bocor sebelum embargo berakhir, PHP memajukan rilis perbaikan satu hari menjadi 21 Oktober pukul 14.00 UTC.

Ada tiga alasan celah ini dianggap serius:

• Skalanya. PHP menjalankan sebagian besar situs di internet, termasuk WordPress, Laravel, dan berbagai panel hosting. Celah dilaporkan memengaruhi hampir semua versi sejak PHP 5.4.
• Tanpa login. Penyerang cukup mengirim request HTTP yang dirancang khusus.
• Tidak bergantung aplikasi. Di mod_php, serangan yang didemonstrasikan bisa berhasil sebelum satu baris kode aplikasi pun dijalankan.

Satu koreksi atas kabar yang beredar: skor 10.0 berasal dari unggahan yang bocor, bukan dari PHP. Penilaian resmi PHP adalah 9.2 untuk kedua celah.

Bagaimana kedua celah ini bekerja?

CVE-2026-109618: korupsi memori saat kehabisan memori

Ketika alokasi memori gagal, PHP bisa menghentikan pemrosesan request secara mendadak. Kalau data internal request baru terisi sebagian, proses pembersihan (cleanup) kemudian memakai data yang tidak valid. Request multipart yang dirancang khusus, jenis yang dipakai untuk form dan unggah file, bisa menghabiskan memori meski ukurannya tampak masih di bawah batas konfigurasi PHP.

Di Apache mod_php, cleanup tetap berjalan walaupun startup request gagal, sehingga serangan bisa dilakukan sebelum kode aplikasi berjalan, dengan batas memori dan input bawaan. PHP-FPM menghentikan worker ketika startup gagal sehingga jalur ini tertutup, tetapi analisis kode tetap menunjukkan FPM rentan setelah startup berhasil. Sejauh ini belum ada exploit FPM lengkap untuk CVE ini.

CVE-2026-109619: memori basi yang terbawa ke request berikutnya

Satu proses worker PHP biasa dipakai untuk banyak request. Celah ini muncul karena ada state internal yang masih menunjuk ke memori yang sudah dibebaskan di akhir request sebelumnya. Request berikutnya yang ditangani worker yang sama bisa membaca nilai basi tersebut sebelum inisialisasi normal membersihkannya. Fatal error, seperti kehabisan memori atau timeout eksekusi, adalah pemicu umum karena memotong proses pembersihan.

Advisory PHP mengonfirmasi dua jalur RCE:

• Fatal error backtrace di PHP 8.5 (opsi fatal_error_backtraces, aktif secara default) pada mod_php.
• Siklus hidup session pada mod_php dan FPM, lewat fitur session upload progress yang aktif secara default. Jalur ini bisa terpicu walaupun aplikasi Anda tidak pernah memanggil session_start().

Apakah PHP2Shell sudah dieksploitasi?

Sudah, walaupun gambarannya bertahap:

Tanggal (2026)	Kejadian
20 Oktober	Detail celah bocor di Hacker News sebelum embargo
21 Oktober	PHP merilis 8.5.12, 8.4.27, 8.3.36, 8.2.35 dan dua advisory
21-24 Oktober	Cloudflare dan peneliti lain melaporkan percobaan eksploitasi awal; beberapa PoC publik muncul
23 Oktober	PHP mengumumkan celah lanjutan CVE-2026-115560 (lihat bagian di bawah)
26 Oktober	CISA memasukkan kedua CVE ke KEV dengan tenggat instansi federal AS 29 Oktober
29 Oktober	Palo Alto Networks mengonfirmasi eksploitasi terhadap antarmuka manajemen PAN-OS yang terbuka ke internet

Rapid7 menilai PoC publik yang beredar masing-masing hanya berhasil pada kombinasi OS, versi PHP, dan web server tertentu, dan belum ada yang andal secara umum. Rapid7 menyebut kondisi ini sebagai jendela waktu untuk menambal, bukan alasan untuk menunda, karena teknik yang lebih portabel bisa muncul kapan saja.

Kasus PAN-OS menunjukkan seperti apa serangan nyatanya. Dream Research melaporkan kampanye yang merangkai PHP2Shell dengan celah eskalasi hak akses di kernel Linux untuk mendapatkan akses root, dan Unit 42 dari Palo Alto Networks memverifikasi perangkat serangan yang sama. Menurut Palo Alto, hanya sekitar 0,02% basis pelanggannya yang membuka antarmuka manajemen ke internet dan terdampak.

Versi PHP mana yang aman?

Cabang	Versi rentan	Versi perbaikan
PHP 8.5	Sebelum 8.5.12	8.5.12
PHP 8.4	Sebelum 8.4.27	8.4.27
PHP 8.3	Sebelum 8.3.36	8.3.36
PHP 8.2	Sebelum 8.2.35	8.2.35
PHP 7.4, 8.0, 8.1	Semua	Backport source terbatas dari PHP, atau paket vendor/distro
PHP 7.x lain dan 5.x	Semua	Tidak ada perbaikan dari PHP; upgrade atau isolasi

Distribusi Linux dan vendor LTS menerima patch lebih awal, jadi paket distro bisa sudah aman walaupun nomor versinya masih terlihat lama karena perbaikannya di-backport. Pembaruan yang memuat kedua perbaikan secara lengkap adalah satu-satunya remediasi penuh.

Bagaimana cara mengecek server saya?

Pertama, cek versi PHP dan paket yang terpasang. Di server dengan backport, versi paket distro lebih bisa dipercaya daripada angka php -v.

# Versi PHP CLI
php -v

# Versi PHP-FPM (sesuaikan nomor versinya)
php-fpm8.3 -v

# Debian/Ubuntu: versi paket distro (cocokkan dengan advisory keamanan distro)
dpkg -l | grep -E '^ii\s+(php|libapache2-mod-php)'

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

Ingat bahwa satu server bisa punya beberapa versi PHP sekaligus, misalnya di cPanel, Plesk, atau server dengan banyak pool FPM. Pastikan setiap runtime yang melayani request web sudah diperbarui, bukan hanya PHP CLI.

Setelah update, restart semua proses PHP. Paket baru yang sudah terpasang tidak berarti apa-apa selama worker lama masih berjalan.

sudo systemctl restart php8.3-fpm   # ulangi untuk setiap versi FPM
sudo systemctl restart apache2      # bila memakai mod_php (httpd di RHEL)

Mitigasi sementara kalau belum bisa update

PHP menyediakan langkah konfigurasi untuk mengurangi paparan pada jalur serangan tertentu. Semuanya hanya mengurangi risiko, tidak menutup celah, dan wajib diikuti restart semua worker.

1. Matikan session upload progress di php.ini, pool FPM, atau konfigurasi server. Ini menutup jalur session yang terkonfirmasi, dan juga jalur CVE-2026-115560. Mengaturnya lewat ini_set() atau .user.ini sudah terlambat karena request sudah diparsing.
2. Di PHP 8.5, matikan fatal_error_backtraces secara administratif.
3. Untuk celah OOM, PHP menyarankan memory_limit=-1 yang dipaksakan di level server sehingga aplikasi tidak bisa mengubahnya. Langkah ini menghapus batas memori per request, jadi wajib diimbangi batas lain: post_max_size=8M bila tidak butuh unggah file atau 32M bila butuh, upload_max_filesize di bawahnya, dan batas ukuran request di reverse proxy. Bila aplikasi tidak memakai multipart, blokir request multipart sebelum sampai ke PHP.

Contoh untuk pool PHP-FPM (misalnya /etc/php/8.3/fpm/pool.d/www.conf):

php_admin_flag[session.upload_progress.enabled] = off
; khusus PHP 8.5:
php_admin_flag[fatal_error_backtraces] = off

Contoh untuk Apache mod_php:

php_admin_flag session.upload_progress.enabled off

Beberapa hal yang tidak membantu dan perlu dihindari:

• Menyembunyikan error lewat display_errors, error_reporting, log_errors, atau operator @ tidak mencegah akses ke state basi.
• Memakai RLIMIT_AS atau RLIMIT_DATA sebagai pengganti batas memori justru bisa memicu jalur yang rentan.
• Batas memori container atau cgroup tidak cukup, dan bisa mematikan master process beserta semua worker.
• Log yang bersih bukan bukti server aman.

Apa itu CVE-2026-115560?

Dua hari setelah patch darurat, pada 23 Oktober, PHP mengumumkan celah ketiga yang tidak diperbaiki oleh rilis 21 Oktober. Celah ini hanya berlaku pada konfigurasi yang tidak biasa, yaitu aplikasi yang:

1. mengatur session.serialize_handler ke php_binary atau php_serialize di konfigurasi, lalu
2. mengubahnya ke php saat runtime dengan ini_set(),
3. sebelum memanggil session_start().

PHP menilai skenario ini jarang terjadi, sehingga perbaikannya masuk siklus rilis rutin, bukan rilis darurat. Belum ada laporan eksploitasi. Rekomendasi PHP sampai perbaikan terbit sama dengan mitigasi di atas: matikan session.upload_progress.enabled. Periksa juga kode aplikasi Anda untuk pemanggilan ini_set('session.serialize_handler', ...).

Ada juga laporan regresi stabilitas memori pada versi yang sudah ditambal. Laporan ini terpisah dari PHP2Shell dan tidak terbukti bisa dipakai untuk RCE. Jangan kembali ke versi lama hanya karena regresi ini.

Bagaimana mendeteksi server yang mungkin sudah dibobol?

Kalau server Anda terbuka ke internet dan belum ditambal sejak 21 Oktober, anggap ada kemungkinan sudah disusupi dan periksa tanda-tanda berikut. Pola ini diringkas dari kueri threat hunting Unit 42, dan berlaku umum untuk eksploitasi aplikasi web PHP.

• Proses PHP melahirkan shell atau perintah sistem. Worker php-fpm, apache2/httpd, lsphp, atau user www-data/apache/nginx yang menjalankan whoami, id, uname -a, cat /etc/passwd, atau ps aux.
• Unduhan payload. curl atau wget yang menulis file, terutama ke /tmp, /var/tmp, atau /dev/shm, diikuti chmod +x.
• Binary yang berjalan dari direktori sementara atau dari file yang sudah dihapus.
• Reverse shell, misalnya /dev/tcp/, nc -e, mkfifo, atau curl ... | sh.
• Persistensi. Crontab baru untuk user web, perubahan authorized_keys, user baru, atau unit systemd baru.
• Akses kredensial. Pembacaan file .env, kredensial cloud, atau metadata service 169.254.169.254.

# Contoh cepat: proses yang dijalankan user web
ps -eo user,pid,ppid,cmd --forest | grep -E '^(www-data|apache|nginx)'

# File executable baru di direktori sementara dalam 10 hari terakhir
find /tmp /var/tmp /dev/shm -type f -perm -u+x -mtime -10 -ls

# Crontab milik user web
sudo crontab -u www-data -l

Bila ada temuan, rotasi semua secret yang bisa dibaca aplikasi (kredensial database, API key, isi .env), lalu pertimbangkan membangun ulang server dari image yang bersih.

Checklist singkat untuk hari ini

1. Inventaris semua server, container, dan akun hosting yang menjalankan PHP, termasuk staging dan panel admin perangkat jaringan.
2. Update ke 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 atau paket distro yang memuat kedua perbaikan.
3. Restart semua worker PHP-FPM dan Apache.
4. Matikan session.upload_progress.enabled di level server, untuk berjaga terhadap CVE-2026-115560.
5. Tutup akses internet ke antarmuka manajemen perangkat (firewall, router, panel hosting).
6. Jalankan pemeriksaan jejak penyusupan di atas, dan rotasi secret bila ada tanda mencurigakan.
7. Untuk PHP 7.x atau 8.0-8.1, rencanakan upgrade ke cabang yang masih didukung.

Pertanyaan yang sering diajukan

Saya pakai shared hosting. Apa yang perlu dilakukan?

Versi PHP di shared hosting dikelola penyedia. Cek pengumuman atau status page penyedia Anda, pastikan mereka sudah memasang versi perbaikan, lalu pilih versi PHP terbaru yang tersedia di panel. Beberapa penyedia besar sudah memasang mitigasi sejak sebelum patch dirilis.

Situs saya WordPress/Laravel yang selalu di-update. Apakah aman?

Belum tentu. Celahnya ada di runtime PHP, bukan di WordPress atau Laravel, jadi yang perlu diperbarui adalah PHP-nya.

Apakah PHP CLI atau cron job ikut terdampak?

Advisory menyoroti instalasi yang melayani request web. Risiko terbesar ada pada PHP-FPM, mod_php, php-cgi, FrankenPHP, dan LiteSpeed yang menerima request dari internet.

Apakah mitigasi konfigurasi sudah cukup?

Tidak. PHP menegaskan pembaruan yang memuat kedua perbaikan adalah satu-satunya remediasi lengkap. Mitigasi hanya menutup jalur serangan yang sudah terkonfirmasi.

Apakah exploit-nya sudah publik?

Beberapa PoC publik sudah beredar dan eksploitasi aktif sudah dikonfirmasi, termasuk kampanye yang merangkai PHP2Shell dengan celah kernel Linux untuk mendapatkan root. Perlakukan sebagai prioritas darurat.

Sumber

• CVE-2026-109618 and CVE-2026-109619: Critical Unauthenticated RCE in PHP, Rapid7
• Threat Brief: Critical Vulnerabilities in PHP, Unit 42 Palo Alto Networks
• Security advisory: Critical remote code execution vulnerabilities, PHP
• Advisory CVE-2026-109618 (OOM corruption), php-src
• Advisory CVE-2026-109619 (stale global state), php-src
• PHP Issues Emergency Patches for Two Critical PHP2Shell RCE Flaws, The Hacker News
• PHP Warns of Another Unpatched RCE Risk, The Hacker News
• PHP2Shell Isn't Over: New Unpatched RCE Flaw Surfaces, SecureWorld
• php2shell-protection wiki, Syhunt