Dua kerentanan kritis pada PHP yang disebut PHP2Shell dapat memungkinkan penyerang menjalankan kode dari jarak jauh tanpa akun atau proses login. Celah ini berada pada inti PHP sehingga website berbasis WordPress, Drupal, Joomla, dan sistem lain yang menggunakan bahasa pemrograman tersebut berisiko terdampak.
Tim keamanan PHP mengungkap kerentanan itu pada Rabu, 21 Oktober 2026, sekaligus merilis pembaruan darurat bagi sejumlah versi yang masih mendapat dukungan. Kedua celah memiliki skor 9,2 dari 10 berdasarkan CVSS versi 4.0.
PHP2Shell bukan kerentanan pada plugin, tema, atau CMS tertentu. Karena itu, pembaruan CMS maupun plugin saja belum tentu melindungi website jika PHP pada server belum diperbarui.
Mengenal dua celah PHP2Shell
PHP2Shell merujuk pada dua kerentanan yang dapat memicu Remote Code Execution (RCE), yakni kondisi ketika penyerang menjalankan kode atau perintah pada sistem sasaran melalui jaringan. Keduanya terkait kesalahan pengelolaan memori saat PHP memproses permintaan HTTP tertentu.
Dalam keadaan normal, PHP menggunakan memori untuk memproses permintaan pengunjung, lalu membersihkannya setelah pekerjaan selesai. Namun, gangguan saat pemrosesan—termasuk kondisi kehabisan memori—dapat membuat PHP salah menangani data dan referensi memori.
| Identifikasi | Jenis masalah | Penjelasan |
|---|---|---|
| CVE-2026-109618 | Out-of-memory corruption | Terjadi ketika PHP kehabisan memori saat data internal masih diinisialisasi. Dalam proses penghentian dan pembersihan, data yang belum siap sepenuhnya dapat diperlakukan sebagai data valid. |
| CVE-2026-109619 | Stale global state | PHP masih menyimpan referensi ke memori yang telah dibebaskan setelah permintaan sebelumnya selesai. Jika referensi itu digunakan kembali, penyerang dapat memengaruhi jalannya program. |
Kesalahan tersebut berpotensi membuka akses ke bagian memori yang tidak valid, mengganggu layanan, membaca informasi sensitif, atau menjalankan kode berbahaya. Permintaan HTTP yang dirancang khusus dapat memicu kedua celah, bahkan dalam skenario tertentu sebelum kode aplikasi website dijalankan.
Konfigurasi server yang dapat terdampak
Risiko mencakup instalasi PHP yang menerima permintaan web melalui berbagai konfigurasi, termasuk Apache dengan mod_php, PHP-FPM, php-cgi, FrankenPHP, dan LiteSpeed. Di antara konfigurasi itu, Apache dengan mod_php disebut memiliki risiko paling tinggi.
Peneliti keamanan telah menunjukkan skenario ketika permintaan dari pengguna yang belum terautentikasi dapat memicu eksploitasi sebelum aplikasi menjalankan kode utamanya. Meski demikian, bukan berarti semua website berbasis PHP otomatis dapat diretas; keberhasilan serangan bergantung pada konfigurasi server, proses penanganan permintaan, dan faktor teknis lainnya.
Penggunaan plugin keamanan atau pembaruan CMS tidak menggantikan perbaikan PHP. Kerentanan berada pada bahasa pemrograman yang menjadi komponen berbagai platform, termasuk WordPress, Drupal, dan Joomla.
Versi PHP yang perlu diperbarui
Tim pengembang PHP menerbitkan perbaikan pada 21 Oktober 2026 untuk cabang PHP 8.2, 8.3, 8.4, dan 8.5. Administrator dapat memeriksa versi yang digunakan dan mencocokkannya dengan daftar berikut.
| Cabang PHP | Versi sebelum patch | Versi perbaikan atau tindakan |
|---|---|---|
| PHP 8.5 | Hingga 8.5.11 | 8.5.12 |
| PHP 8.4 | Hingga 8.4.26 | 8.4.27 |
| PHP 8.3 | Hingga 8.3.35 | 8.3.36 |
| PHP 8.2 | Hingga 8.2.34 | 8.2.35 |
| PHP 8.1 dan lebih lama | Tidak mendapat rilis reguler terbaru dari PHP | Disarankan bermigrasi atau menggunakan patch vendor |
Pengguna PHP 8.5, 8.4, 8.3, dan 8.2 perlu memperbarui instalasi masing-masing ke versi perbaikan yang tercantum. Untuk cabang lama yang tidak lagi menerima dukungan keamanan reguler, migrasi ke versi yang masih didukung menjadi pilihan yang disarankan.
Pengguna Ubuntu atau Debian juga perlu memeriksa pembaruan dari vendor sistem operasi. Vendor dapat menerapkan perbaikan melalui mekanisme backport, sehingga patch keamanan tersedia tanpa mengubah nomor versi utama PHP menjadi versi terbaru yang dirilis langsung oleh pengembang.
Perlindungan tambahan dari Cloudflare
Cloudflare menyatakan pada 21 Oktober 2026 bahwa perusahaan telah menyiapkan mitigasi sejak awal Oktober melalui koordinasi dengan sejumlah pihak yang menangani kerentanan tersebut. Perlindungan itu menggunakan Web Application Firewall (WAF) untuk mengenali dan memblokir pola permintaan HTTP yang berpotensi dimanfaatkan dalam serangan.
Perlindungan tersedia bagi pengguna gratis melalui Cloudflare Managed Free Ruleset. Menurut Cloudflare, pengguna paket gratis tidak perlu melakukan tindakan tambahan untuk mengaktifkannya.
WAF merupakan lapisan perlindungan tambahan, bukan pengganti pembaruan PHP. Perbaikan utama tetap perlu dipasang pada server agar kerentanan ditutup.
Langkah mengamankan website
Administrator server dan pemilik website perlu memeriksa PHP yang digunakan, terutama pada hosting atau VPS yang menampung beberapa website. Pada server Linux, versi PHP di lingkungan Command Line Interface (CLI) dapat diperiksa dengan perintah php -v.
Hasil pemeriksaan CLI belum tentu sama dengan PHP yang menjalankan website. Karena itu, administrator juga perlu memeriksa PHP-FPM atau layanan PHP lain yang terhubung ke web server.
Jika instalasi belum mendapat perbaikan, pembaruan sebaiknya dilakukan melalui repositori resmi sistem operasi atau penyedia hosting. Pengelola juga dapat mengaktifkan WAF, membatasi ukuran unggahan yang tidak diperlukan, serta memantau log server untuk mencari aktivitas mencurigakan.
Pemeriksaan log perlu dilakukan apabila server yang rentan sebelumnya dapat diakses melalui internet. Setelah paket PHP diperbarui, proses terkait juga harus dimuat ulang atau di-restart; jika tidak, proses lama dapat terus berjalan dengan kode yang belum diperbaiki.
Laporan aktivitas eksploitasi
Tingkat keparahan PHP2Shell disertai laporan adanya indikasi eksploitasi di internet. Dalam laporan pada 21 Oktober 2026, perusahaan keamanan Tenable mengutip pernyataan Cloudflare mengenai indikasi awal serangan yang memanfaatkan kerentanan tersebut.
Informasi itu menjadi perhatian khusus bagi server publik yang menerima permintaan tanpa autentikasi. Namun, aktivitas eksploitasi yang terdeteksi tidak otomatis berarti setiap percobaan berhasil mengambil alih server; dampaknya dapat berupa gangguan proses PHP hingga kemungkinan eksekusi kode, bergantung pada kondisi yang terpenuhi.
Jika penyerang berhasil menjalankan kode, tingkat kerusakan juga bergantung pada hak akses proses PHP di server. Pembatasan hak akses, pemisahan lingkungan aplikasi, dan pembaruan perangkat lunak tetap menjadi bagian dari pengamanan infrastruktur website.
Bagi pengelola WordPress dan aplikasi PHP lainnya, pembaruan pada sisi server menjadi langkah utama untuk menutup dua celah tersebut. Perlindungan tambahan dapat membantu mengurangi risiko, tetapi administrator tetap perlu memastikan PHP yang digunakan telah memperoleh patch resmi.
