Mengenal Apa itu PHP2Shell, Ancaman Celah Kritis RCE Paling Berbahaya dan yang Mengancam Jutaan Website di Seluruh Dunia

Assalamu‘alaikum wr. wb.

Hello guys! Beberapa hari yang lalu, Dunia sedang dihebohkan tentang Celah Kritis RCE yang mengancam Jutaan Website yang menggunakan Bahasa Pemrograman PHP, baik itu menggunakan PHP biasa, Laravel, hingga WordPress. Nama Celah Keamanannya adalah PHP2Shell atau dikenal sebagai CVE-2026-109618 dan CVE-2026-109619, yang diumumkan secara Publik pada 20 Oktober 2026 (9 Jumadil Awal 1448 H).

Sumber Artikel : en.Wikipedia.org, Wiz.io (Blog), Thehackernews.com, Upwind.io, Akamai.com (Blog), Tekno.Kompas.com (1), Tekno.Kompas.com (2), dan Inet.Detik.com

BERITA UTAMA

Ilustrasi PHP2Shell Code Injection

Rabu, 21 Oktober 2026 (10 Jumadil Awal 1448 H), sejumlah situs milik pemerintah di Eropa dan beberapa wilayah lainnya sengaja dihentikan sementara sebagai langkah pencegahan.

Langkah serupa diterapkan pada berbagai situs pemerintah Belanda, termasuk portal Overheid.nl dan situs milik Pusat Keamanan Siber Nasional Belanda (NCSC).

Di Denmark, penghentian layanan turut mencakup platform komunikasi nasional yang digunakan oleh sekolah-sekolah. Sementara itu, Finlandia menonaktifkan sejumlah layanan web publik pemerintah. Beberapa rumah sakit di Belanda juga memilih untuk menutup sementara akses ke situs web mereka.

Penonaktifan tersebut tidak serta-merta menunjukkan bahwa situs-situs itu telah diretas. Langkah pencegahan diambil untuk mengurangi risiko eksploitasi setelah dua kerentanan kritis pada PHP diumumkan kepada publik.

Bagi sebagian orang, istilah PHP mungkin masih terdengar asing. Padahal, bahasa pemrograman ini digunakan oleh banyak situs web yang diakses dalam kehidupan sehari-hari, mulai dari situs kelurahan, portal perguruan tinggi, jurnal ilmiah, sistem informasi rumah sakit, hingga toko online. Oleh karena itu, insiden yang terjadi di Eropa juga perlu menjadi perhatian di Indonesia.

Apa itu PHP?

Untuk memahaminya, kita bisa mengibaratkan sebuah situs web sebagai rumah makan. Halaman yang muncul di layar pengguna merupakan ruang makan, sedangkan bagian belakangnya adalah dapur tempat pesanan diproses.

Ketika seseorang memasukkan nama, mencari informasi pasien, atau mengisi formulir, permintaan tersebut dikirim ke bagian belakang sistem. Di sana, data diproses sebelum hasilnya ditampilkan kembali kepada pengguna.

PHP merupakan salah satu komponen yang menjalankan fungsi seperti dapur tersebut. PHP adalah bahasa pemrograman yang dijalankan di server, bukan secara langsung di ponsel atau laptop pengunjung. Fungsinya adalah menghasilkan halaman web secara dinamis berdasarkan permintaan pengguna.

Bahasa pemrograman ini sangat populer dan digunakan oleh berbagai platform, seperti WordPress, Drupal, Joomla, serta MediaWiki yang menjadi dasar bagi Wikipedia.

Apabila terdapat kerentanan pada PHP, banyak situs dengan tampilan, pengelola, dan tujuan yang berbeda dapat menghadapi ancaman serupa secara bersamaan.

Dari Alat Pribadi Menjadi Fondasi Web Dunia

PHP bermula dari kebutuhan sederhana. Pada 1994, seorang programmer bernama Rasmus Lerdorf membuat perangkat kecil untuk memantau pengunjung yang mengakses CV atau riwayat hidupnya secara online. Perangkat tersebut diberi nama Personal Home Page Tools, yang kemudian dikenal sebagai PHP Tools.

Pada Juni 1995, Lerdorf merilis kode sumbernya secara gratis kepada publik. Sejak saat itu, pengembang lain mulai menggunakan, memperbaiki, dan mengembangkan teknologi tersebut bersama-sama.

Popularitas PHP umumnya didukung oleh tiga faktor utama, yaitu gratis, relatif mudah dipelajari, serta didukung oleh hampir semua penyedia layanan hosting berbiaya terjangkau.

Berkat keunggulan tersebut, seorang mahasiswa dapat membangun situs web dinamis sederhana hanya dalam satu akhir pekan, kemudian mengunggahnya ke layanan hosting dengan biaya puluhan ribu rupiah per bulan.

Lembaga pemantau teknologi web, W3Techs, telah mengamati teknologi yang digunakan oleh jutaan situs sejak 2010. Data W3Techs dan berbagai sumber lainnya memperlihatkan bahwa PHP mendominasi pengembangan web selama bertahun-tahun.

Pada 2010, PHP digunakan oleh sekitar 72,5 persen situs yang tercatat. Angkanya meningkat menjadi 80,6 persen pada 2015, kemudian turun menjadi 78,8 persen pada 2021. Hingga Oktober 2026, proporsinya tercatat sekitar 69,3 persen.

Seiring perkembangan teknologi, pilihan bahasa pemrograman untuk pengembangan web semakin beragam. JavaScript, Ruby, dan Java terus berkembang, sementara sejumlah perusahaan teknologi besar memilih membangun sistem mereka sendiri.

Meskipun demikian, pada Oktober 2026 PHP masih memiliki pangsa penggunaan yang jauh lebih besar dibandingkan dengan para pesaingnya. JavaScript, sebagai salah satu pesaing terdekat, hanya mencatat sekitar 8 persen.

Ada satu temuan lain yang patut diperhatikan. Menurut W3Techs, sekitar 5,3 persen situs yang bahasa pemrograman sisi servernya diketahui masih menggunakan PHP 5.

Versi tersebut sudah lama tidak menerima pembaruan keamanan resmi. Dengan kata lain, masih terdapat banyak situs—termasuk ratusan ribu situs dalam sampel W3Techs—yang mengandalkan teknologi lama tanpa dukungan perbaikan keamanan dari pengembang resminya.

Mengapa PHP Begitu Dominan di Indonesia?

Besarnya penggunaan PHP juga terlihat di Indonesia. Survei wmtips terhadap 33.049 situs Indonesia menunjukkan bahwa PHP digunakan oleh sekitar 81,9 persen situs dengan platform yang berhasil diidentifikasi.

Dalam kategori kerangka kerja backend, Laravel dan CodeIgniter masing-masing menempati posisi pertama dan ketiga di Indonesia.

Dominasi tersebut dipengaruhi oleh beberapa faktor.

Pertama, biaya pengembangan dan infrastruktur. Layanan hosting yang mendukung PHP tersedia secara luas dan umumnya terjangkau. Untuk proyek berskala kecil, biayanya juga cenderung lebih rendah dibandingkan dengan alternatif yang membutuhkan server privat virtual (VPS). Kondisi ini menjadikannya pilihan menarik bagi organisasi dengan anggaran terbatas.

Kedua, faktor pendidikan. PHP dan MySQL banyak digunakan dalam pembelajaran pemrograman web di sekolah menengah kejuruan (SMK) maupun perguruan tinggi. Tidak sedikit tugas akhir mahasiswa yang berupa sistem informasi berbasis web dengan PHP sebagai teknologi utamanya.

Kondisi tersebut turut mendukung ketersediaan pengembang PHP yang dapat direkrut oleh vendor penyedia aplikasi untuk pemerintah daerah.

Ketiga, tersedianya aplikasi siap pakai secara gratis. Salah satu contoh utamanya adalah Open Journal Systems (OJS), yaitu platform pengelolaan jurnal ilmiah yang dibangun menggunakan PHP.

Berdasarkan studi PKP pada 2022 terhadap 25.671 Jurnal, Indonesia memiliki 11.535 jurnal yang menggunakan OJS. Jumlah tersebut setara dengan sekitar 45 persen dari keseluruhan jurnal dalam studi dan menjadi yang terbanyak dibandingkan dengan negara lain.

Di bidang kesehatan, terdapat pula SIMRS Khanza, aplikasi sistem informasi manajemen rumah sakit gratis yang menurut pengembangnya telah digunakan oleh lebih dari 1.500 rumah sakit. Sistem ini terutama dibangun menggunakan Java, tetapi juga memiliki komponen aplikasi web berbasis PHP.

Penggunaan PHP secara luas membawa berbagai keuntungan, terutama dalam mempercepat digitalisasi dengan biaya relatif rendah. Namun, ketergantungan tersebut juga memiliki konsekuensi. Ketika ditemukan kerentanan serius pada PHP, Indonesia menjadi salah satu negara yang berpotensi menghadapi dampak luas akibat besarnya jumlah situs yang menggunakan teknologi tersebut.

Apa yang Terjadi pada Pekan ini?

Dua kerentanan yang menjadi perhatian tersebut diberi kode CVE-2026-109618 dan CVE-2026-109619. Keduanya dikenal di kalangan komunitas keamanan dengan sebutan PHP2Shell dan memperoleh skor 9,2 dari 10 berdasarkan sistem penilaian CVSS versi 4.0. Skor tersebut menempatkannya dalam kategori kritis.

