PHP2Shell Dijelaskan: Dua Celah Kritis PHP dan Cara Memperbaikinya

Kalau websitemu berjalan di PHP, cek versinya hari ini juga. Dua kerentanan kritis di PHP itu sendiri, yang dijuluki PHP2Shell, sudah ditambal pada 21 Oktober 2026, dan percobaan eksploitasinya sudah teramati. Versi singkatnya: perbarui ke PHP 8.5.12, 8.4.27, 8.3.36, atau 8.2.35, sesuai branch yang kamu pakai. Versi yang lebih lama dari itu di branch yang sama berarti terekspos, dan PHP 8.1 ke bawah tidak menerima perbaikan sama sekali dari proyek PHP. Kedua celah ini memungkinkan penyerang tanpa autentikasi menjalankan kode di servermu, dan keduanya diberi skor CVSS v4.0 9,2 oleh tim keamanan PHP, menurut advisori resmi di PHP.net. Versi panjangnya, termasuk cara kerja kedua celah, siapa yang paling berisiko, cara memeriksa eksposurmu, dan apa yang harus dilakukan kalau kamu belum bisa patch hari ini, ada di bawah.

Poin Penting

• PHP2Shell adalah pasangan CVE-2026-109618 dan CVE-2026-109619, dua celah remote code execution tanpa autentikasi di PHP, keduanya berskor CVSS v4.0 9,2.

• Rilis perbaikannya terbit pada 21 Oktober 2026: PHP 8.5.12, 8.4.27, 8.3.36, dan 8.2.35. PHP 8.1 ke bawah tidak mendapat rilis perbaikan.

• Semua setup PHP yang menghadap web masuk dalam cakupan, termasuk PHP-FPM, Apache dengan mod_php, php-cgi, FrankenPHP, dan LiteSpeed. Risiko tertinggi ada pada mod_php.

• OpenAI menerbitkan alat pemeriksa gratis yang membaca versi PHP kamu dan menandai eksposurnya, tetapi hasil UNKNOWN bukan berarti kamu sudah aman.

• Tidak ada solusi konfigurasi yang tuntas. Memperbarui adalah satu-satunya perbaikan yang aman, kata tim keamanan PHP.

• Percobaan serangan sudah terlihat sejak 17 Oktober, tetapi sampai 22 Oktober belum ada laporan eksploitasi yang berhasil dikonfirmasi, dan exploit publik membutuhkan kondisi khusus. Patch dengan cepat, tetapi jangan panik.

Apa Itu PHP2Shell?

PHP adalah bahasa sisi server di balik sebagian besar web: Tenable, mengutip W3Techs, menyebut angka 69,3% dari website yang bahasa pemrograman sisi servernya diketahui. Kedua celah ini ditemukan pada Agustus 2026 oleh peneliti dari Calif, Wiz Research, dan OpenAI dalam inisiatif Patch the Planet, seperti dilaporkan JFrog dan Sansec. Pengungkapan terkoordinasi direncanakan pada 22 Oktober. Pada 20 Oktober, detailnya bocor lebih dulu: sebuah unggahan media sosial dan tangkapan layar alat exploit privat bernama PHP2Shell beredar online, dan watchTowr menjadi pihak pertama yang mengonfirmasi secara publik bahwa kebocoran itu asli. Tim keamanan PHP menerbitkan pemberitahuan awal malam itu juga dan merilis versi perbaikannya pada 21 Oktober, sehari lebih cepat dari jadwal semula. Satu detail yang perlu diketahui: unggahan yang bocor mengklaim skor CVSS 10,0. Skor resmi dari tim keamanan PHP adalah 9,2, sebagaimana dikonfirmasi Check Point.

Dua Celah Ini, dengan Bahasa Sederhana

CVE-2026-109618: RCE lewat korupsi out-of-memory

