PHP2Shell: Penyebab, Dampak, dan Cara Mengamankan Server Website

PHP2Shell: Penyebab, Dampak, dan Cara Mengamankan Server Website

Ditulis oleh Dita Nur Sabila, Project Manager Officer (PMO) ASTACODE.

Keamanan website kembali menjadi perhatian setelah ditemukannya dua kerentanan kritis pada PHP, bahasa pemrograman yang banyak digunakan untuk membangun aplikasi dan layanan berbasis web. Kerentanan yang dikenal sebagai PHP2Shell ini dapat memungkinkan penyerang menjalankan kode dari jarak jauh tanpa autentikasi pada sistem yang rentan.

Masalah ini tidak terbatas pada satu framework atau aplikasi tertentu. Kerentanannya berada pada mesin inti atau runtime PHP, yaitu komponen yang bertugas menjalankan kode PHP di server. Karena itu, pengelola website yang menggunakan WordPress, Drupal, Joomla, Laravel, maupun aplikasi PHP lainnya perlu memeriksa versi runtime yang digunakan.

Pada 21 Oktober 2026, tim pengembang PHP merilis pembaruan keamanan untuk memperbaiki dua kerentanan utama tersebut. Berbagai perusahaan teknologi dan lembaga keamanan siber kemudian menerbitkan peringatan agar pengelola sistem segera memeriksa dan memperbarui instalasi PHP yang terdampak.

Artikel ini membahas penyebab PHP2Shell, alasan topik ini ramai dicari, dampak yang mungkin terjadi, respons pemerintah Jepang, serta langkah teknis untuk melindungi website dan server.

1. Mengapa PHP2Shell Trending Akhir-Akhir Ini?

PHP2Shell menjadi perhatian komunitas teknologi karena menggabungkan beberapa faktor penting: tingkat keparahan yang tinggi, potensi eksekusi kode tanpa login, laporan upaya eksploitasi, serta kebutuhan untuk segera memperbarui perangkat lunak yang terdampak.

Dalam tangkapan layar Google Trends Indonesia yang kamu pantau, sejumlah kueri terkait PHP muncul dalam daftar penelusuran populer untuk periode 24 jam terakhir, antara lain:

• PHP version: pencarian untuk mengetahui versi PHP yang digunakan.
• PHP update dan update PHP: pencarian mengenai pembaruan PHP.
• CVE PHP dan PHP CVE: pencarian terkait identitas dan informasi kerentanan keamanan.
• PHP security: pencarian seputar keamanan PHP.
• PHP vulnerabilities: pencarian mengenai kerentanan pada PHP.

Rangkaian kueri tersebut sejalan dengan kebutuhan developer, administrator server, dan pemilik website untuk mengetahui apakah sistem mereka terdampak, pembaruan apa yang perlu diterapkan, dan bagaimana cara mengurangi risiko serangan.

Namun, Google Trends menunjukkan minat penelusuran relatif, bukan jumlah pencarian absolut. Daftar tersebut juga tidak membuktikan bahwa setiap pencarian terjadi secara langsung akibat PHP2Shell. Data tersebut lebih tepat digunakan sebagai indikasi meningkatnya perhatian terhadap topik yang berkaitan dengan PHP.

Ada satu hal lain yang perlu diperhatikan. Kueri seperti PHP IDR dan PHP to IDR juga terlihat dalam tangkapan layar. Dalam konteks konversi mata uang, PHP merupakan kode mata uang peso Filipina, sedangkan IDR adalah rupiah Indonesia. Oleh karena itu, tidak semua kueri yang menggunakan istilah PHP merujuk pada bahasa pemrograman.

Peran AI dalam Penemuan PHP2Shell

Salah satu faktor yang membuat PHP2Shell mendapat perhatian luas adalah laporan penelitian Wiz Research. Tim tersebut menjelaskan bagaimana AI membantu peneliti menemukan kelemahan pada mesin inti PHP dan mengembangkan pembuktian eksploitasi yang sebelumnya memerlukan analisis teknis kompleks.

