Pada 21 Oktober 2026, tim keamanan PHP merilis pembaruan yang menutup dua celah kritis sekaligus. Keduanya memungkinkan penyerang menjalankan kode di server tanpa perlu akun, tanpa perlu login, dan pada sebagian konfigurasi bahkan sebelum satu baris kode aplikasi kamu dieksekusi. Dua celah itu diberi nama PHP2Shell: CVE-2026-109618 dan CVE-2026-109619.

Yang membuatnya mendesak bukan hanya skornya. Menurut laporan Amazon Threat Intelligence, percobaan eksploitasi sudah terlihat pada 17 Oktober, empat hari sebelum celah ini diumumkan ke publik. Artinya ada pihak yang tahu lebih dulu dan sudah mencoba memakainya.

Apa Sebenarnya yang Bocor

CVE-2026-109618 berakar pada cara PHP menangani kondisi kehabisan memori (out-of-memory). Ketika memori habis tepat pada saat data internal sebuah request baru terisi sebagian, proses pembersihan yang menyusul bisa memperlakukan data setengah jadi itu sebagai data yang sah. Penyerang yang bisa mengatur kapan server kehabisan memori dapat memancing kondisi itu.

CVE-2026-109619 adalah use-after-free. Sisa keadaan dari satu request masih menunjuk ke memori yang sudah dibebaskan. Request berikutnya yang ditangani worker yang sama lalu memakai memori basi tersebut. Pada celah kedua ini, PHP juga menyebut kebocoran isi memori (memory disclosure) sebagai dampak yang terkonfirmasi, di samping eksekusi kode.

Keduanya dinilai CVSS v4.0 9.2 oleh tim keamanan PHP. Perlu dicatat: angka 10,0 yang sempat beredar bersama ID CVE sebelum rilis resmi adalah skor yang salah menurut PHP Foundation.

Siapa yang Terdampak

Menurut PHP, setiap pemasangan yang melayani request web berisiko. Itu mencakup PHP-FPM, Apache dengan mod_php, php-cgi, FrankenPHP, dan LiteSpeed. Risiko tertinggi ada pada mod_php, karena eksploitasi yang sudah didemonstrasikan bisa dipicu oleh request tanpa autentikasi sebelum kode aplikasi berjalan sama sekali.

Dari sisi versi, jalur kode paling awal yang ditemukan berasal dari PHP 5.4.0. Versi yang sudah mendapat perbaikan resmi:

Kalau kamu memakai PHP dari paket distribusi Linux, patch biasanya datang lewat pembaruan paket vendor. Paket itulah yang harus kamu perbarui lebih dulu, bukan mengompilasi sendiri.

Kalau Kamu Memakai Shared Hosting

Ini kelompok yang paling sering terlupa. Di shared hosting, kamu tidak mengompilasi PHP sendiri; versi PHP ditentukan oleh penyedia. Yang bisa kamu lakukan:

  1. Buka panel hosting dan cek versi PHP yang aktif untuk domainmu.
  2. Kalau ada pilihan versi, pindahkan ke rilis terbaru yang tersedia.
  3. Kalau penyedia belum menyediakan versi yang dipatch, kirim tiket dan tanyakan jadwal pembaruannya secara tertulis.
  4. Selama menunggu, kurangi permukaan risiko: matikan modul yang tidak dipakai, batasi akses admin, dan pastikan log error menyala.

Untuk situs WordPress, celah ini tidak bergantung pada versi WordPress-mu. Yang menentukan adalah versi PHP di belakangnya. Panduan langkah per langkah untuk platform populer ada di artikel WordPress, Drupal, Joomla: cek PHP2Shell.

Kenapa "Belum Ada Serangan" Bukan Alasan Menunda

Pada celah GitLab yang rilis sehari sebelumnya, vendor menyatakan belum ada tanda eksploitasi. PHP berbeda: percobaan eksploitasi sudah tercatat sebelum pengumuman resmi. Pola ini berulang di banyak insiden besar, dan pelajarannya selalu sama, yaitu jendela paling berbahaya justru saat patch baru keluar dan publik mulai mempelajari detailnya.

Pembahasan lebih panjang soal pola ini ada di artikel Eksploitasi sebelum pengumuman.

Yang Perlu Kamu Lakukan Sekarang

Urutannya sederhana dan tidak perlu menunggu rapat:

  1. Ukur dulu. Cek versi PHP di setiap server yang melayani trafik publik. Jangan andalkan ingatan; banyak server masih di 8.1 atau 8.2 karena "tidak pernah diganggu".
  2. Patch yang terekspos internet lebih dulu. Situs publik, API publik, panel admin yang terbuka. Server internal bisa menyusul.
  3. Uji setelah patch. Buka halaman utama, form login, form kontak, dan satu alur transaksi. Perhatikan log error PHP setelah pembaruan.
  4. Catat tanggal patch per server. Ini yang nanti diminta auditor atau klien, dan yang membedakan tim yang siap dari tim yang panik.

Kalau kamu mengelola lebih dari satu layanan dan waktunya terbatas, ada urutan prioritas yang lebih rinci di artikel Tim kecil: urutan patch kalau waktu cuma satu jam. Untuk langkah teknis gabungan PHP, Node.js, dan GitLab dalam satu sesi, lihat panduan patch 30 menit.

Pertanyaan yang Sering Muncul

Apakah cukup menutup akses ke file tertentu? Tidak. Celah ini berada di inti PHP, bukan di file aplikasi, sehingga tidak ada aturan .htaccess yang bisa menutupnya dengan aman.

Apakah situs yang tidak memakai database ikut terdampak? Ya. Pemicunya adalah pemrosesan request dan memori, bukan database.

Bagaimana kalau hosting tidak mau update? Minta jadwal tertulis. Kalau tidak ada kepastian, pertimbangkan memindahkan situs. Selama belum dipatch, asumsikan server bisa diambil alih.

Apakah ada bukti eksploitasi yang beredar? Ada demonstrasi publik setelah rilis, dan percobaan eksploitasi sebelum rilis menurut Amazon Threat Intelligence. Itu cukup alasan untuk tidak menunda.

Penutup

PHP2Shell bukan celah yang bisa diselesaikan dengan mengganti password atau memasang plugin keamanan. Ini pembaruan versi, dan hanya itu yang menutupnya. Kabar baiknya, perbaikannya sudah tersedia untuk semua cabang yang masih didukung. Yang dibutuhkan cuma satu hal: memastikan nomor versi di servermu benar-benar berubah hari ini, bukan "nanti setelah sibuk".

Kalau kamu ingin membaca sumber primer, mulai dari pengumuman tim keamanan PHP dan tulisan teknis Calif. Untuk konteks tambahan soal cara vendor menangani pengungkapan celah, lihat juga artikel tentang ketatnya Google soal konten massal.