Menurut kata-kata PHP.net sendiri, "penanganan out-of-memory dapat menginterupsi PHP saat data request internal baru terinisialisasi sebagian. Pembersihan request kemudian dapat memperlakukan data yang tidak valid itu seolah valid." Advisori GitHub menjelaskan mekanismenya: PHP memakai longjmp() untuk keluar dari error out-of-memory, jadi kalau penyerang bisa memaksakan kekurangan memori pada momen yang tepat, kode shutdown akan berjalan di atas data request yang baru setengah terbentuk dan bisa diarahkan untuk mengeksekusi kode. Memaksakan kekurangan memori itu ternyata lebih murah dari yang terdengar. Advisori tersebut mencantumkan trik yang bisa dijangkau penyerang, misalnya request multipart tanpa Content-Length yang bisa dipakai sehingga lolos dari pemeriksaan post_max_size pertama.

CVE-2026-109619: RCE lewat status global yang basi

Celah kedua adalah use-after-free. Menurut PHP.net, "status internal milik request dapat bertahan setelah memori pendukungnya dibebaskan. Request berikutnya yang ditangani worker yang sama dapat menggunakan status basi itu sebelum inisialisasi normal meresetnya." Advisori GitHub mengonfirmasi dua jalur serangan. Jalur pertama menyalahgunakan fitur session upload progress, yang aktif secara default dan bekerja bahkan jika aplikasimu tidak pernah memanggil session_start(). Jalur kedua, di PHP 8.5, menyalahgunakan fatal error backtrace. Dampak yang terkonfirmasi adalah remote code execution tanpa autentikasi dengan hak akses akun worker web, ditambah pengungkapan memori: memori worker yang sudah dibebaskan dapat membocorkan data dari request lain, seperti yang diuraikan Sansec pada handler upload progress.

Untuk sebagian jalur, kedua celah ini mengharuskan request penyerang ditangani oleh proses worker yang sama, itulah sebabnya server sibuk dengan banyak worker lebih sulit ditembus per request. Itu menurunkan peluangnya. Bukan menghilangkan bug-nya.

Siapa yang Berisiko?

Jawaban resminya luas. PHP.net menyatakan: "semua instalasi PHP yang melayani request web, termasuk PHP-FPM, Apache dengan mod_php, php-cgi, FrankenPHP dan LiteSpeed. Kami menilai risiko tertinggi ada pada mod_php, dengan exploit yang sudah didemonstrasikan di mana request tanpa autentikasi dapat memicu serangan sebelum kode aplikasi apa pun berjalan."

Poin terakhir itu yang membuat mod_php istimewa di kasus ini. Menurut advisori CVE-2026-109618, remote code execution penuh sudah divalidasi lewat HTTP terhadap mod_php dengan batas default, karena mod_php menjalankan prosedur shutdown request bahkan ketika startup request gagal. Serangannya terjadi sebelum satu baris pun kode aplikasimu dieksekusi, jadi pertahanan di level aplikasi tidak pernah mendapat kesempatan. Untuk PHP-FPM, advisori yang sama menyatakan analisis kode sumber mendukung FPM sebagai rentan terhadap celah OOM ini, walaupun exploit FPM yang tuntas belum didemonstrasikan untuk celah tersebut. Untuk CVE-2026-109619, jalur session lifecycle-nya sudah divalidasi terhadap mod_php maupun FPM, menurut advisorinya.

Versi yang Terdampak dan Versi Perbaikannya

Fakta pastinya berasal dari pengumuman rilis di PHP.net, semuanya bertanggal 21 Oktober 2026:

Tiga catatan penting di sini:

• Paket distro bisa berbeda. Distribusi Linux menerima patch lebih awal dan sering mem-backport perbaikan ke nomor versi yang lebih lama. Server yang melaporkan PHP 8.3.20 bisa jadi sudah ditambal oleh distribusinya. Periksa advisori keamanan vendormu, jangan hanya mengandalkan string versi, seperti yang disarankan PHP.net.

• Branch lama mendapat pertolongan, bukan rilis. Karena tingkat keparahannya, tim keamanan PHP menerbitkan backport sumber minimal untuk PHP 7.4, 8.0, dan 8.1 bagi yang membangun dari sumber atau tidak punya vendor LTS. Vendor dukungan jangka panjang seperti Ubuntu dan TuxCare juga merilis paket backport, menurut Sansec.

• Waktu untuk 8.2 hampir habis. PHP 8.2 mencapai end of life pada 31 Desember 2026 dan tidak menerima perbaikan keamanan setelah tanggal itu, menurut catatan rilis 8.2.35 di PHP.net.