Menurut laporan Wiz Research tentang PHP2Shell yang diterbitkan pada 21 Oktober 2026, peneliti menggunakan sejumlah alat dan model AI, termasuk Wiz Atlas, Gemini 4 Argon, dan GPT-5.6 Sol dalam proses penelitian dan pengembangan eksploitasi.

Masalah dasarnya bukanlah AI, melainkan kelemahan dalam implementasi dan pengelolaan memori PHP. AI membantu peneliti menganalisis kode, menguji kemungkinan eksploitasi, serta mengembangkan pendekatan yang bekerja pada kondisi tertentu.

Penelitian ini menunjukkan bahwa AI dapat membantu menemukan kerentanan perangkat lunak yang telah lama ada. Pada saat yang sama, kemampuan tersebut juga menegaskan pentingnya proses pengungkapan kerentanan yang terkoordinasi, pembaruan keamanan, dan pemantauan sistem.

2. Apa Itu PHP2Shell?

PHP2Shell adalah sebutan untuk dua kerentanan kritis pada runtime PHP yang didaftarkan dengan identitas CVE-2026-109618 dan CVE-2026-109619. Berdasarkan analisis Wiz Research, kedua kerentanan tersebut memiliki skor keparahan hingga CVSS 9,2 dari 10.

CVE merupakan singkatan dari Common Vulnerabilities and Exposures, yaitu sistem identifikasi untuk kerentanan keamanan yang telah dicatat. Sementara itu, CVSS atau Common Vulnerability Scoring System digunakan untuk menggambarkan tingkat keparahan kerentanan berdasarkan karakteristik dan potensi dampaknya.

Kedua kerentanan PHP2Shell dapat membuka jalan bagi Remote Code Execution (RCE), yaitu kondisi ketika penyerang dapat menjalankan kode pada sistem dari jarak jauh tanpa harus terlebih dahulu melakukan autentikasi.

Apabila eksploitasi berhasil, penyerang berpotensi menjalankan tindakan sesuai hak akses proses PHP. Dampaknya dapat mencakup akses terhadap informasi sensitif, perubahan berkas yang dapat diakses proses, atau gangguan terhadap layanan website.

Kerentanan ini berbeda dari bug pada aplikasi biasa. Karena sumber masalah berada di runtime PHP, website dapat berisiko meskipun kode aplikasi yang berjalan di atasnya tidak memiliki celah yang sama.

Wiz Research mendemonstrasikan dampak eksploitasi pada sejumlah aplikasi berbasis PHP, termasuk WordPress, Drupal, dan Joomla. Demonstrasi tersebut tidak berarti semua instalasi aplikasi itu telah diretas. Artinya, kelemahan pada runtime dapat berdampak pada aplikasi berbeda yang menggunakan runtime rentan.

Referensi teknis: Wiz Research — PHP2Shell: AI Uncovers Critical RCE Vulnerabilities.

3. Penyebab PHP2Shell dan Cara Kerjanya

PHP2Shell bukanlah satu kesalahan sederhana. Istilah ini merujuk pada dua kerentanan yang berkaitan dengan penanganan kesalahan fatal dan pengelolaan memori dalam PHP. Untuk memahami risikonya, penting untuk mengetahui bagaimana proses internal PHP dapat mengalami keadaan yang tidak konsisten.

CVE-2026-109618: Kerusakan Memori Saat Terjadi Kehabisan Memori

Kerentanan pertama berkaitan dengan kondisi out of memory (OOM), yaitu saat proses tidak dapat memperoleh memori yang dibutuhkan untuk melanjutkan pekerjaan.

Dalam kondisi tertentu, kegagalan alokasi memori dapat menghentikan pemrosesan permintaan ketika sebagian data internal PHP belum terbentuk secara lengkap. Ketika PHP kemudian membersihkan data setelah kegagalan tersebut, mekanisme internal tertentu berpotensi memperlakukan data yang tidak valid seolah-olah masih sah.

Kondisi ini dapat menimbulkan korupsi memori. Pada jalur eksploitasi yang telah didemonstrasikan peneliti, kelemahan tersebut dapat digunakan untuk membaca memori proses PHP atau mengembangkan serangan hingga eksekusi kode dari jarak jauh.

