PHP2Shell : Mengenal Celah Keamanan PHP, Dampak, dan Cara Mitigasinya

Keamanan aplikasi web tidak hanya bergantung pada sistem autentikasi, plugin, atau kode aplikasi. Runtime yang menjalankan aplikasi tersebut juga harus dikelola dan diperbarui secara berkala.

Salah satu isu keamanan yang perlu mendapat perhatian tim IT adalah PHP2Shell, istilah yang digunakan dalam analisis keamanan Akamai untuk merujuk pada dua kerentanan kritis di inti PHP yang berpotensi memungkinkan remote code execution (RCE) tanpa autentikasi.

Pada 21 Oktober 2026, proyek PHP menerbitkan pembaruan keamanan untuk mengatasi dua kerentanan tersebut, yaitu CVE-2026-109618 dan CVE-2026-109619. Keduanya dinilai memiliki tingkat keparahan Critical, dengan skor CVSS v4.0 sebesar 9,2 dalam pemberitahuan awal PHP.

Kerentanan ini perlu diperhatikan oleh organisasi yang menjalankan website, portal pelanggan, aplikasi internal, dan layanan digital berbasis PHP. PHP menyatakan bahwa instalasi yang melayani request web perlu dievaluasi, dengan risiko yang secara khusus dinilai paling tinggi pada konfigurasi Apache mod_php berdasarkan skenario eksploitasi yang telah diperlihatkan.

Karena itu, langkah yang disarankan adalah memeriksa runtime PHP, menerapkan pembaruan keamanan yang sesuai, dan memastikan bahwa sistem yang diperbarui benar-benar menggunakan paket yang telah diperbaiki.

Apa Itu PHP2Shell?

PHP2Shell bukan nama resmi satu produk atau satu kerentanan tersendiri. Istilah ini digunakan untuk membahas dua kerentanan pada inti PHP yang memungkinkan remote code execution dalam kondisi tertentu.

Remote code execution adalah kondisi ketika penyerang dapat menjalankan kode pada sistem target melalui jalur akses jarak jauh. Jika eksploitasi berhasil, dampaknya bergantung pada hak akses proses PHP, konfigurasi server, serta sumber daya dan sistem lain yang dapat dijangkau oleh proses tersebut.

Dua kerentanan yang termasuk dalam pembahasan PHP2Shell adalah:

• CVE-2026-109618: berkaitan dengan kerusakan memori dalam penanganan kondisi out of memory.

• CVE-2026-109619: berkaitan dengan status internal PHP yang masih merujuk pada memori request sebelumnya yang telah dibebaskan.

  
  

Keduanya memiliki penyebab teknis berbeda, tetapi sama-sama dapat membuka peluang remote code execution.

PHP digunakan untuk menjalankan berbagai aplikasi web, termasuk website berbasis WordPress dan aplikasi yang dibangun menggunakan framework PHP. Oleh sebab itu, pemeriksaan keamanan tidak boleh berhenti pada versi CMS, plugin, atau framework. Tim IT juga perlu mengetahui versi runtime PHP yang sebenarnya digunakan oleh server.

Dua Kerentanan PHP2Shell yang Perlu Dipahami

1. CVE-2026-109618: Remote Code Execution melalui Out-of-Memory Corruption

   CVE-2026-109618 berkaitan dengan penanganan kondisi out of memory (OOM), yaitu keadaan ketika proses PHP gagal memperoleh alokasi memori yang diperlukan.

   
   

   Dalam kondisi tertentu, kegagalan alokasi memori dapat menghentikan pemrosesan request ketika sebagian data internal PHP belum sepenuhnya diinisialisasi. Proses pembersihan request kemudian dapat memperlakukan data yang tidak valid tersebut seolah-olah masih valid.

   
   

   Menurut advisory resmi PHP, kondisi ini dapat menyebabkan kerusakan memori dan berujung pada remote code execution. Pada skenario tertentu, masalah terjadi ketika PHP masih memproses request, bahkan sebelum kode aplikasi mulai berjalan.

   
   

   Artinya, pembaruan kode aplikasi saja tidak cukup untuk memperbaiki kerentanan yang berada pada lapisan runtime PHP.

   
   

2. CVE-2026-109619: Remote Code Execution melalui Stale Global State

   CVE-2026-109619 berkaitan dengan stale global state, yaitu kondisi ketika status internal yang dipertahankan oleh worker PHP masih merujuk pada memori milik request sebelumnya yang telah dibebaskan.

   
   

   Status internal tersebut dapat mencakup informasi terkait error, session, objek, atau ekstensi. Dalam kondisi tertentu, suatu operasi dapat mengakses status yang sudah tidak valid sebelum proses inisialisasi normal request berikutnya selesai.

   
   

   Situasi ini dapat menimbulkan use-after-free, yakni penggunaan memori setelah memori tersebut dibebaskan. Dengan kondisi yang sesuai, masalah tersebut dapat dimanfaatkan untuk mencapai remote code execution.

   
   

   Fitur session upload progress merupakan salah satu jalur yang relevan dalam analisis kerentanan ini. Namun, advisory PHP menjelaskan masalah yang lebih luas pada pengelolaan status internal antarreques. Karena itu, menonaktifkan satu fitur saja tidak boleh dianggap sebagai penyelesaian menyeluruh.