Sejauh apa kode rentannya mundur ke belakang? Advisori PHP tidak mencetak rentang versi terdampak, tetapi para peneliti mengatribusikan kode rentannya ke PHP 5.4.0, yang dirilis pada 2012, seperti dilaporkan Tenable dari tulisan Calif. Perlakukan setiap PHP yang belum ditambal dari satu dekade terakhir sebagai masuk cakupan sampai vendormu menyatakan sebaliknya.

Cara Memeriksa Versi PHP Kamu

Mulailah dari servernya langsung. Jalankan `php -v` dan bandingkan dengan versi perbaikan di atas. Satu peringatan: versi PHP command-line bisa berbeda dari versi yang benar-benar melayani situsmu di bawah FPM atau mod_php, jadi periksa runtime yang dipakai web servermu, bukan hanya CLI-nya.

Untuk pandangan cepat dari luar, OpenAI menerbitkan php2shell-checker di GitHub dengan lisensi Apache-2.0. Ini alat Node.js kecil, juga dikemas sebagai skill Codex, yang membaca versi PHP dari header respons HTTP sebuah situs (atau dari `php -v` dengan flag `--local`) lalu membandingkannya dengan batas per branch:

``` node phpcheck.js "https://example.com" node phpcheck.js --local ```

Jawabannya OK, VULNERABLE, atau UNKNOWN. Hormati batasannya, yang dinyatakan README-nya dengan jelas: alat ini hanya menilai versi yang bisa dilihatnya, situs yang menyembunyikan header versinya akan menghasilkan UNKNOWN, dan backport distro dapat membuat server yang sudah ditambal terlihat rentan karena nomor versinya tidak berubah. Dalam peringatan tebal proyek itu sendiri: UNKNOWN bukan berarti targetnya sudah ditambal.

Patch Dulu: Cara Memperbarui

1. Cadangkan dan amankan log terlebih dahulu kalau kamu melihat trafik mencurigakan. Salah satu celah ini hidup di memori worker, jadi me-restart worker akan menghancurkan bukti. watchTowr menyarankan mengamankan log PHP dan web server, snapshot konfigurasi, dan file mencurigakan sebelum membuat perubahan.

2. Pasang rilis perbaikan untuk branch-mu dari PHP.net, atau perbarui paket distribusimu kalau vendormu merilis backport. Di hosting bersama atau managed hosting, periksa advisori penyedia hostingmu dan tanyakan langsung apakah build PHP mereka sudah ditambal.

3. Restart semua worker PHP (pool FPM, Apache, image container-mu) supaya kode barulah yang benar-benar melayani request.

4. Periksa ulang dengan `php -v` pada runtime web dan alat pemeriksa OpenAI dari luar.

Kalau Kamu Belum Bisa Patch Hari Ini

Posisi tim keamanan PHP tegas: tidak ada mitigasi yang tuntas, dan memperbarui adalah satu-satunya pilihan yang aman. Langkah-langkah di bawah ini, dari advisori resmi dan kedua advisori GitHub, mengurangi eksposur pada jalur serangan tertentu. Tidak satu pun membuat server yang belum ditambal menjadi aman.

• Matikan session upload progress. Atur `session.upload_progress.enabled=0` di php.ini atau konfigurasi pool FPM dan restart semua worker. Ini memblokir jalur session yang terkonfirmasi dari CVE-2026-109619, tetapi bukan varian lainnya.

• Di PHP 8.5, nonaktifkan fatal error backtrace. Atur `fatal_error_backtraces=0` dan restart worker. Ini hanya memblokir jalur backtrace yang terkonfirmasi.

• Atur memory_limit ke -1, diberlakukan secara administratif (misalnya dengan php_admin_value) supaya aplikasi tidak bisa menimpanya. Ini mempersempit jalur OOM dari CVE-2026-109618, tetapi PHP memperingatkan langkah ini tidak tuntas dan menghilangkan perlindungan PHP sendiri terhadap kehabisan sumber daya. Jangan memakai RLIMIT_AS atau RLIMIT_DATA sebagai gantinya: keduanya justru menyebabkan kegagalan alokasi yang memicu jalur rentannya.