Masalahnya bukan semata-mata karena server memiliki RAM yang kecil. Akar persoalannya adalah bagaimana PHP menangani kegagalan tertentu ketika data internal permintaan belum sepenuhnya diinisialisasi.

CVE-2026-109619: Keadaan Internal yang Mengacu pada Memori Lama

Kerentanan kedua berhubungan dengan keadaan internal PHP yang dapat mempertahankan referensi ke memori yang sudah dibebaskan. Dalam pengelolaan memori, sebuah referensi tidak seharusnya digunakan setelah memori yang dirujuk tidak lagi berlaku.

Pada kondisi kerentanan ini, kesalahan fatal dapat mengganggu proses pembersihan dan meninggalkan referensi internal yang tidak lagi valid. Jika worker PHP yang sama menangani permintaan berikutnya sebelum keadaan tersebut diinisialisasi ulang dengan benar, referensi lama berpotensi digunakan kembali.

Kondisi tersebut dikenal sebagai use-after-free. Ketika digabungkan dengan perilaku pengelolaan memori lainnya, kondisi ini dapat menyebabkan korupsi memori atau memungkinkan eksekusi kode dalam situasi yang memenuhi persyaratan eksploitasi.

Mengapa Kerentanan pada Runtime Bisa Berdampak Luas?

PHP digunakan untuk menjalankan banyak aplikasi web. Karena kelemahan utama berada pada runtime, dampaknya tidak selalu bergantung pada framework atau CMS tertentu.

PHP.net menyebut instalasi PHP yang melayani permintaan web sebagai lingkungan yang perlu diperiksa, termasuk PHP-FPM, Apache dengan mod_php, php-CGI, FrankenPHP, dan LiteSpeed. Risiko dapat berbeda berdasarkan konfigurasi, tetapi tidak tepat untuk menganggap suatu instalasi aman hanya karena aplikasi webnya tidak menggunakan framework yang disebut dalam laporan eksploitasi.

Dalam panduan resminya, PHP menilai risiko paling tinggi pada konfigurasi Apache mod_php karena eksploitasi yang didemonstrasikan dapat dipicu sebelum kode aplikasi berjalan.

Sumber:

• PHP.net — Peringatan keamanan dan detail kerentanan
• Wiz Research — Analisis teknis PHP2Shell

4. Dampak PHP2Shell terhadap Website dan Server

Dampak PHP2Shell tidak selalu sama pada setiap sistem. Keberhasilan eksploitasi bergantung pada versi PHP, konfigurasi server, jalur kode yang dapat dicapai, serta hak akses proses yang berhasil disalahgunakan. Berikut beberapa risiko yang perlu dipahami oleh pengelola website.

Eksekusi Kode Tanpa Autentikasi

Jika eksploitasi berhasil, penyerang dapat menjalankan kode dengan hak akses proses PHP. Hal ini berpotensi membuka jalan bagi tindakan yang tidak diizinkan, tergantung pada konfigurasi dan batasan keamanan yang diterapkan pada server.

Kebocoran Informasi Sensitif

Penelitian Wiz juga mendemonstrasikan kemungkinan membaca informasi dari memori proses PHP. Bergantung pada data yang berada di memori, informasi sensitif seperti kata sandi, token autentikasi, API key, atau data lain yang sedang diproses berpotensi terpapar.

Informasi tersebut dapat memiliki nilai tinggi karena mungkin digunakan untuk mencoba memperoleh akses ke aplikasi atau layanan lain. Namun, jenis data yang terekspos akan bergantung pada kondisi proses dan sistem yang terdampak.

Perubahan Berkas dan Gangguan Website

Jika proses PHP memiliki izin menulis ke direktori aplikasi, penyerang yang berhasil menjalankan kode dapat berpotensi mengubah berkas yang dapat diakses proses tersebut. Dampaknya dapat berupa perubahan tampilan website, penanaman berkas berbahaya, atau gangguan terhadap jalannya aplikasi.

Pengambilalihan seluruh server tidak otomatis terjadi dalam setiap eksploitasi. Dampak akhirnya dipengaruhi oleh hak akses proses PHP, pembatasan sistem operasi, isolasi layanan, dan konfigurasi keamanan lainnya.

