PHP2Shell: Celah Keamanan PHP CVSS 9.2 — Update ke 8.4.27, 8.3.36, atau 8.2.35 Sekarang

PHP2Shell adalah nama untuk dua celah keamanan kritis di inti PHP — CVE-2026-109618 dan CVE-2026-109619, masing-masing CVSS 9.2 — yang memungkinkan penyerang menjalankan kode di server tanpa login. Patch darurat dirilis 21 Oktober 2026 di PHP 8.5.12, 8.4.27, 8.3.36, dan 8.2.35. Satu-satunya perbaikan lengkap adalah update PHP dan restart worker, bukan update aplikasi kamu.

Apa itu PHP2Shell?

PHP2Shell bukan nama virus, plugin, atau celah di WordPress dan Laravel. Ini adalah julukan yang diberikan peneliti keamanan untuk dua bug keamanan memori di interpreter PHP itu sendiri — kode yang berjalan paling awal saat server menerima request, bahkan sebelum baris pertama aplikasi kamu dieksekusi.

Karena letaknya di mesin PHP, konsekuensinya berbeda dari celah aplikasi biasa. Website kamu bisa saja sudah memakai Laravel atau WordPress versi terbaru, password admin yang kuat, dan autentikasi dua faktor — server tetap bisa diambil alih jika versi PHP-nya rentan. Itulah kenapa kabar ini ramai dibahas di mana-mana sejak 21 Oktober 2026, dan kenapa layanan besar di Jepang dan Belanda sampai mengambil langkah maintenance darurat atau offline sementara.

Kedua celah dilaporkan ke tim PHP oleh peneliti dari Wiz dan Calif, dengan bantuan model AI dalam proses penemuan dan pembuatan bukti eksploitasinya. Detail teknisnya bocor pada 20 Oktober 2026 — sehari sebelum jadwal pengumuman resmi — sehingga tim PHP memajukan rilis patch ke 21 Oktober 2026 pukul 14:00 UTC.

Bagaimana kronologi kejadian PHP2Shell?

Urutan kejadiannya menjelaskan kenapa tingkat urgensinya tinggi:

Pola "exploit bocor duluan, patch menyusul" adalah skenario terburuk dalam keamanan: penyerang mendapat jendela waktu untuk menyerang server yang belum ditambal, dan jendela itu belum tertutup selama server kamu belum update.

Apa perbedaan CVE-2026-109618 dan CVE-2026-109619?

Dua-duanya berakhir sama — remote code execution (RCE) tanpa autentikasi — tetapi jalur masuknya berbeda:

Poin kedua dari CVE-2026-109618 yang sering terlewat: selain RCE, celah ini juga bisa dipakai membaca memori proses PHP — dan memori worker biasanya berisi hal-hal sensitif seperti password database dari .env, token sesi, dan API key. Jadi dampaknya bukan cuma "server bisa disusupi", tetapi juga "rahasia aplikasi bisa bocor tanpa penyerang perlu berhasil menjalankan kode".

Versi PHP mana saja yang terdampak dan mana yang aman?

Menurut Wiz, kode rentannya sudah ada sejak PHP 5.4 (rilis 2012), jadi hampir semua instalasi PHP yang melayani request web terdampak oleh setidaknya salah satu celah. Semua mode menjalankan PHP ikut terdampak: PHP-FPM, Apache dengan mod_php (risiko tertinggi menurut PHP), php-cgi, FrankenPHP, dan LiteSpeed.

Untuk PHP 8.1 ke bawah yang sudah end of life, tim PHP hanya menyediakan backport kode sumber minimal untuk 7.4, 8.0, dan 8.1 bagi yang mengompilasi PHP sendiri. PHP 7.3 ke bawah tidak mendapat perbaikan sama sekali. Ini alasan tambahan untuk tidak menunda migrasi dari cabang lama — topik yang juga kami bahas di artikel PHP 8.2 End of Life 31 Desember 2026.

Catatan penting untuk pengguna distro Linux dan cPanel: vendor sering melakukan backport patch ke nomor versi lama tanpa menaikkan nomor versinya. Contohnya paket Ubuntu bisa tetap tertulis 8.3.6 tetapi sudah berisi perbaikan. Jadi selain nomor versi, cek juga changelog paket atau pengumuman resmi host kamu.

Bagaimana cara mengecek versi PHP website saya?

Lakukan pengecekan pada PHP yang melayani website, bukan sekadar PHP di terminal — keduanya bisa berbeda versi.

1. Lewat terminal / SSH (VPS)