Secara sederhana, kerentanan ini berpotensi memungkinkan pihak luar mengambil alih proses yang berjalan di server. Penyerang tidak selalu perlu mengetahui kata sandi untuk mengeksploitasinya. Dalam kondisi tertentu, mereka cukup mengirimkan permintaan yang dirancang khusus agar memicu kelemahan pada sistem.

Pada konfigurasi tertentu, eksploitasi bahkan dapat berlangsung sebelum aplikasi sempat memvalidasi permintaan tersebut.

Situasi menjadi semakin rumit karena informasi terperinci mengenai kerentanan itu tersebar di internet pada 20 Oktober, satu hari sebelum pembaruan perbaikan tersedia.

Tim pengembang PHP kemudian mempercepat penerbitan pembaruan keamanan. Pada 21 Oktober 2026 (10 Jumadil Awal 1448 H), versi perbaikan yang dirilis mencakup PHP 8.5.12, 8.4.27, 8.3.36, dan 8.2.35. Sejumlah perusahaan keamanan juga melaporkan bahwa upaya eksploitasi mulai terdeteksi tidak lama setelah informasi tersebut beredar.

Sementara itu, PHP 8.1 dan versi yang lebih lama tidak lagi memperoleh pembaruan keamanan resmi. Pengelola sistem yang masih menggunakannya perlu mendapatkan paket perbaikan dari penyedia hosting atau distribusi yang digunakan, atau melakukan migrasi ke versi yang masih didukung.

Tidak ada langkah mitigasi sementara yang dapat menjamin perlindungan sepenuhnya terhadap kerentanan tersebut. Karena itu, memperbarui PHP ke versi yang telah diperbaiki merupakan langkah utama untuk mengatasi masalah ini.

Bagaimana Kerentanan Ini Bekerja?

Kerentanan pertama dapat dianalogikan seperti seorang pelayan yang sedang menyiapkan hidangan, tetapi bahan-bahannya habis sebelum proses selesai. Alih-alih membuang hidangan yang belum selesai, petugas kebersihan justru memperlakukannya seolah-olah sudah siap dan lengkap.

Penyerang dapat sengaja memicu kondisi ketika sumber daya yang dibutuhkan habis untuk mengacaukan proses tersebut. Pada server PHP, kelemahan dalam pengelolaan memori seperti ini berpotensi dimanfaatkan untuk menjalankan kode berbahaya.

Kerentanan kedua dapat diibaratkan sebagai meja makan yang belum dibersihkan dengan benar. Sisa makanan dari pelanggan sebelumnya masih tertinggal, meskipun meja sudah dianggap kosong dan siap digunakan kembali.

Pelanggan berikutnya berpotensi memanfaatkan sisa tersebut. Dalam sistem komputer, kondisi serupa dapat menyebabkan penyerang memanfaatkan data yang seharusnya sudah tidak digunakan, termasuk informasi sensitif seperti kata sandi, kunci akses, atau data milik pengguna lain.

Menurut informasi yang disampaikan dalam laporan mengenai kerentanan tersebut, kode yang rentan telah ada sejak PHP 5.4 pada 2012. Semua rilis sebelum PHP 8.2.35, 8.3.36, 8.4.27, dan 8.5.12 terdampak.

Artinya, situs berbasis PHP yang belum diperbarui ke versi yang telah diperbaiki berpotensi menghadapi risiko keamanan.

Sejumlah penyedia hosting telah menerapkan perbaikan pada server yang mereka kelola. Namun, pengelola yang mengoperasikan server sendiri tetap perlu melakukan pembaruan secara manual.

Akar masalah secara teknis terletak pada kelemahan dalam mekanisme pengelolaan memori PHP. Akan tetapi, jika dilihat dari besarnya dampak yang ditimbulkan, terdapat empat faktor mendasar yang perlu diperhatikan.

Pertama, kerentanan lama yang belum sepenuhnya terselesaikan.

Pada 2004, peneliti keamanan Stefan Esser menemukan kerentanan terkait batas memori pada PHP 4 sebelum versi 4.3.8 serta pada versi prarilis PHP 5.

Kerentanan tersebut kemudian diperbaiki. Namun, menurut Calif, pola masalah yang mendasarinya—yakni penghentian permintaan ketika pengelolaan memori belum berada dalam kondisi aman—masih menjadi salah satu titik rawan.

PHP Foundation juga mengungkapkan bahwa indikasi salah satu dari dua kerentanan terbaru sebenarnya telah ditemukan dalam audit eksternal pada 2024.

Pada saat itu, belum ditemukan mekanisme eksploitasi yang konkret. Proses perbaikan pun mengalami hambatan akibat pertimbangan kompatibilitas, proses pengambilan keputusan, serta keterbatasan tenaga ahli.

PHP Foundation bahkan menyebut keterlambatan tersebut sebagai sebuah “kegagalan struktural”.

Kedua, ketergantungan yang terlalu besar pada satu teknologi.

Ketika sekitar tujuh dari sepuluh situs di dunia dan delapan dari sepuluh situs berdomain .id menggunakan teknologi yang sama, sebuah kerentanan pada fondasi tersebut dapat berubah menjadi masalah berskala besar.

Semakin luas penggunaan suatu teknologi, semakin banyak pula sistem yang berpotensi terdampak ketika ditemukan kelemahan mendasar di dalamnya.

Ketiga, kurangnya pemahaman mengenai teknologi yang digunakan.

PHP tidak selalu terlihat secara langsung oleh pengguna maupun pengelola situs. Teknologi ini dapat berjalan di balik panel hosting, perangkat jaringan, atau aplikasi yang dikembangkan oleh vendor pihak ketiga.

Sebagian layanan tidak menampilkan versi PHP yang digunakan secara jelas. Akibatnya, sejumlah pengelola mungkin bahkan tidak menyadari bahwa situs atau aplikasi mereka bergantung pada PHP, termasuk versi yang sudah usang.

Kondisi ini menyulitkan proses identifikasi aset yang terdampak dan memperlambat penerapan pembaruan keamanan.

Keempat, meningkatnya kecepatan penemuan kerentanan berkat kecerdasan buatan.

Kerentanan yang tersembunyi selama lebih dari satu dekade tersebut dilaporkan berhasil ditemukan dalam hitungan minggu dengan bantuan model kecerdasan buatan (AI).

Pada Juli sebelumnya, kasus serupa juga terjadi di WordPress melalui kerentanan yang dikenal sebagai wp2shell.

AI dapat mempercepat proses analisis kode, identifikasi kelemahan, dan pengembangan eksploitasi. Namun, kemampuan tersebut tidak hanya dimanfaatkan oleh peneliti keamanan untuk menemukan dan memperbaiki celah, tetapi juga berpotensi digunakan oleh penyerang untuk mengembangkan serangan.

Ketika informasi mengenai kerentanan telah tersebar secara terbuka, waktu yang tersedia bagi pengelola sistem untuk melakukan pembaruan menjadi semakin sempit. Dalam situasi seperti ini, kesempatan untuk menutup celah keamanan bisa menyusut menjadi hanya beberapa jam hingga beberapa hari.

Situs Apa Saja yang Terdampak?

Peringatan darurat terkait kerentanan ini telah mengganggu berbagai layanan di seluruh dunia, mulai dari platform permainan hingga portal pemerintah dan forum daring. Wikimedia, organisasi yang menaungi Wikipedia, juga menonaktifkan sejumlah sistemnya untuk mengantisipasi potensi ancaman keamanan.

Sejumlah situs turut dinonaktifkan sementara oleh pemerintah Finlandia, Dewan Kota Edinburgh, dan BBC. Badan keamanan siber Belanda juga mengambil langkah serupa. Selain itu, beberapa organisasi publik di Skotlandia, termasuk dewan perwakilan dan lembaga kesehatan daerah, memilih menutup akses ke situs web mereka sebagai tindakan pencegahan.

Sejumlah pakar memperingatkan bahwa kerentanan ini dapat menimbulkan risiko yang lebih besar bagi situs web yang tidak mendapatkan pemeliharaan secara rutin. Ancaman tersebut terutama mengkhawatirkan bagi organisasi kecil yang memiliki sumber daya keamanan siber terbatas.

Mereka juga memperkirakan bahwa upaya eksploitasi terhadap celah tersebut akan meningkat dalam beberapa minggu mendatang, mengingat informasi teknis mengenai kerentanan itu telah tersedia untuk publik.

Apa yang Terjadi Setelah Kerentanan Terungkap?

Tim pengembang PHP merilis pembaruan keamanan atau patch untuk memperbaiki kerentanan yang telah tersembunyi di dalam perangkat lunak mereka selama bertahun-tahun. Para pengembang mengimbau seluruh pengguna PHP agar segera memperbarui sistem ke versi yang telah diperbaiki.

Peringatan serupa turut disampaikan oleh berbagai otoritas dan organisasi keamanan di berbagai negara. Badan Keamanan Nasional Amerika Serikat (NSA), misalnya, meminta organisasi yang menggunakan PHP untuk menonaktifkan sistem sementara apabila pembaruan keamanan tidak dapat segera diterapkan. NSA juga memperingatkan bahwa kerentanan tersebut berpotensi dimanfaatkan sebagai jalur untuk menyerang basis data yang terhubung dengan sistem.

Pusat Keamanan Siber Nasional Inggris (NCSC) mengeluarkan rekomendasi sejenis. Selain meminta organisasi memperbaiki kerentanan, lembaga tersebut juga mengimbau pengelola sistem untuk memeriksa kemungkinan adanya backdoor atau akses tersembunyi yang dipasang oleh penyerang.