Gangguan Ketersediaan Layanan

Kesalahan memori juga dapat menyebabkan proses PHP gagal atau berhenti bekerja. Jika kondisi ini terjadi berulang kali, pengguna bisa mengalami error atau website menjadi tidak tersedia.

Penting: semua dampak tersebut merupakan potensi akibat eksploitasi yang berhasil. Ditemukannya kerentanan atau adanya percobaan serangan tidak otomatis membuktikan bahwa setiap server PHP telah diretas.

5. Laporan Upaya Eksploitasi PHP2Shell

Kasus PHP2Shell menjadi semakin mendesak karena terdapat laporan upaya eksploitasi sebelum pengungkapan publik dilakukan.

Dalam laporan yang diterbitkan pada 21 Oktober 2026, Amazon Threat Intelligence menyebut bahwa mereka menemukan upaya penargetan PHP2Shell pada 17 Oktober 2026, empat hari sebelum kerentanan diumumkan secara publik. Aktivitas tersebut terdeteksi melalui telemetri sistem honeypot MadPot milik Amazon.

Amazon juga melaporkan ditemukannya sejumlah proof of concept eksploitasi pada hari pengungkapan. Meski demikian, pihaknya menyatakan belum dapat memastikan bagaimana pelaku memperoleh informasi eksploitasi sebelum pengumuman publik.

Laporan tersebut memperlihatkan bahwa aktivitas penargetan tidak hanya bersifat teoritis. Namun, penting membedakan antara upaya eksploitasi dan bukti keberhasilan menembus sistem. Organisasi perlu memeriksa log dan indikator kompromi untuk menentukan apakah server mereka benar-benar terdampak.

Sumber: Amazon Threat Intelligence — PHP2Shell Exploitation Prior to Public Disclosure.

6. Respons Pemerintah Jepang Menurut Nippon.com

Perhatian terhadap PHP2Shell juga mencapai pemerintah Jepang. Dalam artikel yang diterbitkan pada 22 Oktober 2026, Nippon.com melaporkan bahwa pemerintah Jepang berulang kali mengimbau pengguna PHP untuk melakukan tindakan pencegahan setelah ditemukannya kerentanan kritis pada bahasa pemrograman tersebut.

Menurut laporan Jiji Press yang dimuat Nippon.com, Perdana Menteri Jepang Sanae Takaichi menyampaikan permintaan mendesak melalui akun X pada malam 21 Oktober. Ia meminta pengelola website yang menggunakan PHP untuk segera memasang patch keamanan.

Takaichi juga menyampaikan bahwa penghentian sementara website dapat menjadi langkah efektif apabila pembaruan sulit diterapkan. Dalam unggahan berikutnya pada 22 Oktober, ia mengatakan bahwa akses ke website miliknya sendiri telah diblokir sementara dan kembali menekankan pentingnya mempertimbangkan penangguhan akses.

Langkah tersebut menunjukkan bahwa pemerintah Jepang memandang kerentanan ini sebagai persoalan yang perlu ditangani dengan cepat. Keterlambatan penanganan kerentanan kritis berpotensi berdampak pada layanan digital, organisasi, dan masyarakat, terutama ketika sistem yang terpapar mengelola informasi penting.

Namun, berita tersebut tidak menyatakan bahwa semua website di Jepang telah diretas. Pemblokiran sementara pada website perdana menteri juga tidak membuktikan bahwa website tersebut telah berhasil ditembus. Fokus pemberitaannya adalah imbauan untuk melakukan patch dan membatasi akses jika perbaikan belum dapat diterapkan.

Pelajaran yang dapat diambil oleh pengelola website adalah bahwa keamanan harus dipertimbangkan sebagai bagian dari pengelolaan risiko operasional. Jika sistem yang rentan tidak dapat diperbarui dan mitigasi yang memadai belum tersedia, membatasi akses dari internet atau menangguhkan website sementara dapat menjadi pilihan yang masuk akal.

Sumber: Nippon.com — Japan Govt Issues Rare Calls over PHP Flaw, 22 Oktober 2026.