Perintah ini menampilkan versi CLI. Untuk memastikan versi PHP-FPM yang melayani web, cek juga pool FPM yang aktif atau buat pengecekan lewat web di langkah berikutnya.

2. Lewat file phpinfo sementara (shared hosting & VPS)

Simpan sebagai file bernama acak, misalnya cek-php-9f3.php, buka sekali lewat browser, catat versi di baris paling atas, lalu hapus file itu segera setelah selesai. File phpinfo() yang dibiarkan online adalah kebocoran informasi tersendiri — jangan pernah meninggalkannya.

3. Lewat cPanel (shared hosting)

Masuk ke cPanel, buka menu Select PHP Version atau MultiPHP Manager. Di sana terlihat versi PHP aktif per domain. Jika versi aman (misalnya 8.4.27) sudah tersedia sebagai pilihan, kamu bisa berpindah langsung dari menu ini — tetapi uji website kamu setelahnya, karena perpindahan cabang (misalnya dari 8.2 ke 8.4) bisa memunculkan error kompatibilitas di plugin atau source code lama.

4. Lewat WordPress

Buka Tools → Site Health → Info → Server — versi PHP yang melayani situs tertulis di sana.

Bagaimana cara update dan menutup celah PHP2Shell?

Jika kamu memakai VPS atau server sendiri:

1. Update paket PHP dari repo distro atau repo yang kamu pakai sampai mencapai versi aman di tabel di atas.
2. Restart layanan PHP agar worker menjalankan binary baru — update tanpa restart tidak menutup apa-apa:

Sesuaikan nama layanan dengan versi dan setup kamu (php8.3-fpm, httpd, dan seterusnya). Pengguna Docker perlu me-rebuild image dengan base image PHP versi aman, bukan sekadar restart container.

1. Verifikasi ulang dengan php -v dan langkah phpinfo di atas.

Jika kamu memakai shared hosting:

Kamu tidak bisa update PHP sendiri — itu wewenang penyedia hosting. Yang bisa dan harus kamu lakukan hari ini:

1. Cek versi PHP aktif domain kamu lewat cPanel (langkah di atas).
2. Jika ada pilihan versi yang sudah ditambal, pindah ke versi itu dan uji website.
3. Jika belum ada, buka tiket ke support hosting dan tanyakan secara spesifik: "Apakah versi PHP di server saya sudah ditambal untuk CVE-2026-109618 dan CVE-2026-109619 (PHP2Shell)?" Simpan jawabannya.
4. Sambil menunggu, pastikan kamu punya backup terbaru di luar server — ikuti pola di panduan backup otomatis website Laravel.

Jika kamu menjual atau membeli source code:

Celah ini bukan di source code, jadi tidak ada file aplikasi yang perlu diganti penjual. Tetapi penjual yang baik tetap berkepentingan: beri tahu pembeli bahwa mereka perlu mengecek versi PHP hosting-nya, dan cantumkan syarat versi PHP aman di halaman produk. Bagi pembeli, langkah ini melengkapi checklist mengamankan website setelah beli source code — keamanan bukan cuma soal kode, tetapi juga runtime di bawahnya. Beda kasusnya dengan celah di level framework seperti TokenGuard Laravel CVSS 9.2 yang memang ditambal lewat composer update.

Kalau belum bisa update hari ini, apa yang bisa dilakukan?

Jawaban resmi tim PHP tegas: tidak ada mitigasi lengkap selain update. Dua hal yang perlu diluruskan karena banyak beredar sebagai "solusi":

1. Menonaktifkan session.upload_progress memang menutup satu jalur exploit publik, tetapi tidak cukup — masih ada jalur kedua lewat parser multipart.
2. WAF seperti Cloudflare dan Imunify360 memang sudah memblokir pola request exploit yang dikenal, dan itu menurunkan risiko. Tetapi WAF adalah rem darurat, bukan perbaikan — varian exploit yang menyamar sebagai upload normal masih bisa lolos, dan jalur OOM pada CVE-2026-109618 belum tercover rule WAF mana pun per 22 Oktober 2026.

Jika update benar-benar belum mungkin dan website kamu melayani data penting, anjuran NCSC Inggris dan NSA adalah mempertimbangkan menurunkan website sementara (offline/maintenance) sampai patch terpasang. Terdengar ekstrem, tetapi itulah yang dilakukan DigiD, MijnOverheid, pixiv, DMM, dan BASE — mereka memilih downtime beberapa jam dibanding risiko takeover.

Setelah update selesai, luangkan waktu memeriksa tanda kompromi, terutama jika server kamu online dan rentan selama 17–21 Oktober: file baru yang tidak dikenal di folder web, user admin baru, proses asing, dan koneksi keluar yang aneh di log.