Peringatan sejalan juga diterbitkan oleh lembaga keamanan siber di Uni Eropa dan Australia. Sementara itu, Perdana Menteri Jepang, Sanae Takaichi, mengimbau masyarakat untuk memeriksa apakah situs web publik yang mereka kelola menggunakan PHP.

Para pemilik dan pengelola situs web pun didesak untuk meningkatkan keamanan sistem dengan memasang versi PHP terbaru yang telah mendapatkan perbaikan. NSA turut menekankan pentingnya meningkatkan kewaspadaan selama beberapa minggu ke depan serta terus memantau pembaruan yang dirilis oleh vendor perangkat lunak.

Menurut lembaga tersebut, penerapan tambalan keamanan secara tepat waktu merupakan langkah yang sangat penting untuk mengurangi risiko eksploitasi dan mencegah dampak yang lebih luas.

TENTANG PHP2SHELL

PHP2Shell berkaitan dengan dua identitas kerentanan, yakni CVE-2026-109618 dan CVE-2026-109619. Keduanya mendapat skor tingkat keparahan CVSS v4.0 sebesar 9,2 dari 10, yang menempatkannya dalam kategori kritis. Tim pengembang PHP merilis pembaruan keamanan pada 21 Oktober 2026 untuk memperbaiki masalah tersebut.

Laporan dari Wiz Research menjelaskan bahwa kerentanan ini tidak semata-mata berasal dari WordPress, Joomla, Drupal, atau plugin tertentu. Akar masalahnya berada pada mesin PHP itu sendiri, khususnya pengelolaan memori ketika permintaan web diproses dan terjadi kesalahan fatal. Akibatnya, aplikasi yang kode bisnisnya telah ditulis dengan baik sekalipun berpotensi terdampak jika berjalan menggunakan versi PHP yang rentan.

Situasi tersebut memperlihatkan tantangan besar dalam pengamanan infrastruktur digital. Ketika masalah berada pada lapisan bahasa pemrograman yang digunakan oleh banyak aplikasi, satu kelemahan dapat menciptakan risiko lintas platform. Organisasi tidak cukup hanya memperbarui CMS atau menonaktifkan plugin tertentu; mereka perlu memastikan runtime PHP yang benar-benar menjalankan aplikasi telah diperbarui dan prosesnya menggunakan versi yang aman.

Artikel ini membahas secara mendalam apa itu PHP2Shell, bagaimana kerentanan tersebut bekerja, dampaknya bagi organisasi dan pengguna, serta langkah mitigasi yang perlu diprioritaskan oleh pengelola situs, administrator server, pengembang, dan tim keamanan informasi.

A. Mengenal PHP2Shell: Kerentanan Kritis yang Berada di Inti PHP

Apa itu PHP2Shell?

PHP2Shell adalah nama yang digunakan untuk merujuk pada rangkaian eksploitasi terhadap dua kerentanan kritis di PHP, yaitu CVE-2026-109618 dan CVE-2026-109619. Eksploitasi yang berhasil dapat memungkinkan penyerang menjalankan kode dari jarak jauh atau Remote Code Execution (RCE) pada sistem yang terdampak.

Istilah RCE mengacu pada kondisi ketika seseorang dapat membuat komputer atau server menjalankan instruksi yang dikendalikan dari jarak jauh. Dalam konteks server web, kemampuan tersebut berpotensi jauh melampaui sekadar mengubah tampilan halaman. Bergantung pada hak akses proses PHP dan konfigurasi lingkungan, penyerang dapat mencoba membaca data, mengubah berkas, memasang perangkat lunak berbahaya, atau menjadikan server sebagai titik awal untuk menyerang sistem lain.

Sementara itu, kata shell dalam nama PHP2Shell mengacu pada konteks eksekusi perintah pada sistem. Namun, istilah tersebut tidak berarti bahwa setiap situs yang rentan otomatis memberikan akses administrator atau akses root kepada penyerang. Tingkat kendali yang mungkin diperoleh bergantung pada keberhasilan eksploitasi, hak akses proses, pembatasan sistem operasi, dan kontrol keamanan lainnya.

Hal penting yang perlu dipahami adalah bahwa PHP2Shell bukan sekadar kerentanan pada sebuah plugin atau aplikasi web tertentu. Masalah ini berkaitan dengan mekanisme internal PHP dalam menangani memori dan kesalahan saat permintaan web sedang diproses. Oleh sebab itu, memperbarui plugin, mengganti tema, atau memasang ulang CMS tanpa memperbaiki versi PHP tidak menyelesaikan akar masalah.

Mengapa PHP2Shell menjadi perhatian besar?

PHP telah lama menjadi salah satu fondasi utama pengembangan web. Berbagai sistem populer menggunakan PHP, mulai dari WordPress dan Joomla hingga Drupal dan beragam aplikasi internal perusahaan.

Ketika sebuah kerentanan ditemukan pada aplikasi tertentu, pengelola biasanya dapat mengurangi risiko dengan memperbarui aplikasi tersebut. Akan tetapi, kerentanan pada runtime bahasa pemrograman memiliki cakupan yang lebih luas karena banyak aplikasi berbeda dapat bergantung pada komponen yang sama.

Wiz Research melaporkan bahwa peneliti berhasil mendemonstrasikan rantai eksploitasi terhadap instalasi WordPress, Drupal, dan Joomla. Demonstrasi tersebut penting bukan karena ketiga aplikasi itu secara khusus menjadi sumber masalah, melainkan karena aplikasi-aplikasi tersebut menunjukkan bagaimana kelemahan pada lapisan PHP dapat memengaruhi berbagai lingkungan web.

Bahkan, menurut penelitian yang dipublikasikan Wiz, masalah ini dapat relevan bagi aplikasi PHP yang sangat sederhana sekalipun. Dengan kata lain, aplikasi tidak harus menggunakan CMS besar atau mempunyai kode yang kompleks untuk menghadapi risiko runtime yang rentan.

Ada 3 (Tiga) alasan utama PHP2Shell perlu mendapat perhatian :

• Cakupan lintas aplikasi. Masalah berada di inti PHP, sehingga sejumlah aplikasi dan layanan yang menggunakan versi terdampak dapat menghadapi risiko serupa.
• Potensi serangan tanpa autentikasi. Penyerang tidak selalu perlu memiliki akun sah untuk memulai rangkaian serangan yang memanfaatkan kerentanan ini.
• Dampak yang dapat melampaui aplikasi web. Jika eksekusi kode berhasil, dampaknya dapat menjangkau berkas, kredensial, layanan, dan sumber daya lain yang dapat diakses oleh proses PHP.

Ketiga faktor tersebut membuat inventarisasi versi PHP, penerapan patch, dan pemeriksaan kemungkinan kompromi menjadi pekerjaan mendesak bagi organisasi yang mengoperasikan layanan berbasis PHP.

Dua Kerentanan Utama PHP2Shell

Kedua kerentanan ini berkaitan dengan masalah pengelolaan memori, tetapi mekanisme teknisnya tidak sepenuhnya sama.

CVE-2026-109618 berkaitan dengan penanganan proses yang gagal akibat kondisi kehabisan memori atau out-of-memory (OOM), termasuk jalur pemrosesan data yang berhubungan dengan fitur session upload progress. Dalam kondisi tertentu, kegagalan tersebut dapat membuat struktur internal PHP berada dalam keadaan tidak konsisten. Penanganan atau pembersihan berikutnya dapat berinteraksi dengan data yang sudah tidak valid. Peneliti juga melaporkan kemungkinan pengungkapan memori proses PHP tanpa autentikasi.

CVE-2026-109619 berkaitan dengan penanganan kesalahan fatal dan referensi memori yang sudah tidak lagi valid, termasuk jalur yang melibatkan backtrace kesalahan dan OPcache. Ketika PHP mempertahankan referensi ke memori yang telah dibebaskan, operasi berikutnya dapat menggunakan kembali referensi tersebut secara tidak semestinya. Kondisi ini dikenal sebagai use-after-free dan dapat membuka peluang terjadinya korupsi memori serta eksekusi kode.

Secara sederhana, masalah keduanya berpusat pada pertanyaan yang sama: apakah PHP selalu menjaga agar data dan referensi memori tetap valid ketika permintaan web gagal di tengah pemrosesan?

Dalam kondisi normal, PHP harus memastikan bahwa kegagalan sebuah permintaan tidak meninggalkan keadaan internal yang dapat merusak pemrosesan berikutnya. PHP2Shell menunjukkan bahwa kesalahan pada proses tersebut dapat menimbulkan konsekuensi keamanan yang serius.

Apakah semua situs PHP otomatis dapat diretas?

Tidak tepat jika dikatakan bahwa semua situs PHP pasti telah diretas atau bahwa seluruh instalasi PHP dapat dieksploitasi dengan cara yang identik.

Risiko aktual dipengaruhi oleh versi PHP, konfigurasi server, jenis SAPI yang digunakan, fitur yang aktif, pola pemrosesan permintaan, dan kemungkinan penyerang membangun rangkaian eksploitasi yang sesuai dengan target.

Namun, ketidakpastian mengenai keberhasilan eksploitasi tidak boleh dijadikan alasan untuk menunda pembaruan. Sistem yang menjalankan versi rentan dan menerima permintaan dari jaringan, khususnya internet, harus diperlakukan sebagai prioritas remediasi.