7. Versi PHP dan Pembaruan Keamanan

Pada 21 Oktober 2026, tim pengembang PHP merilis pembaruan keamanan untuk memperbaiki CVE-2026-109618 dan CVE-2026-109619. Versi perbaikan awal yang diumumkan adalah sebagai berikut.

Angka di atas merupakan versi perbaikan yang diumumkan pada 21 Oktober, bukan jaminan bahwa versi tersebut akan selalu menjadi versi terbaru. Sebelum melakukan pembaruan, periksa apakah sudah tersedia rilis patch yang lebih baru untuk cabang PHP yang digunakan.

PHP 8.1 dan versi yang lebih lama sudah tidak lagi menerima pembaruan rutin langsung dari proyek inti PHP. Akan tetapi, sejumlah vendor sistem operasi dan penyedia dukungan jangka panjang dapat menyediakan perbaikan yang di-backport ke paket lama. Pengelola sistem perlu memeriksa status patch dari vendor atau meningkatkan versi PHP ke cabang yang masih didukung.

Jika menggunakan layanan hosting terkelola, tanyakan kepada penyedia apakah paket PHP yang menjalankan website telah menerima perbaikan terkait. Jangan hanya mengandalkan angka versi yang terlihat tanpa memeriksa asal paket dan status patch-nya.

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

8. Cara Mengatasi PHP2Shell dan Melindungi Server

Penanganan PHP2Shell sebaiknya dilakukan secara berurutan: identifikasi runtime yang digunakan, terapkan pembaruan resmi, verifikasi bahwa perbaikan telah aktif, dan periksa indikasi kompromi jika diperlukan.

1. Periksa Versi PHP yang Aktif

Langkah pertama adalah menginventarisasi seluruh sistem yang menjalankan PHP, terutama layanan yang dapat diakses dari internet.

Jika memiliki akses terminal, jalankan perintah berikut untuk memeriksa versi PHP pada lingkungan command line:

php -v

Untuk melihat berkas konfigurasi yang digunakan oleh PHP CLI, jalankan:

php --ini

Perlu diperhatikan bahwa hasil perintah tersebut tidak selalu menunjukkan runtime yang digunakan oleh website. Server dapat menjalankan beberapa versi PHP sekaligus, PHP-FPM, container, atau konfigurasi hosting yang berbeda dari CLI.

Karena itu, periksa juga panel hosting, konfigurasi web server, service PHP-FPM, atau tanyakan langsung kepada penyedia hosting. Pastikan pemeriksaan mencakup runtime produksi yang benar-benar menerima permintaan website.

2. Terapkan Patch Keamanan Resmi

Perbarui PHP ke versi perbaikan yang sesuai dengan cabang yang digunakan atau rilis patch lebih baru yang telah tersedia dan didukung. Jika PHP dikelola oleh sistem operasi atau layanan hosting, gunakan paket resmi yang telah memasukkan perbaikan keamanan.

Sebelum memperbarui server produksi, lakukan pencadangan dan uji kompatibilitas jika kondisi operasional memungkinkan. Setelah pembaruan, restart atau muat ulang layanan terkait jika diperlukan agar proses PHP menggunakan binary dan konfigurasi yang sudah diperbarui.

Sesudahnya, verifikasi kembali versi runtime yang melayani website dan pastikan aplikasi berjalan normal. Nama perintah untuk memperbarui paket dan merestart layanan dapat berbeda pada setiap distribusi Linux, penyedia hosting, atau lingkungan deployment.

3. Jangan Hanya Memperbarui Laravel atau WordPress

Pembaruan aplikasi berbeda dari pembaruan runtime PHP. Memperbarui Laravel, WordPress, plugin, tema, atau dependency Composer tidak otomatis memperbarui mesin PHP yang menjalankan aplikasi.

Jika runtime server masih menggunakan versi yang rentan, masalah pada tingkat PHP belum tentu terselesaikan. Sebaliknya, memperbarui PHP juga tidak menggantikan kebutuhan untuk memelihara aplikasi, plugin, dependency, dan sistem operasi.

Karena itu, pemeriksaan keamanan harus mencakup setiap lapisan yang digunakan oleh website.

