Ringkasnya
PHP2Shell adalah dua celah kritis di PHP: CVE-2026-109618 dan CVE-2026-109619. Menurut tim PHP, semua instalasi PHP yang melayani request web berisiko, termasuk PHP-FPM, Apache mod_php, php-cgi, FrankenPHP dan LiteSpeed (php.net). Artinya masalahnya ada di server website, bukan di HP atau laptop pengunjung. Yang menutupnya adalah update PHP di server ke 8.5.12, 8.4.27, 8.3.36 atau 8.2.35 (php.net).
Pada 21 Oktober, sebuah postingan Threads yang viral menyebut ini "celah di mesin utama 70% website di dunia", bilang "belum ada penangkalnya", dan menyarankan ganti password. Berikut faktanya.
Setengah benar: "celah di mesin utama 70% website di dunia"
Faktanya: benar saat diumumkan, tapi itu bukan angka hari ini.
Sekitar 70% adalah porsi website yang memakai PHP. Per 24 Oktober 2026, W3Techs mencatat PHP dipakai oleh 69,3% website yang bahasa pemrograman sisi server-nya diketahui (W3Techs). Kompas Tekno mengutip data W3Techs yang sama: sekitar 70 persen situs web yang teknologi pemrograman sisi server-nya dapat diidentifikasi (Kompas Tekno). Peneliti Wiz juga menulis bahwa PHP menjalankan 70% website di dunia (Wiz). Saat celah ini diumumkan, semua instalasi PHP yang melayani request web berisiko sampai di-update (php.net). Jadi pada hari itu, angka sekitar 70% sejalan dengan sumber-sumber ini.
Yang keliru adalah menganggapnya masih 70% sekarang. Website yang PHP-nya sudah di-update tidak lagi rentan terhadap dua celah ini, dan belum ada angka publik tentang berapa website yang masih rentan. Cara tahu status website Anda adalah mengecek versinya: cara cek di sini.
Di Indonesia, BSSN mengarahkan peringatannya ke pemilik dan pengelola website (Kompas Tekno). Kemenperin menonaktifkan sementara situs dan sejumlah layanan digitalnya mulai 22 Oktober pukul 22.00 WIB, yang disebutnya sebagai langkah mitigasi risiko (Kompas Tekno).
Mitos 1: "Belum ada penangkalnya"
Faktanya: klaim ini sudah kedaluwarsa. Postingan itu terbit pukul 15.47 WIB, 21 Oktober. Tim PHP sudah mengumumkan sehari sebelumnya bahwa rilis keamanan dijadwalkan 21 Oktober pukul 14.00 UTC atau 21.00 WIB (php.net), dan perbaikannya keluar hari itu: 8.5.12, 8.4.27, 8.3.36 dan 8.2.35. Distro Linux dan vendor LTS menerima patch lebih dulu. Untuk PHP 7.4, 8.0 dan 8.1, tim keamanan PHP menyediakan backport source minimal (php.net).
Apakah sudah dieksploitasi?
Ya, ada upaya serangan nyata. Amazon menemukan upaya eksploitasi pertama di honeypot MadPot pada 17 Oktober, empat hari sebelum pengumuman. Pada 21 Oktober, masih sebelum rilis patch, muncul upaya lain dari infrastruktur anonim yang berbeda-beda, yang menurut Amazon tampaknya berasal dari beberapa pelaku. Untuk upaya-upaya sebelum pengumuman ini, Amazon menulis bahwa belum jelas apakah ada yang akan berhasil di sistem sungguhan (AWS).
Setelah patch dirilis, exploit baru muncul dalam hitungan jam, dan menurut Amazon PHP2Shell kini menghadapi "broad exploitation attempts in the wild" (AWS). watchTowr mengamati eksploitasi di jaringan honeypot-nya sejak 21 Oktober (watchTowr).
Karena itu Amazon menyarankan pemeriksaan dimulai paling tidak dari 17 Oktober, bukan dari tanggal pengumuman (AWS).
Setengah benar: "ganti password kamu atau aktifkan 2FA"
Kalimat lengkapnya di postingan: "Klo kamu masih pake password sama di beberapa website mending langsung ganti password kamu atau aktifkan 2FA."
Faktanya: sarannya baik, tapi bukan perbaikan celahnya. Peneliti Wiz menunjukkan bahwa penyerang bisa membaca memori proses PHP, yang bisa berisi password, token autentikasi, API key dan sertifikat (Wiz). Jadi mengganti password yang dipakai ulang dan menyalakan 2FA itu masuk akal. Tetapi celahnya ada di PHP di server, dan menurut tim PHP hanya update yang menjadi solusi lengkap (php.net).
Siapa yang perlu berbuat apa:
Pengunjung website: ganti password yang Anda pakai di banyak tempat, nyalakan 2FA, dan segera ganti password di website mana pun yang mengumumkan kebocoran. Langkah ini melindungi akun Anda, tetapi tidak menutup celah di server website itu.
Pengelola website: update PHP dulu, lalu restart semua worker PHP supaya perbaikannya berlaku (watchTowr). Setelah itu cek apakah server sempat dibobol. Huntress belum punya indikator kompromi (IOC) yang terkonfirmasi, tetapi menyarankan: jika Anda menemukan sesuatu, isolasi server, simpan log web server dan log PHP, lalu cari webshell, file baru di web root, serta cron job, scheduled task dan akun baru (Huntress). Menurut Kompas Tekno, pemeriksaan ini juga dapat mencakup kemungkinan kebocoran kredensial. Perusahaan teknologi PXL, yang dikutip Kompas Tekno, menyarankan agar pengelola yang menemukan tanda mencurigakan mengganti kata sandi serta kunci akses dan memulihkan website dari cadangan yang bersih. Tidak menemukan tanda pun bukan jaminan, karena PHP2Shell bisa dipakai membaca data di memori tanpa meninggalkan file atau akun baru. Karena itu, menurut rangkuman Kompas Tekno dari PXL dan Malwarebytes, pengelola yang masih memakai PHP rentan setelah 20 Oktober disarankan mengganti password database, kunci keamanan dan API key (Kompas Tekno).
Mitos 2: sudah pakai Cloudflare, jadi aman sampai sempat update
Ini muncul di balasan di thread lanjutan. Satu balasan bilang Cloudflare sudah memblok request ke path celahnya, "Jadi masih bisa tidur tenang malam ini". Seorang pengguna lalu menulis, "Saya pake cloudflare untuk set dns nya", dan balasan berikutnya menjawab: "Berarti udh bang, aman untuk malam ini."
Faktanya: aturan WAF Cloudflare membantu, tapi bukan perbaikan.
Cloudflare sendiri menulis bahwa pelanggan tetap harus patch PHP meski sudah ada perlindungan WAF (Cloudflare).
Memakai Cloudflare untuk DNS belum tentu berarti traffic lewat Cloudflare. Record yang proxied (awan oranye) mengirim request HTTP/HTTPS ke jaringan Cloudflare. Record DNS only (awan abu-abu) dijawab dengan IP asli server Anda, jadi request langsung ke server (Cloudflare Docs) dan WAF tidak melihatnya.
Untuk celah terkait CVE-2026-115560 (lihat langkah 4 di bawah), Cloudflare mencatat per 23 Oktober bahwa aturan WAF-nya tidak mencakup website yang mengubah
session.upload_progress.name(Cloudflare).Google Cloud menyebut aturan WAF-nya hanya kontrol pengganti, dan upgrade PHP tetap wajib untuk menutup celah sepenuhnya (Google Cloud).
Balasan kedua ditutup dengan "Ingat update besok". Bagian itu benar.
Yang perlu Anda lakukan
Cek versi PHP dan cara PHP dijalankan di server Anda. Langkah untuk cPanel/shared hosting dan VPS ada di Apakah website saya terdampak PHP2Shell?
Update ke versi yang sudah di-patch, atau minta penyedia hosting melakukannya. Lalu restart semua worker PHP (watchTowr).
Cek tanda kompromi, mulai dari log sejak 17 Oktober (AWS).
Ada satu celah terkait lagi, CVE-2026-115560 (session upload progress). Tim PHP menyebutnya jalur RCE yang kecil kemungkinannya: celah ini hanya muncul jika aplikasi menyetel
session.serialize_handlerkephp_binaryatauphp_serialize, lalu menggantinya kephpsaat berjalan denganini_set()sebelumsession_start(). Perbaikan dan advisory lengkapnya ikut rilis reguler berikutnya. Sampai saat itu, mereka menyarankansession.upload_progress.enabled=0, dan jika Anda sudah memasangnya pada 21 Oktober, biarkan tetap terpasang (php.net). Advisory 21 Oktober menjelaskan cara memasangnya: lewatphp.ini, pool FPM atau konfigurasi server, bukanini_set()atau.user.ini, lalu restart semua worker (php.net).
Ingin kami yang cek dan patch?
Kami sudah mengecek dan mem-patch host PHP yang kami kelola untuk klien (website WordPress, WooCommerce dan Moodle). Untuk server Anda, kami mengecek versi PHP, SAPI dan paket, lalu melakukan patch, upgrade atau backport (PHP 7.4–8.1), me-restart worker, dan mengecek tanda kompromi. Di shared hosting, kami pindahkan versi PHP jika panel hosting mengizinkan. Jika tidak, PHP-nya milik penyedia hosting, dan kami kirimkan permintaan yang persis ke penyedia hosting Anda. Laporan tertulis berisi temuan Anda terima di hari yang sama Anda mengirim permintaan. Untuk server yang kami patch sendiri, status akhirnya kami tulis apa adanya: dicek dan di-patch.