Peneliti Wiz melaporkan bahwa versi-versi PHP yang dirilis selama bertahun-tahun dapat terdampak oleh setidaknya salah satu masalah yang ditemukan, dengan riwayat kerentanan yang menjangkau PHP 5.4. Meski demikian, penentuan versi yang benar-benar terdampak dan versi perbaikan yang berlaku harus mengacu pada advisori resmi PHP serta paket pembaruan dari masing-masing distributor sistem operasi.

B. Kronologi Penemuan dan Penanganan PHP2Shell

PHP2Shell menjadi perhatian luas setelah pengumuman pembaruan keamanan PHP pada Oktober 2026. Rangkaian kejadian ini juga menyoroti pentingnya koordinasi antara peneliti keamanan, pengelola proyek perangkat lunak, penyedia infrastruktur, dan organisasi pengguna.

Penemuan Kerentanan dan Proses Pengungkapan

Menurut laporan Wiz Research, salah satu kerentanan ditemukan pada 19 Agustus 2026. Peneliti kemudian mengonfirmasi kemampuan eksekusi kode tanpa autentikasi dalam lingkungan pengujian dan melaporkan temuannya kepada tim keamanan PHP pada 24 Agustus 2026.

Setelah menerima laporan, tim PHP menyiapkan perbaikan dan mengoordinasikan pengungkapan dengan pihak terkait. Proses ini dimaksudkan agar pengelola sistem memperoleh pembaruan keamanan sebelum rincian teknis yang dapat membantu penyerang tersedia secara luas.

Akan tetapi, proses pengungkapan tersebut menghadapi tekanan ketika sebagian informasi mengenai kerentanan beredar sebelum jadwal publikasi yang direncanakan. Situasi itu mendorong percepatan jadwal rilis sehingga administrator perlu bersiap memasang pembaruan sesegera mungkin.

21 Oktober 2026: Pembaruan Keamanan dirilis

Pada 21 Oktober 2026 (10 Jumadil Awal 1448 H), PHP menerbitkan pembaruan yang memperbaiki dua kerentanan utama PHP2Shell. Pembaruan tersebut menjadi langkah utama untuk menutup akar masalah pada runtime.

Rilis perbaikan mencakup versi :

• PHP 8.5.12
• PHP 8.4.27
• PHP 8.3.36
• PHP 8.2.35

Organisasi yang masih menggunakan versi lebih lama perlu memeriksa jalur pembaruan yang sesuai dengan cabang PHP dan sistem operasi mereka. Nomor versi di atas merupakan rilis perbaikan untuk cabang masing-masing, bukan berarti seluruh versi PHP yang lebih tua dapat langsung ditingkatkan dengan cara yang sama tanpa memperhatikan kompatibilitas.

Administrator juga perlu memastikan bahwa pembaruan benar-benar diterapkan pada runtime yang melayani permintaan web. Mengubah versi PHP pada terminal atau lingkungan pengembangan tidak otomatis berarti versi PHP pada PHP-FPM, Apache, container, atau layanan produksi ikut berubah.

Aktivitas eksploitasi dilaporkan sebelum pengungkapan publik

Perkembangan berikutnya memperbesar urgensi penanganan. Amazon Threat Intelligence melaporkan adanya upaya eksploitasi yang terdeteksi pada 17 Oktober 2026, empat hari sebelum pembaruan PHP dirilis.

Temuan tersebut menunjukkan bahwa pengelola tidak seharusnya menganggap periode sebelum pengumuman publik sebagai periode yang sepenuhnya aman. Informasi dapat bocor, pihak tertentu dapat mengetahui rincian lebih awal, dan penyerang dapat melakukan pemindaian atau percobaan eksploitasi sebelum banyak organisasi sempat memasang patch.

Penting untuk membedakan antara upaya eksploitasi dan kompromi yang berhasil. Adanya permintaan berbahaya yang terdeteksi tidak dengan sendirinya membuktikan bahwa suatu server telah dikuasai. Sebaliknya, tidak ditemukannya bukti serangan juga bukan jaminan bahwa sistem tidak pernah menjadi sasaran.

Bagi organisasi, kronologi ini memperkuat satu prinsip: ketika kerentanan kritis diumumkan dan patch tersedia, prioritas pertama adalah mengurangi paparan, memasang perbaikan, lalu memeriksa apakah sistem pernah menunjukkan tanda-tanda kompromi.

C. Cara Kerja PHP2Shell: Memahami Akar Masalah Teknis

Untuk memahami PHP2Shell, kita perlu melihat bagaimana PHP menangani permintaan web dan mengelola memori ketika terjadi kegagalan.

Penjelasan berikut berfokus pada prinsip teknis yang mendasarinya, bukan petunjuk untuk membangun atau menjalankan eksploitasi terhadap sistem nyata.

1. PHP memproses Permintaan HTTP

Ketika seseorang membuka halaman web, browser mengirimkan permintaan HTTP ke server. Jika aplikasi menggunakan PHP, permintaan tersebut dapat diteruskan ke mesin PHP melalui mekanisme seperti Apache mod_php, PHP-FPM, atau implementasi lain yang kompatibel.

PHP kemudian menjalankan tahapan pemrosesan yang meliputi pembacaan permintaan, penanganan data, pengelolaan sesi jika diperlukan, dan eksekusi kode aplikasi.

Selama proses ini, PHP menggunakan memori untuk menyimpan variabel, struktur data, informasi permintaan, dan berbagai objek internal. Setelah permintaan selesai, memori yang digunakan perlu dibersihkan atau dikembalikan ke mekanisme pengelolaan memori yang sesuai.

Dalam kondisi normal, proses tersebut berlangsung tanpa menimbulkan dampak yang terlihat oleh pengguna selain respons halaman yang diharapkan.

Masalah muncul ketika suatu permintaan menyebabkan kondisi kesalahan yang tidak ditangani dengan benar. Jika kegagalan tersebut membuat struktur internal PHP tidak konsisten, tahapan pembersihan atau pemrosesan berikutnya dapat menggunakan data yang tidak lagi valid.

2. CVE-2026-109618: Kesalahan Alokasi Memori dan Penanganan Upload

Salah satu jalur kerentanan PHP2Shell berkaitan dengan penanganan permintaan yang memuat data unggahan serta fitur session upload progress.

Fitur tersebut dirancang untuk membantu aplikasi melaporkan perkembangan pengunggahan berkas. Dalam lingkungan yang relevan, PHP dapat menangani informasi terkait unggahan sebelum seluruh inisialisasi aplikasi selesai dilakukan.

Pengelolaan urutan ini penting karena pada tahap awal pemrosesan, sejumlah struktur internal PHP mungkin belum berada dalam kondisi yang sama seperti ketika aplikasi telah berjalan sepenuhnya.

Masalah dapat timbul apabila proses mengalami kegagalan alokasi memori. Dalam situasi OOM, sebuah operasi mungkin terhenti sebelum seluruh perubahan internal diselesaikan atau dibatalkan dengan benar.

Akibatnya, PHP berpotensi mempertahankan data atau referensi yang tidak lagi menggambarkan keadaan memori sebenarnya. Ketika mekanisme pembersihan kemudian berinteraksi dengan struktur tersebut, dapat muncul kondisi penggunaan memori yang tidak valid.

Wiz Research mengaitkan jalur ini dengan masalah use-after-free pada penanganan data internal yang berhubungan dengan proses unggahan. Peneliti juga mendemonstrasikan bahwa kondisi tertentu dapat mengakibatkan pengungkapan isi memori proses PHP.

Pengungkapan memori menjadi persoalan serius karena memori proses dapat memuat informasi yang seharusnya tidak tersedia bagi peminta eksternal. Bergantung pada keadaan proses, informasi itu dapat mencakup bagian data permintaan lain atau nilai sensitif yang masih berada dalam memori.

Pengungkapan memori tidak sama dengan eksekusi kode. Namun, dalam rantai serangan yang lebih kompleks, informasi tersebut dapat membantu penyerang memahami tata letak memori dan mengurangi ketidakpastian ketika mengeksploitasi kelemahan lain.

Dengan demikian, CVE-2026-109618 memperlihatkan bagaimana kesalahan penanganan kondisi OOM dapat berkembang dari persoalan stabilitas menjadi persoalan kerahasiaan dan integritas sistem.

3. CVE-2026-109619: Referensi Memori yang sudah Tidak Valid

CVE-2026-109619 melibatkan mekanisme yang berbeda, yaitu keadaan internal PHP setelah kesalahan fatal terjadi.

Dalam pengelolaan memori, use-after-free terjadi ketika program masih menggunakan referensi menuju area memori yang telah dibebaskan. Memori tersebut mungkin telah digunakan kembali untuk menyimpan data lain, sehingga program tidak lagi dapat mengasumsikan bahwa isi atau struktur di dalamnya masih sama seperti sebelumnya.

Dalam konteks PHP2Shell, penanganan kesalahan fatal tertentu dapat membuat referensi internal tetap menunjuk ke data yang sudah tidak valid. Apabila proses berikutnya menggunakan kembali referensi tersebut sebelum keadaan internal diatur ulang dengan benar, PHP dapat mengakses atau memodifikasi memori secara tidak semestinya.

Wiz Research juga menjelaskan jalur terkait OPcache. OPcache menyimpan representasi hasil kompilasi kode PHP agar aplikasi dapat berjalan lebih efisien. Mekanisme ini melibatkan pengelolaan struktur data dan referensi yang perlu tetap konsisten, termasuk ketika terjadi kegagalan alokasi memori.