Seberapa Serius Risiko PHP2Shell bagi Perusahaan?

Kedua kerentanan tersebut dinilai Critical karena berpotensi memungkinkan penyerang menjalankan kode pada server tanpa autentikasi. Meski demikian, tingkat keterpaparan dan jalur eksploitasi aktual bergantung pada lingkungan PHP, integrasi web server, konfigurasi, serta kondisi request yang dapat dijangkau penyerang.

Beberapa risiko bisnis yang perlu diperhitungkan meliputi:

1. Kompromi terhadap Server Aplikasi

   Jika eksploitasi berhasil, penyerang berpotensi menjalankan kode dengan hak akses proses PHP yang terdampak. Konsekuensinya dapat mencakup perubahan file yang tidak sah, gangguan layanan, atau akses ke sumber daya lain yang dapat dijangkau dari server tersebut.

2. Paparan Data dan Kredensial

   Server aplikasi dapat memiliki akses ke file konfigurasi, kredensial layanan, basis data, dan informasi pelanggan. Jika kontrol akses atau segmentasi jaringan tidak memadai, kompromi terhadap satu komponen dapat meningkatkan risiko terhadap aset lain.

3. Gangguan Operasional

   Aktivitas berbahaya dapat mengganggu proses aplikasi, memicu error, atau memerlukan isolasi sistem untuk investigasi dan pemulihan. Hal ini berpotensi memengaruhi ketersediaan layanan dan menambah beban operasional tim IT.

4. Dampak terhadap Bisnis dan Reputasi

   Insiden yang melibatkan website atau aplikasi perusahaan dapat menimbulkan biaya investigasi, pemulihan, serta komunikasi dengan pelanggan dan mitra bisnis. Dampak akhirnya bergantung pada sistem yang terkena dan data yang benar-benar terdampak.

Penting untuk membedakan antara sistem yang rentan dan sistem yang telah dikompromi. Adanya versi PHP yang rentan menunjukkan perlunya tindakan mitigasi, tetapi tidak otomatis membuktikan bahwa server telah berhasil diserang.

Versi PHP yang Terdampak dan Pembaruan Keamanan

Proyek PHP merilis pembaruan pada empat cabang versi yang masih menerima pembaruan keamanan reguler saat advisory diterbitkan.

Cabang PHP	Rentang versi terdampak menurut advisory upstream	Versi perbaikan
PHP 8.5	Di bawah 8.5.12	8.5.12
PHP 8.4	Di bawah 8.4.27	8.4.27
PHP 8.3	Di bawah 8.3.36	8.3.36
PHP 8.2	Di bawah 8.2.35	8.2.35

Tabel tersebut mengacu pada rilis upstream PHP. Untuk instalasi yang menggunakan distribusi Linux, paket hosting, atau layanan dengan dukungan jangka panjang, nomor versi yang terlihat tidak selalu cukup untuk menentukan status patch. Beberapa vendor dapat memasukkan perbaikan keamanan melalui backport ke paket yang mereka kelola.

Bagaimana dengan PHP 8.1 dan Versi yang Lebih Lama?

PHP menyatakan bahwa PHP 8.1 dan versi lebih lama tidak lagi menerima pembaruan keamanan reguler dari proyek PHP. Namun, sejumlah distribusi Linux dan penyedia layanan dengan dukungan jangka panjang dapat menyediakan perbaikan yang di-backport. PHP juga menyediakan minimal source backports untuk PHP 7.4, PHP 8.0, dan PHP 8.1.

Karena itu, organisasi yang menggunakan versi lama perlu memeriksa advisory vendor dan status paket aktual, bukan sekadar membandingkan nomor versinya dengan tabel di atas.

Untuk sistem yang tidak lagi memperoleh pembaruan keamanan, migrasi ke cabang PHP yang masih didukung perlu masuk ke dalam rencana pengelolaan risiko.

Catatan: PHP 8.2 dijadwalkan mencapai akhir masa dukungan pada 31 Desember 2026. Organisasi yang masih menggunakan PHP 8.2 perlu mempertimbangkan rencana migrasi, meskipun pembaruan keamanan PHP2Shell sudah diterapkan.

Cara Mengatasi PHP2Shell dan Mengurangi Risiko Keamanan

Penanganan PHP2Shell perlu dilakukan sebagai bagian dari pengelolaan kerentanan, bukan hanya sebagai respons terhadap satu pemberitaan keamanan.