4. Terapkan Mitigasi Sementara dengan Hati-Hati

Jika patch belum dapat diterapkan segera, pengelola sistem dapat mempertimbangkan mitigasi sementara berdasarkan panduan resmi PHP. Langkah ini harus dilakukan oleh administrator yang memahami konfigurasi dan kebutuhan aplikasi karena beberapa pengaturan dapat memengaruhi fungsi website atau ketersediaan layanan.

PHP menyebut beberapa tindakan untuk mengurangi paparan terhadap jalur eksploitasi tertentu, antara lain:

• Meninjau batas ukuran request dan unggahan melalui konfigurasi PHP, web server, atau reverse proxy.
• Menyesuaikan post_max_size dan upload_max_filesize sesuai kebutuhan aplikasi, tanpa mengabaikan kebutuhan unggahan berkas yang sah.
• Mempertimbangkan pengaturan session.upload_progress.enabled=0 dan melakukan restart seluruh worker yang relevan sesuai panduan resmi.
• Pada PHP 8.5, mempertimbangkan fatal_error_backtraces=0 untuk memblokir jalur backtrace tertentu sebagaimana dijelaskan PHP.
• Membatasi akses publik sementara jika sistem tetap berisiko dan patch tidak dapat diterapkan.

Pengaturan ini bukan pengganti patch dan tidak membuat seluruh instalasi yang rentan menjadi aman. PHP secara eksplisit menyatakan bahwa pembaruan merupakan solusi lengkap untuk dua kerentanan utama tersebut, sedangkan mitigasi hanya mengurangi paparan terhadap jalur tertentu.

Penting: jangan menyalin perubahan konfigurasi ke server produksi tanpa memahami dampaknya. Rujuk panduan resmi PHP untuk rincian, batasan, dan langkah verifikasi.

5. Batasi Hak Akses Proses PHP

Jalankan PHP dengan hak minimum yang diperlukan oleh aplikasi. Hindari menjalankan seluruh proses aplikasi menggunakan akun administrator atau root apabila tidak diperlukan.

Pastikan pula bahwa aplikasi hanya dapat menulis ke direktori yang memang diperlukan, kredensial disimpan dengan aman, dan layanan dipisahkan sesuai kebutuhan. Pembatasan hak akses tidak menghilangkan kerentanan PHP2Shell, tetapi dapat membatasi dampak jika sebuah proses berhasil disalahgunakan.

6. Periksa Indikasi Kompromi

Jika terdapat aktivitas yang mencurigakan, jangan berhenti hanya setelah melakukan pembaruan. Periksa log, perubahan berkas, proses yang tidak dikenal, koneksi jaringan keluar, serta penggunaan sumber daya yang tidak biasa.

Jika ditemukan indikasi bahwa server telah berhasil dieksploitasi, pertimbangkan pembatasan akses sementara, penyimpanan bukti untuk investigasi, penggantian kredensial atau token yang mungkin terpapar, serta pemulihan sistem dari kondisi yang diketahui bersih.

Pembaharuan PHP mencegah jalur eksploitasi yang telah diperbaiki, tetapi tidak otomatis menghapus artefak yang mungkin sudah ditanam pada sistem sebelum patch diterapkan.

9. Mitigasi Tambahan: Perhatikan CVE-2026-115560

Setelah pembaruan keamanan utama diumumkan pada 21 Oktober, PHP menerbitkan imbauan tambahan pada 23 Oktober 2026 mengenai kerentanan lain, yaitu CVE-2026-115560. Isu ini merupakan jalur RCE terpisah yang berkaitan dengan konfigurasi khusus fitur session upload progress.

Menurut arsip pengumuman resmi PHP, kondisi tersebut hanya dapat terjadi pada kombinasi konfigurasi dan perilaku aplikasi yang tidak umum. Aplikasi harus mengatur session.serialize_handler ke php_binary atau php_serialize, kemudian menggantinya saat runtime menjadi php melalui ini_set() sebelum memanggil session_start(), sementara fitur session upload progress tetap aktif.