• Turunkan post_max_size. PHP menyarankan 8M untuk aplikasi yang tidak memerlukan unggahan file dan 32M bila unggahan diperlukan, dengan upload_max_filesize dijaga di bawahnya.

• Blokir request multipart di proxy kalau aplikasimu tidak memakai multipart form data. Toolkit komunitas php2shell-protection dari Syhunt melakukan ini untuk Apache, dan README-nya menegaskan bahwa alat itu "BUKAN mitigasi tuntas untuk kedua CVE". Memblokir multipart juga merusak semua unggahan file di rute yang dicakup.

• Sebagai jalan terakhir, isolasi. Panduan CISA dan CERT-EU, yang diteruskan oleh Tenable, adalah mempertimbangkan untuk mematikan sistem PHP yang menghadap internet atau mengisolasinya sampai ditambal.

Apakah Sudah Ada yang Jadi Korban?

Percobaan, iya. Pembobolan yang terkonfirmasi, belum, dan perbedaan itu penting. Tenable melaporkan bahwa Amazon Threat Intelligence mengamati percobaan eksploitasi PHP2Shell terhadap jaringan honeypot MadPot miliknya pada 17 Oktober, empat hari sebelum pengungkapan publik, dan menyarankan penyelidikan dimulai dari tanggal tersebut. Cloudflare melaporkan percobaan serangan awal pada 21 Oktober dan mendorong aturan WAF ke semua pelanggan, termasuk paket gratis. watchTowr mengonfirmasi eksploitasi teramati di jaringan honeypot globalnya per 21 Oktober, sambil juga menyatakan belum ada percobaan yang berhasil pada saat itu. PHP Foundation memeriksa kode proof-of-concept yang muncul setelah kebocoran dan tidak menemukan exploit yang berfungsi pada saat rilis, dan CISA menyatakan belum mengamati eksploitasi per advisorinya.

Pada 22 Oktober, Sansec menurunkan penilaiannya: eksploitasi massal lebih kecil kemungkinannya daripada perkiraan di hari rilis, serangan membutuhkan pengetahuan spesifik tentang server target dan kondisi khusus di dalamnya, exploit publik tidak bekerja terhadap instalasi PHP default, dan sebagian besar kode proof-of-concept publik membutuhkan aplikasi target yang sudah memiliki bug local file inclusion. Dengan kata sederhana: jendela untuk patch itu nyata, tetapi tidak akan terbuka selamanya. Manfaatkan.

Cara Berburu Tanda-Tanda Serangan

Baik kamu patch hari ini atau minggu depan, luangkan dua puluh menit memeriksa indikator di bawah ini, yang dihimpun dari panduan logging advisori GitHub, Check Point, dan watchTowr. Perlakukan temuan tunggal sebagai triase, bukan bukti. Yang menentukan adalah korelasinya.

• Request POST multipart yang membawa field PHP_SESSION_UPLOAD_PROGRESS, atau request multipart besar dan cacat format ke endpoint yang tidak pernah menerima unggahan

• Error fatal "Allowed memory size exhausted" dan timeout request yang berulang di log PHP, yang ditinggalkan oleh celah OOM

• Segfault pada worker PHP-FPM atau Apache, atau ledakan crash dan respawn worker

• File .php baru atau yang berubah di bawah web root, terutama di folder upload, cache, atau temp, serta file tak terduga di path penyimpanan session

• Perubahan pada auto_prepend_file atau auto_append_file di php.ini mana pun

• Proses web server yang memunculkan sh, bash, curl, wget, atau nc, ditambah cron job, unit systemd, akun pengguna, atau entri authorized_keys baru

Check Point menyarankan pemeriksaan ini diulang tepat setelah patch dan lagi pada 24 dan 72 jam setelahnya. Untuk deteksi di level jaringan, Corelight menerbitkan aturan Zeek dan Suricata open source di repositori php2shell-detect miliknya, yang dibangun bersama OpenAI dan tim PHP sebelum pengungkapan, seperti yang dicatat ASEC.

Waspadai Repositori Exploit Palsu