Jika pembaruan keadaan internal tidak diselesaikan secara konsisten, struktur yang digunakan oleh proses berikutnya dapat tidak sesuai dengan objek yang sebenarnya menempati suatu lokasi memori.

Dalam skenario yang berhasil dieksploitasi, masalah semacam ini dapat berkembang menjadi korupsi memori yang memungkinkan eksekusi kode. Akan tetapi, hasil tersebut tidak otomatis terjadi pada setiap permintaan yang memicu kesalahan; keberhasilan eksploitasi bergantung pada kondisi dan rangkaian teknis yang relevan.

4. Mengapa satu permintaan dapat memengaruhi pemrosesan berikutnya?

Salah satu aspek penting dalam laporan PHP2Shell adalah kemungkinan keadaan internal yang bermasalah bertahan melampaui satu permintaan, bergantung pada model proses dan jalur eksekusi yang digunakan.

Pada lingkungan yang menggunakan proses pekerja persisten, sebuah worker dapat menangani beberapa permintaan selama masa hidupnya. Jika sebuah kegagalan meninggalkan referensi memori yang tidak valid dan keadaan itu tidak dibersihkan dengan benar, permintaan berikutnya yang diproses oleh worker yang sama berpotensi berinteraksi dengan keadaan tersebut.

Hal ini tidak berarti semua server PHP memiliki perilaku yang identik. Arsitektur proses, konfigurasi, dan implementasi SAPI memengaruhi bagaimana jalur kerentanan dapat terpicu.

Namun, konsep dasarnya menunjukkan mengapa pembersihan memori setelah kesalahan fatal merupakan bagian penting dari keamanan. Program harus memastikan bahwa kegagalan sebuah permintaan tidak meninggalkan keadaan yang dapat dimanfaatkan ketika permintaan lain mulai diproses.

5. Mengapa kerentanan ini tidak membutuhkan bug pada CMS?

Banyak kerentanan web berasal dari kode aplikasi, misalnya ketika aplikasi tidak memvalidasi masukan atau menggunakan kueri basis data secara tidak aman. PHP2Shell berbeda karena akar masalahnya berada pada mesin PHP.

CMS tetap menjadi bagian dari lingkungan yang terdampak, tetapi bukan berarti setiap CMS memiliki implementasi kode yang menyebabkan masalah tersebut.

Wiz Research melaporkan demonstrasi eksploitasi pada WordPress, Drupal, dan Joomla. Hasil itu memperlihatkan bahwa sebuah kelemahan pada lapisan runtime dapat memengaruhi berbagai aplikasi yang berjalan di atasnya.

Implikasinya bagi administrator sangat jelas: audit keamanan tidak boleh berhenti pada pemeriksaan versi CMS dan plugin. Inventaris harus mencakup versi runtime yang sebenarnya digunakan oleh setiap aplikasi, termasuk layanan produksi, container, worker latar belakang, dan lingkungan hosting yang dikelola sendiri.

Jadi, inilah Tabel Perbandingan antara CVE-2026-109618 dan CVE-2026-109619 untuk ID Pelacakan (Tracking ID) yang terkait dengan PHP2Shell :

ID Pelacakan	Bug	Apa yang Dapat Dilakukan Penyerang	Apa yang Kita Demonstrasikan
CVE-2026-109618	Kerentanan use-after-free pada unserializer progres unggahan (upload-progress). Pengungkapan memori proses dari jarak jauh.	Merusak memori proses dan mengeksekusi kode. Pengungkapan memori pekerja PHP tanpa autentikasi.	RCE (eksekusi kode jarak jauh) pra-autentikasi pada WordPress, Drupal, dan Joomla. Pengungkapan memori jarak jauh yang tidak bergantung pada aplikasi tertentu.
CVE-2026-109619	Backtrace kesalahan fatal akibat use-after-free. Type confusion pada OPcache.	Merusak memori proses dan mengeksekusi kode. Merusak status PHP bersama (shared state) dan mengeksekusi kode.	RCE pra-autentikasi pada Drupal. RCE pra-autentikasi pada WordPress.

D. Dampak dan Risiko PHP2Shell bagi Organisasi

Dampak PHP2Shell bergantung pada apakah kerentanan berhasil dieksploitasi, jenis data yang tersedia pada sistem, hak akses proses PHP, serta kontrol keamanan tambahan. Meski demikian, potensi konsekuensinya cukup serius untuk memerlukan penanganan prioritas tinggi.

1. Eksekusi Kode Jarak Jauh Tanpa Autentikasi

Eksekusi Kode Jarak Jauh (Remote Code Execution) via PHP2Shell pada Aplikasi Target [Sumber Gambar : Google Gemini dan Wiz.io (Blog)]

Risiko yang paling menonjol adalah remote code execution. Jika penyerang berhasil mencapai eksekusi kode pada proses PHP, ia dapat menjalankan instruksi dengan hak akses yang tersedia bagi proses tersebut.

Dalam konfigurasi yang membatasi PHP pada akun pengguna khusus, penyerang mungkin hanya memiliki akses sesuai hak akun tersebut. Namun, hak akses yang terbatas pun dapat memberikan jalan menuju data aplikasi, konfigurasi, atau kredensial yang sensitif.

Sebaliknya, jika proses PHP berjalan dengan hak akses terlalu tinggi atau memiliki akses luas ke sistem berkas, dampak potensialnya dapat menjadi lebih besar.

Penyerang yang memperoleh kemampuan eksekusi kode dapat mencoba :

• Membaca atau mengubah berkas aplikasi yang dapat diakses oleh proses PHP.
• Mengakses kredensial basis data yang disimpan dalam konfigurasi.
• Mengubah konten situs atau menyisipkan kode berbahaya.
• Menanam mekanisme akses tersembunyi untuk mempertahankan kendali.
• Menjalankan proses tambahan atau memanfaatkan akses jaringan server.
• Mencoba bergerak ke layanan lain yang dapat dijangkau dari lingkungan tersebut.

Daftar tersebut merupakan kemungkinan dampak, bukan bukti bahwa semua aktivitas itu telah terjadi pada setiap sistem yang rentan.

2. Kebocoran Informasi Sensitif dari Memori

Pengungkapan Memori Jarak Jauh PHP2Shell [Sumber : Google Gemini dan Wiz.io (Blog)]

Selain RCE, penelitian PHP2Shell mengungkap risiko pengungkapan memori proses PHP tanpa autentikasi.

Memori yang sedang digunakan oleh proses aplikasi dapat berisi informasi sementara yang tidak dimaksudkan untuk ditampilkan kepada pengguna. Dalam kondisi tertentu, informasi itu dapat meliputi token autentikasi, kata sandi yang sedang diproses, kunci API, atau data aplikasi lain.

Jika rahasia semacam ini terungkap, dampaknya dapat melampaui server tempat kebocoran terjadi. Sebagai contoh, token yang masih aktif mungkin dapat digunakan untuk mengakses API lain, sedangkan kredensial basis data dapat membuka jalan menuju informasi pelanggan.

Organisasi perlu memperlakukan kemungkinan kebocoran memori sebagai alasan untuk mengevaluasi kredensial yang dapat diakses oleh proses PHP. Jika terdapat bukti atau indikasi kuat bahwa eksploitasi berhasil, rotasi kredensial dan pencabutan token perlu dipertimbangkan sebagai bagian dari respons insiden.

3. Pengambilalihan Situs Web dan Perubahan Konten

Situs yang berhasil dikompromikan dapat digunakan untuk menampilkan konten palsu, mengarahkan pengunjung ke halaman berbahaya, atau menyisipkan skrip yang mencuri informasi.

Pada situs perusahaan, perubahan konten juga dapat merusak reputasi dan menurunkan kepercayaan pelanggan. Pada toko daring, kompromi dapat berpotensi mengganggu proses transaksi, memengaruhi integritas data pesanan, atau mengekspos informasi yang tersedia bagi aplikasi.

Kerusakan tidak selalu langsung terlihat. Penyerang dapat memilih untuk mempertahankan akses secara tersembunyi sambil mengumpulkan informasi atau menunggu kesempatan untuk melakukan tindakan lain.

Karena itu, pemeriksaan setelah pembaruan perlu mencakup integritas berkas, akun pengguna, konfigurasi aplikasi, tugas terjadwal, dan aktivitas proses yang tidak biasa.

4. Risiko terhadap Database dan Kredensial Layanan

Banyak aplikasi PHP menyimpan informasi koneksi basis data di berkas konfigurasi atau variabel lingkungan. Jika proses PHP dapat membaca informasi tersebut, eksekusi kode yang berhasil mungkin memungkinkan penyerang mencoba menggunakan kredensial terkait.

Besarnya risiko bergantung pada hak akses yang diberikan kepada akun basis data. Jika aplikasi menggunakan akun dengan hak administratif yang terlalu luas, kompromi aplikasi dapat berkembang menjadi gangguan yang lebih besar.

Prinsip hak akses minimum menjadi sangat penting dalam situasi ini. Akun aplikasi seharusnya hanya memperoleh izin yang benar-benar diperlukan, sedangkan kredensial untuk tugas administratif perlu dipisahkan dari kredensial yang digunakan oleh proses web sehari-hari.

5. Pergerakan Lateral dan Penyebaran Dampak

Dalam lingkungan perusahaan, satu server web dapat terhubung ke basis data, penyimpanan berkas, layanan autentikasi, sistem pemrosesan internal, atau API lain.