PHP menyarankan agar session.upload_progress.enabled=0 diterapkan sampai rilis perbaikan rutin berikutnya untuk mengurangi risiko jalur ini. Jika pengaturan tersebut sudah diterapkan sebagai mitigasi pada CVE-2026-109619, PHP menyatakan bahwa pengaturan itu perlu dipertahankan.

Hal ini perlu dibedakan dari dua kerentanan utama PHP2Shell. Patch pada 21 Oktober memperbaiki CVE-2026-109618 dan CVE-2026-109619. Imbauan 23 Oktober membahas jalur tambahan yang membutuhkan kondisi konfigurasi tertentu.

Jangan menganggap perubahan konfigurasi tersebut sebagai pengganti update keamanan. Pastikan mengikuti panduan PHP dan memeriksa rilis patch terbaru sebelum memutuskan bahwa sistem sudah sepenuhnya terlindungi.

Sumber: PHP.net — Informational Advisory: Session Upload Progress, 23 Oktober 2026.

10. Cara Memeriksa Indikasi Serangan PHP2Shell

Memeriksa apakah server menggunakan PHP rentan merupakan langkah awal, tetapi pemeriksaan versi saja tidak menjawab apakah eksploitasi pernah berhasil. Jika server dapat diakses dari internet selama periode paparan, pengelola perlu mempertimbangkan pemeriksaan log dan integritas sistem.

Beberapa hal yang dapat diperiksa antara lain:

• Permintaan HTTP multipart atau aktivitas unggahan yang tidak biasa, termasuk pola yang berkaitan dengan session upload progress.
• Error PHP yang berulang, respons HTTP 500, atau worker yang berhenti dan dimulai ulang secara tidak wajar.
• Proses baru yang tidak dikenal atau proses PHP yang menjalankan perintah di luar pola normal aplikasi.
• Perubahan berkas aplikasi, file konfigurasi, file unggahan, atau tugas terjadwal yang tidak dapat dijelaskan.
• Koneksi jaringan keluar yang tidak sesuai dengan fungsi normal aplikasi.

Amazon Threat Intelligence merekomendasikan pemeriksaan aktivitas yang berkaitan dengan eksploitasi, termasuk permintaan POST tertentu, log web server, eksekusi proses, dan perubahan berkas aplikasi. Lihat laporan Amazon Threat Intelligence untuk konteks dan indikator yang dilaporkan.

Indikator tunggal tidak selalu membuktikan adanya serangan. Sebuah alamat IP, misalnya, bisa merupakan bagian dari infrastruktur bersama dan tidak selalu eksklusif digunakan oleh pelaku. Korelasikan temuan dengan waktu, permintaan, proses, dan bukti lain sebelum mengambil keputusan.

Jika ditemukan indikasi kompromi, tangani sebagai insiden keamanan, bukan sekadar masalah pembaruan perangkat lunak. Untuk sistem yang menangani informasi pelanggan atau layanan penting, libatkan tenaga keamanan siber yang berpengalaman.

11. Pertanyaan yang Sering Diajukan tentang PHP2Shell

Apakah semua website berbasis PHP sudah diretas?

Tidak. Kerentanan kritis tidak berarti semua website telah berhasil ditembus. Terdapat laporan upaya eksploitasi, tetapi kondisi setiap sistem harus diperiksa untuk menentukan apakah ada indikasi kompromi.

Apakah Laravel dan WordPress terdampak?

Laravel dan WordPress yang berjalan pada runtime PHP rentan perlu diperiksa. Karena masalah utama berada pada runtime, memperbarui framework, CMS, plugin, atau tema saja tidak otomatis memperbaiki kerentanan tersebut.

Apakah cukup mengubah konfigurasi tanpa memperbarui PHP?

Tidak. Mitigasi konfigurasi dapat mengurangi paparan terhadap jalur eksploitasi tertentu, tetapi PHP menyatakan bahwa pembaruan merupakan solusi lengkap untuk dua kerentanan utama. Mitigasi harus diperlakukan sebagai langkah sementara apabila patch belum dapat diterapkan.

Bagaimana jika website menggunakan PHP versi lama?