Dalam sehari setelah pengungkapan, GitHub dibanjiri repositori bernama php2shell. ASEC menghitung 100 hasil pencarian teratas pada 22 Oktober: 99 di antaranya membahas kerentanan ini, hampir semuanya dibuat pada 21 Oktober saja, dan terbagi menjadi 46 proyek defensif dan 36 proyek ofensif. Tidak semuanya jujur. JFrog menyelidiki repo proof-of-concept palsu dan menemukan lelucon, bukan malware yang terkonfirmasi: satu repo palsu menyembunyikan string Base64 yang tampak seperti penanam malware, tetapi ternyata mengubah wallpaper korban menjadi konten NSFW. ASEC secara terpisah menemukan klon dari repositori proof-of-concept populer dengan kode yang dimodifikasi, dan memperingatkan bahwa bahkan alat defensif satu baris pun bisa menuntut hak akses root, dengan setidaknya satu alat yang mengaku ditulis oleh AI tanpa jaminan apa pun.

Kebiasaan amannya sederhana. Jangan pernah menjalankan kode exploit atau pemeriksa yang belum kamu baca sendiri. Jalankan kode pengujian apa pun hanya di lingkungan terisolasi. Untuk memeriksa eksposur, nomor versi adalah pemeriksaannya, dan alat pemeriksa resmi OpenAI serta unduhan di PHP.net adalah sumber yang bisa dipercaya.

Pertanyaan yang Sering Diajukan

Apakah situs WordPress saya terdampak? Celahnya ada di PHP itu sendiri, bukan di WordPress atau aplikasi tertentu mana pun. Eksposurmu bergantung pada versi PHP yang dijalankan hostingmu dan cara pengaturannya. Perbarui PHP terlebih dahulu (atau pastikan hostingmu sudah melakukannya), lalu perbarui aplikasinya seperti biasa.

Alat pemeriksa mengatakan UNKNOWN. Apakah saya aman? Tidak. UNKNOWN berarti tidak ada versi yang bisa dideteksi, biasanya karena server menyembunyikan header-nya. Proyek pemeriksa itu sendiri memperingatkan dengan tegas bahwa UNKNOWN bukan berarti sudah ditambal. Periksa versinya di server langsung.

Saya menjalankan PHP 7.4, 8.0, atau 8.1. Apa pilihan saya? Tidak ada rilis perbaikan resmi untuk branch-branch ini. Pilihanmu adalah paket vendor dukungan jangka panjang dengan perbaikan backport, backport sumber minimal resmi dari PHP untuk 7.4, 8.0, dan 8.1, atau migrasi ke branch yang didukung. Perlakukan migrasi sebagai jawaban sebenarnya dan backport sebagai jembatan.

Apakah mematikan session upload progress sudah cukup? Tidak. Itu memblokir jalur session yang terkonfirmasi dari satu di antara dua celah. Advisori PHP menyatakan tidak ada mitigasi konfigurasi generik yang tuntas. Hanya pembaruan yang menutup kedua celah.

Apakah ada situs sungguhan yang diretas? Per 22 Oktober 2026, percobaan eksploitasi sudah teramati sejak 17 Oktober, tetapi watchTowr, CISA, dan PHP Foundation semuanya melaporkan belum ada eksploitasi berhasil yang terkonfirmasi. Status itu bisa berubah, dan justru karena itulah patch sekarang penting.

Kesimpulan

PHP2Shell seserius yang bisa terjadi pada kerentanan PHP: remote code execution tanpa autentikasi di lapisan bahasanya sendiri, berskor 9,2, dengan percobaan serangan yang sudah beredar. Penanganannya juga luar biasa baik: perbaikan terkoordinasi untuk setiap branch yang didukung, alat pemeriksa resmi, deteksi open source, dan komunikasi vendor yang jujur tentang apa yang sudah dan belum terkonfirmasi. Langkahmu sederhana. Periksa versimu, perbarui ke 8.5.12, 8.4.27, 8.3.36, atau 8.2.35, restart worker-mu, dan luangkan dua puluh menit memburu jejak di log-mu.

Mau lebih banyak alat keamanan open source dan proyek yang layak diperhatikan? Telusuri repo signal terbaru di RepoManiac, tempat proyek GitHub baru diperiksa dan diringkas dalam video 30 detik. Membaca ini dalam bahasa Inggris? Ini versi bahasa Inggris artikel ini.