Seberapa menakutkan PHP2Shell sebenarnya? (batas jujur)

Agar tidak ikut-ikutan panik, ini batas fakta per 23 Oktober 2026:

1. Skor CVSS 9.2 memang kritis, tetapi vektor resminya mencatat kompleksitas serangan tinggi (AC:H) — exploit publik yang beredar butuh kondisi dan pengetahuan spesifik tentang target, dan firma Sansec menilai exploit publik saat ini belum bekerja sebagai serangan "drive-by" universal ke instalasi PHP default.
2. Hingga 22 Oktober 2026, belum ada laporan publik tentang perusahaan nyata yang terkonfirmasi berhasil dibobol lewat PHP2Shell — yang terkonfirmasi adalah percobaan eksploitasi massal, termasuk ke lebih dari 3.600 server di jaringan Imunify360.
3. Kedua hal di atas bukan alasan menunda patch. Riwayat celah seperti ini selalu sama: exploit makin matang dari hari ke hari, sementara patch-nya sudah tersedia sekarang. Yang membuat PHP2Shell berbahaya bukan tingkat kesulitan hari ini, melainkan luasnya paparan — PHP menjalankan sebagian besar website di internet.

FAQ

1. Apakah update WordPress, Laravel, atau plugin bisa menutup PHP2Shell?

Tidak. Celahnya ada di interpreter PHP, di lapisan yang berjalan sebelum aplikasi kamu. Update aplikasi tetap penting untuk celah lain, tetapi untuk PHP2Shell satu-satunya perbaikan adalah update versi PHP di server dan me-restart worker-nya.

2. Saya memakai PHP 8.1 — apakah saya aman karena versinya tidak disebut di rilis patch?

Justru sebaliknya. PHP 8.1 ke bawah ikut terdampak tetapi sudah end of life, sehingga tidak mendapat rilis resmi. Pilihan amanmu: naik ke PHP 8.3 atau 8.4, atau pastikan penyedia hosting/distro kamu menyediakan paket yang sudah di-backport patch-nya — tanyakan secara eksplisit ke support mereka.

3. Bagaimana cara tahu hosting saya sudah patch atau belum?

Cek versi PHP aktif lewat cPanel atau phpinfo (lalu hapus filenya). Jika nomornya mencapai 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 atau lebih baru, kamu aman dari sisi nomor versi. Jika nomornya lebih lama, jangan langsung panik: tanyakan ke support apakah paket mereka sudah mengandung backport perbaikan CVE-2026-109618 dan CVE-2026-109619 — beberapa vendor menambal tanpa menaikkan nomor versi.

4. Apakah mematikan session.upload_progress sudah cukup melindungi website saya?

Tidak cukup. Itu hanya menutup jalur exploit yang memakai progres upload sesi — salah satu jalur yang dipakai tool exploit publik. Jalur parser multipart dan jalur OOM tetap terbuka. Tim PHP sendiri menyatakan update adalah satu-satunya pilihan aman.

5. Apakah website saya perlu dimatikan sementara?

Hanya jika kamu belum bisa update dan website-nya melayani data sensitif atau transaksi penting. Untuk blog atau company profile biasa di shared hosting yang host-nya responsif, jalur realistisnya: cek versi, tanya support hari ini juga, aktifkan WAF bila tersedia, dan pastikan backup terbaru aman. Untuk sistem pemerintah dan layanan publik berskala besar, standar NCSC adalah offline sementara — itu konteks anjuran yang ramai diberitakan dari Jepang dan Belanda.

6. Setelah update PHP, apakah saya perlu mengganti password dan API key?

Jika tidak ada tanda kompromi, tidak wajib. Tetapi karena CVE-2026-109618 bisa membocorkan isi memori worker (yang dapat berisi kredensial .env), bila server kamu rentan dan online selama periode bocornya exploit (20–21 Oktober) dan kamu menemukan aktivitas mencurigakan di log, perlakukan kredensial database, API key payment gateway, dan token sesi sebagai terpapar: rotasi semuanya dan paksa semua user login ulang.

7. Di mana saya bisa memantau kabar resmi PHP2Shell?

Sumber primernya adalah advisory GitHub tim PHP untuk GHSA-w8hw-w9fx-j79w (CVE-2026-109618) dan GHSA-6wmf-4rv5-p3rp (CVE-2026-109619), pengumuman rilis di php.net, serta alert CISA dan NCSC Inggris. Hindari menyimpulkan status server kamu dari postingan media sosial saja — selalu cocokkan dengan versi PHP yang benar-benar berjalan di server kamu.