Periksa apakah vendor sistem operasi atau penyedia hosting menyediakan paket yang sudah menerima patch keamanan. Jika perbaikan tidak tersedia atau tidak dapat diverifikasi, prioritaskan peningkatan ke cabang PHP yang masih didukung.

Apakah website harus langsung dimatikan?

Tidak selalu. Keputusan bergantung pada tingkat paparan, kepentingan layanan, serta kemampuan menerapkan patch dan mitigasi. Namun, jika sistem yang rentan tidak dapat diamankan secara memadai, pembatasan akses atau penghentian sementara dapat menjadi pilihan untuk mengurangi risiko.

Apakah mengganti password sudah cukup?

Tidak. Mengganti password dapat menjadi langkah yang tepat apabila kredensial berpotensi terpapar, tetapi tindakan itu tidak memperbaiki kerentanan PHP. Pengelola tetap perlu menerapkan patch, memeriksa indikasi kompromi, dan mengganti token atau kredensial lain yang mungkin terdampak.

12. Kesimpulan

PHP2Shell menjadi pengingat bahwa keamanan website tidak hanya bergantung pada kode aplikasi. Kerentanan pada runtime dapat memengaruhi banyak aplikasi sekaligus, termasuk website yang menggunakan framework atau CMS populer.

Kasus ini mendapat perhatian luas karena tingkat keparahan yang tinggi, laporan upaya eksploitasi, penelitian yang memanfaatkan AI, serta peringatan kepada pengelola website di berbagai negara. Respons pemerintah Jepang yang diberitakan Nippon.com juga menunjukkan bahwa penanganan kerentanan perlu menjadi bagian penting dari pengelolaan risiko layanan digital.

Bagi pengelola website, prioritas utamanya adalah mengidentifikasi runtime PHP yang digunakan, menerapkan pembaruan resmi, memverifikasi bahwa patch benar-benar aktif, dan memeriksa indikasi kompromi jika diperlukan. Mitigasi tambahan dapat mengurangi paparan sementara, tetapi tidak menggantikan perbaikan keamanan.

Keamanan website perlu dijaga secara berkelanjutan melalui pembaruan perangkat lunak, pemantauan sistem, pembatasan hak akses, serta perencanaan pemulihan yang baik.

Untuk diskusi mengenai pengembangan dan pemeliharaan sistem web, kunjungi ASTACODE atau hubungi tim melalui halaman kontak ASTACODE.

13. Referensi dan Sumber Berita

Artikel ini disusun berdasarkan pengumuman resmi pengembang PHP, analisis peneliti keamanan siber, serta pemberitaan media. Gunakan sumber berikut untuk membaca konteks dan pembaruan lebih lanjut.

1. PHP.net — Security Advisory: Critical Remote Code Execution Vulnerabilities. Pengumuman patch, versi perbaikan, penyebab, dan mitigasi untuk CVE-2026-109618 serta CVE-2026-109619.
2. PHP.net — News Archive 2026. Termasuk imbauan tambahan mengenai session upload progress pada 23 Oktober 2026.
3. Wiz Research — PHP2Shell: AI Uncovers Critical RCE Vulnerabilities Affecting 70% of the Internet. Analisis teknis, dampak, serta peran AI dalam penelitian kerentanan.
4. Amazon Threat Intelligence — PHP2Shell Exploitation Prior to Public Disclosure. Laporan upaya eksploitasi yang terdeteksi sebelum pengungkapan publik.
5. Nippon.com — Japan Govt Issues Rare Calls over PHP Flaw. Pemberitaan mengenai imbauan pemerintah Jepang dan tindakan sementara pada website perdana menteri.
6. Cyber Security Agency of Singapore — Critical Vulnerabilities in PHP. Informasi risiko serta rekomendasi penanganan kerentanan PHP.
7. NCSC-NL — Operational Information Regarding PHP2Shell. Informasi operasional mengenai kerentanan dan status perangkat lunak.

Catatan: informasi versi dan rekomendasi di atas merujuk pada pengumuman yang tersedia hingga 26 Oktober 2026. Periksa kembali dokumentasi resmi PHP dan vendor server sebelum melakukan perubahan pada lingkungan produksi.