Jika penyerang menguasai proses pada server yang memiliki akses luas, ia dapat mencoba memanfaatkan koneksi tersebut untuk menjangkau sistem lain. Aktivitas ini dikenal sebagai lateral movement atau pergerakan lateral.

Keberhasilan langkah tersebut tidak otomatis mengikuti RCE. Akan tetapi, koneksi internal yang terlalu terbuka, kredensial bersama, dan segmentasi jaringan yang lemah dapat memperbesar dampak insiden.

Organisasi perlu menilai bukan hanya apakah sebuah server telah diperbarui, tetapi juga apa yang dapat diakses oleh server tersebut sebelum dan sesudah kompromi.

6. Gangguan Layanan dan Biaya Pemulihan

Serangan yang berhasil dapat mengakibatkan layanan berhenti beroperasi, proses PHP berulang kali gagal, atau administrator perlu mengisolasi server untuk pemeriksaan forensik.

Bahkan tanpa bukti kompromi, penanganan kerentanan kritis dapat membutuhkan waktu dan sumber daya yang besar. Tim harus menginventarisasi aset, memeriksa dependensi, menguji kompatibilitas patch, memperbarui sistem produksi, serta memverifikasi hasilnya.

Bagi perusahaan yang mengandalkan situs web untuk penjualan atau layanan pelanggan, keterlambatan remediasi juga dapat meningkatkan risiko gangguan bisnis.

7. Risiko kepatuhan dan reputasi

Jika insiden menyebabkan data pribadi atau informasi pelanggan terekspos, organisasi mungkin harus melakukan penilaian kewajiban pelaporan sesuai hukum dan ketentuan yang berlaku.

Selain persoalan hukum, insiden dapat mengurangi kepercayaan pelanggan, mitra, dan pemangku kepentingan. Organisasi perlu menunjukkan bahwa mereka memiliki proses pengelolaan kerentanan yang terukur, dapat diaudit, dan mampu merespons ancaman dengan cepat.

8. Risiko Rantai Pasok dan Hosting Bersama

PHP2Shell juga relevan bagi penyedia hosting dan organisasi yang mengoperasikan banyak aplikasi dalam satu infrastruktur.

Dalam lingkungan hosting bersama, sejumlah situs mungkin bergantung pada runtime yang dikelola oleh penyedia yang sama. Apabila penyedia terlambat menerapkan patch, banyak pelanggan dapat menghadapi paparan yang serupa.

Sebaliknya, jika organisasi mengelola VPS atau server sendiri, tanggung jawab pembaruan runtime biasanya berada pada tim yang mengelola sistem tersebut. Pelanggan tidak boleh berasumsi bahwa penyedia layanan telah memperbaiki PHP tanpa memastikan ruang lingkup layanan dan status pembaruannya.

E. Langkah Mitigasi PHP2Shell: Apa yang Harus Dilakukan Administrator?

Penanganan PHP2Shell harus dilakukan dengan pendekatan berlapis. Pembaruan PHP merupakan tindakan paling penting, tetapi organisasi juga perlu membatasi paparan server, memeriksa indikasi serangan, dan memastikan bahwa sistem yang diperbarui tidak menyimpan jejak kompromi sebelumnya.

Tim keamanan PHP secara tegas menyatakan bahwa tidak ada mitigasi sementara yang sepenuhnya menggantikan pembaruan keamanan. Karena itu, langkah-langkah berikut harus dipahami sebagai rangkaian tindakan yang saling melengkapi, bukan alternatif yang membuat patch tidak lagi diperlukan.

1. Segera Perbarui PHP ke versi yang telah diperbaiki

Prioritas pertama adalah memperbarui runtime PHP ke rilis keamanan yang sesuai dengan cabang versi yang digunakan.

Cabang PHP	Versi perbaikan
PHP 8.5	8.5.12
PHP 8.4	8.4.27
PHP 8.3	8.3.36
PHP 8.2	8.2.35

Rilis tersebut diumumkan pada 21 Oktober untuk menangani CVE-2026-109618 dan CVE-2026-109619. Pengelola sistem dapat merujuk pada Pengumuman Resmi di Situs PHP: https://www.php.net/archive/2026.php.

Untuk instalasi yang dikelola melalui paket Linux, gunakan pembaruan dari distributor yang bertanggung jawab atas sistem tersebut. Distributor tertentu dapat menerapkan perbaikan keamanan pada paket dengan nomor versi yang berbeda dari rilis upstream. Oleh karena itu, verifikasi status patch berdasarkan advisori distributor, bukan hanya dengan membandingkan nomor versi secara langsung.

Perlu diperhatikan pula bahwa PHP 8.1 dan versi yang lebih lama tidak lagi memperoleh pembaruan dari proyek PHP upstream. Beberapa distributor mungkin menyediakan patch melalui dukungan jangka panjang, tetapi organisasi harus memastikan status tersebut secara spesifik. Jika tidak tersedia paket aman yang didukung, migrasi ke cabang PHP yang masih mendapatkan dukungan menjadi pilihan yang perlu diprioritaskan.

2. Pastikan Seluruh Rruntime benar-benar diperbarui

Memasang patch pada satu lingkungan tidak berarti seluruh infrastruktur sudah aman. Organisasi perlu memeriksa semua tempat PHP dijalankan, termasuk :

• Server produksi yang melayani permintaan internet.
• PHP-FPM dan pool pekerjanya.
• Apache yang menggunakan mod_php.
• php-cgi, FrankenPHP, dan LiteSpeed.
• Container, image dasar, serta deployment berbasis Kubernetes.
• Server staging, pengujian, dan pengembangan yang dapat diakses melalui jaringan.
• Worker antrean, cron job, dan layanan latar belakang berbasis PHP.

Pada lingkungan Linux, perintah berikut dapat membantu mengidentifikasi versi PHP CLI yang aktif :

php -v

Namun, hasil tersebut tidak selalu menunjukkan versi yang digunakan oleh aplikasi web. Server dapat memiliki beberapa versi PHP sekaligus, sementara Apache atau PHP-FPM menggunakan runtime yang berbeda dari CLI.

Karena itu, periksa pula paket yang terpasang, konfigurasi layanan, versi PHP-FPM, image container, dan konfigurasi deployment. Setelah pembaruan, lakukan restart atau reload layanan sesuai prosedur vendor agar proses lama tidak terus menggunakan runtime yang rentan.

Validasi tidak boleh berhenti pada status instalasi paket. Tim harus memastikan bahwa permintaan web benar-benar diproses oleh versi yang telah diperbaiki.

3. Terapkan Pembatasan Permintaan sebagai Pertahanan Tambahan

Sambil menyelesaikan pembaruan, administrator dapat mengurangi risiko dengan membatasi ukuran dan kompleksitas permintaan yang diterima server.

Tim PHP menyarankan pengaturan post_max_size yang rendah sesuai kebutuhan aplikasi. Sebagai contoh, nilai 8 MB dapat dipertimbangkan untuk aplikasi yang tidak memerlukan unggahan berkas besar, sedangkan nilai 32 MB dapat menjadi titik awal bagi aplikasi yang membutuhkan unggahan. Angka ini bukan nilai universal; kebutuhan bisnis dan ukuran berkas yang sah harus tetap diperhitungkan.

Parameter upload_max_filesize juga perlu disesuaikan agar tidak melebihi post_max_size.

Di tingkat reverse proxy atau web server, pertimbangkan pembatasan untuk :

• Ukuran badan permintaan setelah memperhitungkan bagaimana server memproses data.
• Jumlah bagian multipart dalam permintaan.
• Jumlah kolom masukan dan header.
• Kedalaman struktur data yang diterima.
• Batas waktu pemrosesan dan jumlah koneksi yang dapat ditangani secara bersamaan.

Pembatasan harus diterapkan dengan hati-hati agar tidak mengganggu fitur sah seperti formulir, impor data, dan unggahan dokumen. Aturan juga perlu memperhitungkan permintaan yang tidak memiliki header Content-Length yang dapat digunakan.

Perlu digarisbawahi bahwa pembatasan ini hanya mengurangi sebagian jalur risiko. Aturan WAF, batas ukuran unggahan, dan pembatasan permintaan bukan pengganti patch PHP.

4. Nonaktifkan fitur Session Upload Progress jika sesuai

Salah satu langkah mitigasi tambahan yang disebutkan dalam advisori PHP adalah menonaktifkan fitur session upload progress untuk mengurangi risiko pada jalur tertentu yang berkaitan dengan CVE-2026-109619.

Pengaturan yang relevan adalah :

session.upload_progress.enabled = 0

Pengaturan ini perlu diterapkan melalui konfigurasi server yang berlaku sebelum permintaan diproses, misalnya konfigurasi PHP-FPM pool atau konfigurasi server yang sesuai. Setelah itu, restart seluruh worker yang relevan.

Jangan mengandalkan ini_set() yang dijalankan oleh aplikasi atau pengaturan .user.ini untuk mitigasi ini, karena perubahan tersebut mungkin diterapkan terlalu terlambat dalam siklus pemrosesan permintaan.

Langkah ini mempunyai batasan penting. Menonaktifkan session upload progress tidak menyelesaikan seluruh akar masalah PHP2Shell dan tidak memberikan perlindungan menyeluruh terhadap semua varian kerentanan. Gunakan sebagai lapisan mitigasi tambahan ketika pembaruan belum selesai, bukan sebagai alasan menunda patch.

5. Terapkan mitigasi tambahan untuk jalur kesalahan fatal

Advisori PHP juga menyebutkan pengaturan fatal_error_backtraces=0 pada PHP 8.5 untuk mengurangi risiko dari jalur tertentu yang melibatkan fatal error backtrace.