1. Inventarisasi Sistem yang Menjalankan PHP

   Mulailah dengan mengidentifikasi server dan aplikasi yang menggunakan PHP. Inventaris sebaiknya mencakup website publik, portal pelanggan, aplikasi internal, subdomain, server pengujian, serta lingkungan produksi. Catat versi PHP, integrasi web server, lokasi hosting, pemilik sistem, dan status pembaruannya. Sistem yang dikelola oleh penyedia eksternal juga perlu dikonfirmasi status keamanannya kepada vendor.

   Jangan mengasumsikan bahwa seluruh aset menggunakan versi PHP yang sama.

2. Perbarui Runtime PHP ke Versi yang Telah Diperbaiki

   Prioritaskan sistem yang dapat diakses dari internet dan gunakan versi perbaikan resmi atau paket vendor yang telah mengintegrasikan patch terkait. Sebelum pembaruan, ikuti prosedur perubahan organisasi, periksa kompatibilitas aplikasi, dan siapkan proses pemulihan jika terjadi masalah operasional.

   
   

3. Pastikan Versi PHP yang Aktif pada Website

   Pemeriksaan dapat dimulai melalui panel hosting atau lingkungan server. Namun, versi PHP yang tampil dari terminal melalui perintah php -v dapat berbeda dari versi yang digunakan oleh website melalui PHP-FPM atau integrasi web server lainnya.

   
   

   Karena itu, pastikan bahwa runtime yang menangani request web telah menerima patch yang diperlukan. Jika menggunakan layanan hosting terkelola, mintalah konfirmasi mengenai versi atau paket PHP yang aktif dan perbaikan yang telah diterapkan.

   
   

4. Periksa Log dan Indikasi Aktivitas Tidak Normal

   Setelah memperbarui sistem, tinjau log web server, PHP, dan sistem operasi untuk mencari aktivitas yang tidak biasa.

   
   

   Pemeriksaan dapat mencakup error yang tidak lazim, kondisi kehabisan memori yang mencurigakan, aktivitas upload yang tidak biasa, perubahan file yang tidak terotorisasi, dan proses yang tidak dikenali.

   
   

   Tidak semua error membuktikan eksploitasi. Namun, indikator yang relevan perlu ditindaklanjuti melalui proses investigasi keamanan. Pembaruan runtime juga tidak otomatis menghilangkan kemungkinan kompromi yang terjadi sebelum patch diterapkan.

   
   

5. Gunakan Kontrol Keamanan Tambahan

   Kontrol seperti Web Application Firewall (WAF), pembatasan request, segmentasi jaringan, pengelolaan hak akses, pemantauan log, dan pencadangan dapat menjadi lapisan pertahanan tambahan.

   Kontrol tersebut membantu membatasi paparan atau dampak insiden, tetapi tidak menggantikan pembaruan runtime PHP.

   
   

   PHP juga menjelaskan beberapa konfigurasi sementara yang dapat mengurangi paparan terhadap jalur serangan tertentu apabila pembaruan langsung belum memungkinkan. Namun, langkah-langkah tersebut tidak menutup seluruh jalur eksploitasi dan harus diterapkan dengan mempertimbangkan lingkungan server serta dampak operasionalnya.

   
   

   Pembaruan ke versi yang telah diperbaiki tetap menjadi tindakan utama. Jika patch belum dapat diterapkan, tim keamanan perlu mengikuti advisory resmi dan mengevaluasi kontrol sementara secara terukur.

Kesimpulan: PHP2Shell Perlu Ditangani melalui Patch dan Pengelolaan Kerentanan

PHP2Shell menunjukkan bahwa keamanan aplikasi tidak berhenti pada pembaruan CMS, plugin, atau framework. Runtime dan komponen infrastruktur yang menopang aplikasi juga perlu dipantau dan diperbarui berdasarkan advisory keamanan yang relevan.

Organisasi sebaiknya memulai dengan menginventarisasi aset PHP, memprioritaskan sistem yang terekspos ke internet, menerapkan pembaruan keamanan yang sesuai, dan memastikan runtime yang benar-benar melayani request telah diperbaiki.

Jika menggunakan versi PHP lama, tim IT perlu memeriksa dukungan vendor dan merencanakan migrasi apabila sistem sudah tidak menerima pembaruan keamanan yang memadai. Pemantauan log dan proses respons insiden juga tetap diperlukan setelah patch diterapkan.

Netmarks Indonesia menyediakan informasi mengenai solusi cybersecurity dan infrastruktur TI untuk kebutuhan bisnis. Organisasi yang ingin mengevaluasi kebutuhan keamanan infrastrukturnya dapat mengunjungi website Netmarks Indonesia untuk mempelajari solusi yang tersedia.

Referensi Teknis

1. PHP.net — Security Advisory: Critical Remote Code Execution Vulnerabilities

2. GitHub Security Advisory — CVE-2026-109618

3. GitHub Security Advisory — CVE-2026-109619

4. Akamai — Understanding PHP2Shell: Everything You Need to Know

Artikel ini merangkum informasi yang tersedia pada 23 Oktober 2026. Periksa advisory resmi PHP dan vendor terkait untuk mengetahui pembaruan terbaru serta status patch pada sistem tertentu.