Pengaturan tersebut hanya memblokir jalur yang telah diidentifikasi dan tidak memperbaiki semua varian kerentanan memori. Penerapannya harus mengikuti advisori resmi dan mempertimbangkan dampak terhadap kebutuhan diagnostik aplikasi.

Selain itu, tim pengembang perlu meninjau penanganan kesalahan fatal yang dapat dipicu dari masukan eksternal, termasuk saat unggahan atau impor data diproses. Perbaikan pada kode aplikasi dapat membantu mengurangi kondisi pemicu tertentu, tetapi tidak dapat menggantikan perbaikan pada mesin PHP.

6. Gunakan WAF dan aturan deteksi jaringan

Web Application Firewall (WAF) dapat membantu menyaring pola permintaan yang diketahui berkaitan dengan eksploitasi. Aturan deteksi juga dapat diterapkan pada reverse proxy, load balancer, atau sistem pemantauan jaringan.

Namun, efektivitas WAF bergantung pada kualitas aturan, cara permintaan diproses, dan kemampuan penyerang mengubah pola serangan. Serangan yang tidak sesuai dengan pola yang diketahui dapat lolos dari penyaringan.

Oleh karena itu, WAF harus diposisikan sebagai lapisan pertahanan tambahan. Organisasi perlu tetap memperbarui PHP meskipun telah memiliki WAF, sistem deteksi intrusi, atau perlindungan dari penyedia hosting.

7. Periksa Log dan Cari Indikasi Eksploitasi

Karena percobaan eksploitasi dilaporkan sebelum pembaruan dirilis, administrator sebaiknya memeriksa log untuk periode sebelum dan sesudah tanggal pengungkapan.

Indikator yang dapat ditinjau meliputi :

• Lonjakan permintaan multipart yang tidak biasa.
• Permintaan berulang yang diikuti kesalahan HTTP 500.
• Pesan kehabisan memori yang muncul tanpa penjelasan operasional yang jelas.
• Worker PHP yang berhenti atau dimulai ulang secara tidak biasa.
• Perubahan tidak sah pada berkas aplikasi.
• Proses baru atau koneksi jaringan keluar yang tidak sesuai dengan perilaku normal server.
• Aktivitas akses ke berkas konfigurasi atau kredensial yang tidak dapat dijelaskan.

Indikator tersebut tidak selalu menandakan serangan. Kesalahan HTTP 500 atau penggunaan memori tinggi dapat terjadi akibat masalah aplikasi biasa. Karena itu, analisis perlu menghubungkan waktu kejadian, pola permintaan, aktivitas proses, dan perubahan berkas untuk memperoleh kesimpulan yang lebih dapat dipercaya.

Organisasi juga perlu mengingat bahwa eksploitasi pada lapisan PHP mungkin tidak selalu menghasilkan catatan aplikasi yang jelas. Log aplikasi sebaiknya dilengkapi dengan log web server, telemetri endpoint, catatan proses, dan data jaringan jika tersedia.

8. Evaluasi kredensial dan hak akses proses PHP

Jika terdapat bukti bahwa server berhasil dieksploitasi, jangan menganggap bahwa pemasangan patch otomatis menghapus seluruh dampak serangan sebelumnya.

Tim respons insiden perlu menilai kemungkinan kebocoran kredensial dan memeriksa akses yang dimiliki proses PHP. Jika relevan, lakukan rotasi kata sandi basis data, token API, kunci layanan, dan kredensial lain yang berpotensi diakses dari proses tersebut.

Pastikan proses PHP tidak berjalan dengan hak root jika tidak diperlukan. Pisahkan akun layanan, batasi izin berkas, dan minimalkan akses jaringan ke layanan internal. Dengan cara ini, keberhasilan eksploitasi pada satu proses tidak langsung memberikan akses luas ke seluruh infrastruktur.

9. Lakukan Isolasi dan Pemulihan jika Kompromi Terindikasi

Jika ditemukan bukti kuat adanya eksekusi kode tidak sah, organisasi harus memperlakukan situasi tersebut sebagai kemungkinan insiden keamanan, bukan sekadar masalah patch yang terlambat.

Langkah yang dapat dilakukan meliputi :

• Membatasi konektivitas server yang dicurigai untuk mencegah aktivitas lanjutan.
• Mengamankan log, artefak, dan bukti digital sebelum melakukan perubahan yang dapat menghilangkannya.
• Menyelidiki proses, akun, berkas, tugas terjadwal, serta koneksi jaringan yang mencurigakan.
• Memperbarui sistem dan menutup akses yang tidak diperlukan.
• Memulihkan sistem dari sumber yang diketahui bersih jika integritasnya tidak dapat dipastikan.
• Mengganti kredensial yang berpotensi terpapar dan memantau akses setelah pemulihan.

Isolasi dan pemulihan harus disesuaikan dengan tingkat kritikal layanan. Untuk sistem penting, koordinasikan tindakan bersama tim keamanan, infrastruktur, pemilik aplikasi, dan pihak penyedia layanan.

F. Apakah PHP2Shell Sudah Ditambal? Perbedaan Patch dan Mitigasi

Pertanyaan ini penting karena istilah Unpatched Vulnerability yang digunakan dalam laporan awal dapat menimbulkan kesan bahwa kerentanan masih belum mempunyai perbaikan.

Per 27 Oktober 2026 (16 Jumadil Awal 1448 H), PHP telah merilis pembaruan untuk 2 (Dua) Kerentanan Utama PHP2Shell. Dengan demikian, patch untuk CVE-2026-109618 dan CVE-2026-109619 telah tersedia, tetapi belum tentu seluruh server yang terdampak sudah memasangnya.

Tiga keadaan perlu dibedakan :

Pertama, patch tersedia. Pengembang telah menerbitkan versi yang memperbaiki masalah.

Kedua, sistem telah diperbarui. Administrator telah menerapkan paket yang sesuai dan memastikan runtime yang melayani permintaan menggunakan versi yang telah diperbaiki.

Ketiga, sistem telah dinyatakan aman setelah pemeriksaan. Selain patch, organisasi telah mengevaluasi kemungkinan kompromi sebelumnya, memeriksa integritas sistem, dan menindaklanjuti temuan yang relevan.

Sistem yang sudah diperbarui masih mungkin memerlukan investigasi jika sebelumnya terpapar ketika eksploitasi sedang berlangsung. Sebaliknya, sistem yang belum menunjukkan indikasi kompromi tetap perlu diperbarui selama menggunakan runtime yang rentan.

Penting juga untuk membedakan PHP2Shell dari kerentanan lain yang diumumkan setelahnya. Pada 23 Oktober 2026 (12 Jumadil Awal 1448 H), terdapat laporan mengenai CVE-2026-115560, masalah terpisah yang berhubungan dengan konfigurasi sesi PHP yang tidak lazim. Untuk konfigurasi tertentu, PHP menyarankan penonaktifan session.upload_progress.enabled sampai perbaikan rutin tersedia.

CVE-2026-115560 bukan nama lain untuk PHP2Shell dan tidak boleh diasumsikan otomatis terselesaikan hanya dengan memasang patch PHP2Shell. Administrator perlu memeriksa advisori terbaru dan menentukan apakah konfigurasi mereka memenuhi kondisi yang dijelaskan.

G. Peran AI dalam Penemuan PHP2Shell dan Perubahan Lanskap Keamanan Siber

Sumber : Forkast.news dan Livemint.com

Salah satu aspek paling menarik dari kasus PHP2Shell adalah peran Kecerdasan Buatan (AI) dalam membantu peneliti menemukan dan membuktikan kerentanan keamanan yang selama bertahun-tahun sulit dieksploitasi.

Penemuan ini melibatkan beberapa pihak yang melakukan penelitian secara independen, termasuk Ryan Austin dari perusahaan keamanan siber Calif melalui proyek OpenAI Patch the Planet, serta tim Wiz Research yang menggunakan kombinasi model AI dan alat analisis internal.

Tiga teknologi yang menonjol dalam laporan penelitian tersebut adalah GPT-5.6 Sol, Gemini 4 Argon, dan Wiz Atlas. Ketiganya disebut dalam konteks penelitian Wiz, sementara GPT-5.6 Sol juga dikaitkan dengan penelitian Ryan Austin melalui proyek Patch the Planet.

Peristiwa ini memperlihatkan perubahan penting dalam penelitian keamanan siber: AI tidak hanya membantu menulis kode atau menganalisis log, tetapi juga dapat membantu peneliti menelusuri kelemahan pada kode sumber, menyusun hipotesis eksploitasi, menguji kemungkinan serangan, dan memvalidasi perbaikan keamanan.

1. GPT-5.6 Sol: Membantu menemukan kelemahan melalui analisis kode

GPT-5.6 Sol merupakan salah satu model AI yang disebut dalam laporan mengenai penelitian PHP2Shell.

Ryan Austin, peneliti dari Calif yang berbasis di California, menggunakan bantuan model ini dalam audit keamanan PHP melalui inisiatif OpenAI Patch the Planet. Dalam penelitian tersebut, model AI membantu proses penelusuran kode dan investigasi terhadap perilaku PHP ketika mengalami kesalahan pengelolaan memori.

Secara umum, model bahasa besar atau large language model (LLM) dapat membantu peneliti memahami hubungan antarfungsi, mengidentifikasi jalur kode yang berpotensi bermasalah, dan menyusun hipotesis tentang penyebab sebuah program mengalami kegagalan.

Pada penelitian keamanan, hipotesis tersebut kemudian perlu diuji melalui analisis kode, eksperimen terkontrol, dan validasi teknis. Model AI tidak dengan sendirinya membuktikan bahwa suatu kelemahan dapat dieksploitasi; hasil analisisnya harus diperiksa dan dikonfirmasi oleh peneliti.

Dalam kasus PHP2Shell, penelitian yang dibantu AI membantu memperlihatkan bahwa masalah pengelolaan memori yang sebelumnya sulit dimanfaatkan dapat dikembangkan menjadi rangkaian eksploitasi yang berpotensi menjalankan kode dari jarak jauh.

2. Gemini 4 Argon: Berkontribusi pada penemuan dan validasi eksploitasi

Tim Wiz Research melakukan penelitian independen dan menyebut Gemini 4 Argon sebagai salah satu model AI yang digunakan dalam investigasi PHP2Shell.

Menurut laporan resmi Wiz, Gemini 4 Argon memberikan kontribusi penting dalam beberapa tahapan penelitian, termasuk menemukan kerentanan, mengembangkan eksploitasi, mendukung deteksi serangan, dan memvalidasi perbaikan keamanan.

Hal ini menunjukkan bahwa peran AI dalam penelitian keamanan tidak terbatas pada menemukan potongan kode yang mencurigakan. Teknologi tersebut juga dapat membantu menghubungkan temuan awal dengan pengujian lanjutan untuk memahami dampak dan menentukan apakah perbaikan benar-benar menangani akar masalah.

Meski demikian, temuan Wiz tidak berarti Gemini 4 Argon bekerja sendirian. Penelitian tersebut melibatkan para peneliti keamanan, pengujian teknis, alat pendukung, dan koordinasi dengan tim pengembang PHP.

Penting pula untuk membedakan klaim yang benar-benar dinyatakan oleh peneliti dari kesimpulan yang lebih luas. Wiz secara khusus menyoroti kontribusi Gemini 4 Argon, tetapi hal itu tidak berarti seluruh proses penemuan atau eksploitasi dilakukan secara otomatis oleh model tersebut.

3. Wiz Atlas: Alat internal untuk mendukung penelitian keamanan

Selain menggunakan model AI, Wiz Research juga memanfaatkan Wiz Atlas, alat internal yang disebut dalam laporan mereka sebagai bagian dari proses penelitian PHP2Shell.

Wiz Atlas perlu dibedakan dari Gemini 4 Argon dan GPT-5.6 Sol. Gemini dan GPT merupakan nama model AI, sedangkan Wiz Atlas merupakan alat yang digunakan dalam alur kerja penelitian Wiz.

Dalam penelitian tersebut, kombinasi alat dan model membantu peneliti menyelidiki kode PHP, menguji dugaan kerentanan, mengembangkan demonstrasi eksploitasi, serta mengevaluasi deteksi dan perbaikan.

Pendekatan ini menggambarkan bagaimana sistem keamanan berbantuan AI dapat menggabungkan beberapa kemampuan dalam satu proses kerja. Model AI membantu analisis dan penalaran, sedangkan alat pendukung membantu pelaksanaan tugas penelitian dan pengujian yang relevan.

Namun, rincian mengenai kontribusi masing-masing komponen tidak boleh dilebih-lebihkan. Laporan Wiz menjelaskan bahwa ketiga teknologi digunakan dalam penelitian, tetapi tidak berarti setiap tahap penelitian hanya ditangani oleh satu model atau satu alat secara terpisah.

4. Penemuan Independen oleh Calif dan Wiz Research

PHP2Shell bukan hasil dari satu tim yang bekerja sendirian. Laporan yang tersedia menjelaskan bahwa Calif dan Wiz Research menemukan jalur kerentanan melalui penelitian yang dilakukan secara independen.

Calif mengaitkan penelitiannya dengan proyek OpenAI Patch the Planet, sedangkan Wiz Research menggunakan kombinasi Wiz Atlas, Gemini 4 Argon, dan GPT-5.6 Sol.

Menurut kronologi yang dipublikasikan, Wiz Research menemukan kerentanan pertama pada 19 Agustus 2026 (6 Rabi'ul Awal 1448 H) dan melaporkannya kepada tim keamanan PHP pada 24 Agustus 2026 (11 Rabi'ul Awal 1448 H). Sementara itu, penelitian Calif telah berlangsung pada awal Agustus, dengan laporan kerentanan pertama kepada PHP pada 11 Agustus 2026 (27 Safar 1448 H).

Kronologi ini penting karena menunjukkan bahwa kemunculan PHP2Shell bukan sekadar hasil dari satu model AI yang menemukan bug secara tiba-tiba. Ada beberapa jalur penelitian, validasi teknis, dan koordinasi pengungkapan yang terlibat.

Penelitian independen juga membantu memperkuat proses penanganan. Ketika beberapa tim menemukan masalah serupa, pengembang dapat membandingkan temuan, memvalidasi penyebab, dan memastikan perbaikan menangani akar masalah yang relevan.

5. Bagaimana AI membantu menemukan kerentanan yang sulit dieksploitasi?

PHP2Shell memperlihatkan perbedaan antara menemukan bug dan membuktikan bahwa bug tersebut dapat dieksploitasi.

Suatu masalah pengelolaan memori mungkin telah diketahui atau dicurigai sejak lama, tetapi mengubahnya menjadi eksploitasi yang dapat dijalankan dari jarak jauh membutuhkan tahapan analisis tambahan.

Peneliti perlu memahami kondisi pemicu, keadaan memori setelah kegagalan, interaksi antarbagian program, dan perilaku aplikasi dalam lingkungan pengujian. Proses ini dapat melibatkan banyak percobaan dan pemeriksaan hasil.

AI dapat membantu mempercepat pekerjaan tersebut melalui beberapa cara :

• Analisis kode sumber: Membantu menelusuri hubungan antarfungsi dan mengidentifikasi jalur yang perlu diperiksa lebih lanjut.
• Penyusunan hipotesis: Membantu peneliti merumuskan kemungkinan penyebab kesalahan dan menentukan eksperimen yang relevan.
• Analisis hasil pengujian: Membantu menafsirkan kegagalan program, pola kesalahan, dan hasil eksperimen.
• Pengembangan dan pengujian demonstrasi: Membantu peneliti mengevaluasi apakah sebuah dugaan kelemahan dapat dibuktikan dalam lingkungan laboratorium yang terkendali.
• Validasi perbaikan: Membantu membandingkan perilaku sebelum dan sesudah patch untuk mencari indikasi bahwa masalah telah ditangani.

Kemampuan tersebut tidak menghilangkan kebutuhan akan keahlian manusia. Peneliti tetap harus memeriksa hasil, membedakan temuan yang benar dari dugaan yang keliru, serta memastikan bahwa eksperimen dilakukan secara aman dan bertanggung jawab.

6. Mengapa penemuan ini mengubah lanskap Keamanan Siber?

Selama bertahun-tahun, kompleksitas teknis menjadi salah satu faktor yang membatasi eksploitasi terhadap sejumlah kelemahan perangkat lunak. Sebuah bug dapat diketahui, tetapi penyerang belum tentu mampu mengubahnya menjadi serangan praktis.

PHP2Shell menunjukkan bahwa AI dapat membantu mengurangi sebagian hambatan tersebut. Ketika analisis kode, pengujian, dan pengembangan demonstrasi eksploitasi menjadi lebih cepat, kelemahan yang sebelumnya dianggap sulit dimanfaatkan dapat menjadi lebih relevan sebagai ancaman nyata.

Perubahan ini memiliki dua sisi, yaitu :

Dari sisi pertahanan, organisasi dapat memanfaatkan AI untuk mempercepat audit kode, menemukan masalah keamanan, menguji patch, dan menganalisis indikator serangan.

Dari sisi penyerangan, kemampuan serupa berpotensi mempercepat penelitian kerentanan dan pengembangan eksploitasi oleh pihak yang memiliki niat jahat. Karena itu, organisasi tidak seharusnya mengandalkan anggapan bahwa kerentanan memori yang kompleks terlalu sulit untuk diserang.

Pelajaran penting dari PHP2Shell adalah bahwa kecepatan deteksi dan remediasi harus terus ditingkatkan. Organisasi perlu memiliki inventaris aset yang akurat, proses pengelolaan patch yang disiplin, pengujian keamanan yang konsisten, serta kemampuan pemantauan dan respons insiden yang memadai.

Pada akhirnya, GPT-5.6 Sol, Gemini 4 Argon, dan Wiz Atlas menunjukkan bagaimana model AI dan alat penelitian dapat membantu manusia menghadapi masalah keamanan perangkat lunak yang kompleks. Namun, penemuan PHP2Shell tetap merupakan hasil dari penelitian, eksperimen, validasi, dan koordinasi berbagai pihak—bukan sekadar keluaran otomatis dari sebuah model AI.

Itulah pembahasan mengenai Celah Kritis RCE PHP2Shell yang sedang heboh, terutama bagi Web Developer di bidang PHP.

Untuk membaca Artikel sebelumnya tentang Modul Pemrograman PHP, silakan lihat di sini. Atau, jika ingin membaca tentang Aplikasi REST API Sederhaha menggunakan PHP, silakan lihat di sini.

Dan, nantikan pembahasan selanjutnya tentang Modul Tutorial Laravel untuk Pemula!

Terima Kasih 😄😘👌👍 :)

Wassalamu‘alaikum wr. wb.