PHP2Shell: Celah yang Bertahan Lebih dari Satu Dekade, Ditemukan dengan Bantuan AI
Bagaimana jika sebuah website memiliki kode aplikasi yang baik, tetapi tetap bisa diretas karena kelemahan pada mesin yang menjalankannya?
Pada 21 Oktober 2026, tim keamanan PHP mengumumkan dua kerentanan kritis yang dikenal sebagai PHP2Shell. Keduanya berpotensi memungkinkan penyerang menjalankan kode dari jarak jauh tanpa autentikasi pada sistem yang terdampak.
Yang membuat kasus ini menarik bukan hanya tingkat keparahannya. Menurut Wiz Research, kode rentan tersebut telah berada di dalam PHP selama lebih dari satu dekade. Penelitian pada 2026 kemudian menunjukkan bagaimana kelemahan yang lama tersembunyi dapat dikembangkan menjadi eksploitasi nyata dengan bantuan kecerdasan buatan atau artificial intelligence (AI).
Kasus ini menghadirkan tiga pertanyaan penting: bagaimana kerentanan tersebut bekerja, mengapa baru ditemukan sekarang, dan apa yang harus dilakukan oleh developer serta pengelola server?
1. Dua CVE, satu masalah besar pada fondasi PHP
PHP2Shell merupakan sebutan untuk dua kerentanan pada inti PHP, bukan nama satu CVE tunggal.
Keduanya didokumentasikan sebagai berikut:
| Identitas | Jenis kerentanan | Risiko utama |
|---|---|---|
| CVE-2026-109618 | Out-of-memory (OOM) corruption | Kondisi kehabisan memori dapat menyebabkan kerusakan keadaan internal PHP. |
| CVE-2026-109619 | Use-after-free / stale global state | Data yang telah dibebaskan masih dapat dirujuk atau digunakan kembali dalam kondisi tertentu. |
Kedua kerentanan diberi skor CVSS v4.0 sebesar 9,2 dari 10, dalam kategori kritis. Jika berhasil dieksploitasi, penyerang berpotensi menjalankan kode dengan hak akses proses PHP, membaca data sensitif, atau mengambil tindakan lain pada server yang terdampak.
Referensi teknis:
Hal yang perlu digarisbawahi adalah lokasi masalahnya. Kerentanan ini berada pada runtime PHP, bukan semata-mata pada kode aplikasi yang ditulis menggunakan PHP.
Artinya, memperbaiki validasi formulir atau menghapus query SQL yang tidak aman tidak otomatis mengatasi kerentanan pada mesin PHP itu sendiri.
2. Bagaimana bug yang lama bisa bertahan lebih dari 10 tahun?
Menurut analisis Wiz Research, kelemahan yang mendasari temuan PHP2Shell telah ada selama lebih dari satu dekade.
Namun, ada perbedaan antara usia kode rentan, tanggal bug ditemukan, tanggal dilaporkan, dan tanggal perbaikan diterbitkan. Keempatnya bukan peristiwa yang sama.
Bug yang sudah lama berada di dalam perangkat lunak tidak otomatis mudah ditemukan. Sebagian kelemahan baru terlihat ketika sejumlah kondisi internal terjadi secara berurutan, misalnya ketika permintaan HTTP diproses, memori habis, dan PHP harus membersihkan keadaan internal yang tidak lagi lengkap.
Bayangkan sebuah gudang yang menyimpan barang dengan nomor rak. Ketika sebuah rak dikosongkan, catatan seharusnya ikut diperbarui. Jika catatan lama masih menunjuk ke rak yang sudah digunakan untuk barang lain, program dapat membaca atau mengubah data yang keliru.
Analogi ini mendekati konsep use-after-free: program menggunakan referensi memori setelah memori tersebut dibebaskan.
Pada kasus OOM, situasinya berbeda tetapi berkaitan. Program menghadapi kondisi kehabisan memori ketika data internal mungkin belum selesai dibentuk. Jika penanganan kesalahan tidak aman, keadaan internal dapat menjadi tidak konsisten.
Dua hal tersebut merupakan kelas bug yang dikenal dalam rekayasa perangkat lunak. Yang membuatnya berbahaya adalah kemungkinan bahwa penyerang dapat mengendalikan kondisi pemicunya melalui permintaan dari jaringan.
Pelajaran pentingnya: kode yang telah digunakan bertahun-tahun belum tentu bebas dari kelemahan. Lama beroperasi bukanlah bukti bahwa sebuah sistem sudah aman.
3. Kronologi: dari penemuan hingga patch
Salah satu bagian paling menarik dari PHP2Shell adalah proses penelitiannya.
Berikut kronologi yang dilaporkan Wiz Research:
| Tanggal | Peristiwa |
|---|---|
| 19 Agustus 2026 | Wiz Research menemukan kerentanan pertama dalam investigasinya dengan bantuan alat AI. |
| 20 Agustus 2026 | Kemungkinan RCE tanpa autentikasi dikonfirmasi pada Drupal. |
| 21 Agustus 2026 | RCE tanpa autentikasi dikonfirmasi pada WordPress. |
| 24 Agustus 2026 | Wiz melaporkan temuan kepada tim keamanan PHP. |
| 21 September 2026 | PHP mulai mengembangkan perbaikan terkoordinasi setelah laporan tersebut diakui. |
| 17 Oktober 2026 | AWS mendeteksi percobaan eksploitasi yang tercatat sebelum pengungkapan publik. |
| 21 Oktober 2026 | Patch dirilis dan kerentanan diumumkan kepada publik. |
Sumber: Wiz Research dan AWS Security Blog.
Ada dua interval waktu yang perlu dibedakan.
Pertama, sekitar 63 hari antara penemuan pertama oleh Wiz pada 19 Agustus dan publikasi patch pada 21 Oktober 2026.
Kedua, terdapat sekitar empat hari antara percobaan eksploitasi yang tercatat oleh AWS pada 17 Oktober dan pengungkapan publik pada 21 Oktober.
Catatan AWS tersebut berasal dari telemetri MadPot, sistem honeypot yang digunakan untuk mengamati aktivitas penyerang. AWS menyebut bahwa sumber aktivitas menggunakan alamat IP yang terkait dengan jaringan anonimisasi komersial.
Akan tetapi, AWS juga menjelaskan bahwa belum jelas apakah percobaan tersebut akan berhasil pada sistem nyata. Karena itu, fakta ini sebaiknya ditulis sebagai bukti percobaan eksploitasi sebelum pengungkapan, bukan bukti bahwa server korban telah berhasil diretas.
4. Peran AI: dari membaca kode hingga menemukan jalur eksploitasi
PHP2Shell juga menjadi contoh bagaimana AI mulai mengubah penelitian keamanan perangkat lunak.
Menurut Wiz, proses penemuan memanfaatkan Wiz Atlas, Gemini 4 Argon, dan GPT-5.6 Sol. AI membantu peneliti memahami kode, mengeksplorasi kemungkinan kelemahan, dan mengembangkan serta memvalidasi jalur eksploitasi.
Wiz menyatakan bahwa satu peneliti dapat menyelesaikan pekerjaan dalam waktu sekitar satu minggu yang sebelumnya berpotensi membutuhkan tim ahli berpengalaman selama berbulan-bulan.
Angka tersebut merupakan klaim dari pihak yang melakukan penelitian, bukan hasil eksperimen universal yang membuktikan bahwa semua penemuan bug kini dapat dipercepat dengan rasio yang sama.
Meski demikian, implikasinya penting.
Secara tradisional, peneliti keamanan perlu memahami arsitektur program, membaca kode sumber, menemukan kondisi yang tidak biasa, lalu membangun pengujian untuk membuktikan bahwa kondisi tersebut benar-benar berbahaya.
AI dapat membantu mempercepat beberapa tahap itu. Namun, penemuan yang valid tetap memerlukan verifikasi teknis, pengujian yang dapat direproduksi, pemahaman terhadap konteks program, dan koordinasi pengungkapan yang bertanggung jawab.
AI juga memiliki dua sisi. Kemampuan yang membantu peneliti menemukan dan memperbaiki bug dapat membantu pihak lain memahami cara mengeksploitasinya.
Karena itu, pelajaran PHP2Shell bukan bahwa AI otomatis meretas semua perangkat lunak, melainkan bahwa biaya dan waktu untuk menemukan kelemahan yang kompleks dapat berubah. Tim pengembang dan pengelola sistem perlu menyesuaikan proses keamanan mereka dengan perubahan tersebut.
5. Apakah PHP2Shell mengancam 70% internet?
Wiz menggunakan angka sekitar 70% internet dalam menggambarkan besarnya jangkauan ekosistem PHP.
Angka tersebut perlu dibaca dengan hati-hati. PHP memang digunakan secara luas untuk aplikasi web, tetapi persentase penggunaan PHP tidak sama dengan persentase seluruh website yang pasti rentan atau berhasil diretas.
Untuk menentukan risiko sebuah sistem, kita perlu mengetahui beberapa hal:
- Versi PHP yang digunakan.
- Apakah versi tersebut termasuk versi yang terdampak.
- Apakah konfigurasi dan jalur pemrosesannya memungkinkan eksploitasi.
- Apakah patch telah diterapkan.
- Apakah terdapat bukti aktivitas mencurigakan atau kompromi.
PHP2Shell menunjukkan bahwa kelemahan pada komponen yang digunakan secara luas dapat memiliki dampak potensial yang besar. Namun, klaim bahwa 70% website pasti dapat diretas oleh PHP2Shell akan melampaui bukti yang tersedia.
Perbedaan ini penting, khususnya bagi pembaca yang mengelola layanan produksi. Informasi keamanan seharusnya membantu mereka mengambil tindakan yang tepat, bukan hanya meningkatkan rasa takut.
6. Apakah Laravel dan WordPress ikut terdampak?
Laravel adalah framework aplikasi yang berjalan di atas PHP. WordPress dan Drupal juga menggunakan PHP sebagai bagian penting dari runtime mereka.
Karena itu, aplikasi berbasis framework atau CMS tidak otomatis terlindungi dari bug yang berada pada mesin PHP.
Jika sebuah aplikasi Laravel berjalan menggunakan versi PHP yang rentan, memperbarui Laravel saja tidak cukup untuk memperbaiki kerentanan di runtime tersebut. Pengelola tetap perlu memperbarui PHP atau menerapkan perbaikan vendor yang telah diverifikasi.
Hal serupa berlaku untuk WordPress dan Drupal. Memperbarui plugin atau tema tidak menggantikan kebutuhan memperbarui runtime.
Namun, ini juga tidak berarti setiap instalasi Laravel, WordPress, atau Drupal pasti dapat dieksploitasi. Risiko aktual bergantung pada versi PHP, konfigurasi server, jalur pemrosesan permintaan, dan patch yang sudah diterapkan.
Bagi developer, hal ini memperjelas perbedaan antara keamanan aplikasi dan keamanan platform.
Keamanan aplikasi mencakup validasi input, autentikasi, otorisasi, pengelolaan sesi, dan penggunaan dependensi yang aman.
Keamanan platform mencakup runtime PHP, web server, sistem operasi, pustaka, konfigurasi, serta proses pembaruan.
Keduanya harus ditangani secara bersamaan.
7. Versi PHP yang telah diperbaiki
Pada 21 Oktober 2026, tim PHP menerbitkan rilis keamanan untuk cabang yang masih didukung.
| Cabang PHP | Versi yang diperbaiki |
|---|---|
| PHP 8.5 | 8.5.12 |
| PHP 8.4 | 8.4.27 |
| PHP 8.3 | 8.3.36 |
| PHP 8.2 | 8.2.35 |
Sumber: Pengumuman keamanan resmi PHP.
Jika menggunakan PHP 8.5.11, 8.4.26, 8.3.35, atau 8.2.34, segera periksa dan lakukan pembaruan ke versi yang telah diperbaiki pada cabang terkait.
Versi PHP yang lebih lama memerlukan perhatian khusus karena sejumlah cabang sudah tidak lagi menerima pembaruan reguler dari upstream. Jika masih harus mengoperasikan versi lama, periksa apakah vendor sistem operasi atau penyedia dukungan menyediakan backport keamanan yang sesuai. Pilihan paling baik adalah merencanakan migrasi ke cabang yang masih didukung.
Perhatikan pula bahwa versi PHP CLI yang terlihat ketika menjalankan perintah php -v belum tentu sama dengan versi PHP yang melayani website. Sebuah server dapat memiliki beberapa instalasi PHP, PHP-FPM, atau konfigurasi web server yang berbeda.
Pembaruan harus diterapkan pada runtime yang benar-benar digunakan oleh aplikasi.
8. Langkah mitigasi untuk developer dan admin server
Berikut urutan tindakan yang praktis.
Langkah 1 — Periksa versi PHP
Pada lingkungan yang menggunakan PHP CLI, jalankan:
php -v
Perintah ini memeriksa versi CLI. Jika menggunakan PHP-FPM, Apache mod_php, PHP-CGI, atau runtime yang dikelola panel hosting, periksa juga versi runtime yang melayani permintaan web.
Jangan mengandalkan satu hasil perintah untuk menyimpulkan seluruh instalasi telah aman.
Langkah 2 — Perbarui PHP
Gunakan paket resmi dari vendor sistem operasi, panel hosting, atau sumber distribusi PHP yang sesuai.
Setelah pembaruan, pastikan layanan terkait telah memuat runtime yang baru. Pada server produksi, lakukan pengujian kompatibilitas aplikasi dan verifikasi versi setelah restart atau reload layanan yang diperlukan.
Langkah 3 — Audit semua aplikasi dan server
Inventarisasi seluruh instalasi PHP yang digunakan, termasuk:
- Website produksi dan staging.
- Aplikasi Laravel, WordPress, dan Drupal.
- Worker atau layanan latar belakang yang menggunakan PHP.
- Container dan image deployment.
- Server lama yang mungkin sudah jarang dipantau.
Satu server yang terlupakan dapat menjadi titik lemah dalam lingkungan yang lebih besar.
Langkah 4 — Periksa log dan indikator kompromi
AWS merekomendasikan pemeriksaan terhadap permintaan mencurigakan, termasuk permintaan POST multipart yang memuat PHP_SESSION_UPLOAD_PROGRESS, serta pemeriksaan log web dan aktivitas proses yang tidak biasa.
Namun, keberadaan satu string atau alamat IP saja tidak cukup untuk memastikan sebuah server telah diserang. Indikator harus dianalisis dalam konteks, karena alamat IP anonim dapat digunakan oleh banyak pihak dan dapat pula muncul dalam aktivitas yang tidak berbahaya.
Periksa kemungkinan adanya:
- Proses anak yang tidak lazim dari proses PHP atau web server.
- File PHP baru atau berubah tanpa penjelasan.
- Aktivitas jaringan keluar yang tidak sesuai dengan fungsi aplikasi.
- Error memori atau crash yang tidak biasa.
- Perubahan akun, tugas terjadwal, atau konfigurasi server yang tidak dikenal.
Jika terdapat bukti kompromi, isolasi sistem sesuai prosedur respons insiden, simpan log dan bukti, lalu lakukan investigasi sebelum menganggap patch saja sudah menyelesaikan masalah. Memperbarui perangkat lunak tidak otomatis menghapus akses atau malware yang mungkin sudah dipasang penyerang.
Langkah 5 — Jangan mengandalkan WAF sebagai satu-satunya pertahanan
Web Application Firewall dapat membantu memblokir pola permintaan tertentu, tetapi tidak menggantikan patch pada runtime yang rentan.
Filter berdasarkan pola serangan dapat dilewati jika jalur eksploitasi berubah. Prioritasnya tetap memperbarui PHP, membatasi hak akses proses, memantau aktivitas server, dan menjaga kemampuan pemulihan.
9. Pelajaran bagi dunia pengembangan perangkat lunak
PHP2Shell memperlihatkan bahwa keamanan tidak dapat dinilai hanya dari apakah kode aplikasi terlihat rapi.
Ada beberapa lapisan yang perlu diperhatikan:
- Kode aplikasi: validasi input, autentikasi, otorisasi, dan penanganan kesalahan.
- Runtime dan dependensi: PHP, framework, pustaka, serta komponen yang digunakan.
- Infrastruktur: web server, sistem operasi, container, dan konfigurasi jaringan.
- Operasional: patch rutin, pemantauan log, inventaris aset, dan respons insiden.
- Penelitian keamanan: pengujian sistematis, penggunaan AI secara bertanggung jawab, dan koordinasi pengungkapan.
Tidak ada satu lapisan yang dapat menggantikan seluruh lapisan lainnya.
Framework yang baik tidak dapat menambal runtime secara otomatis. Firewall tidak menjamin tidak ada eksploitasi. Dan AI yang mampu menemukan bug tidak membuat semua temuan otomatis benar.
Keamanan merupakan proses berkelanjutan untuk mengurangi risiko, menemukan kelemahan, memperbaikinya, dan memastikan perbaikan benar-benar diterapkan.
Kesimpulan: kode lama bukan berarti aman
PHP2Shell menjadi pengingat bahwa kerentanan serius dapat bertahan lama di dalam perangkat lunak yang digunakan secara luas.
Menurut Wiz Research, kelemahan yang mendasari kasus ini telah ada selama lebih dari satu dekade. Pada Agustus 2026, penelitian yang melibatkan AI membantu mengidentifikasi dan memvalidasi jalur eksploitasi. Pada 21 Oktober 2026, perbaikan resmi diterbitkan untuk cabang PHP yang didukung.
Kasus ini bukan alasan untuk meninggalkan PHP atau menganggap seluruh website PHP telah diretas. Sebaliknya, ini merupakan alasan untuk memperlakukan pemeliharaan runtime sebagai bagian wajib dari keamanan aplikasi.
Bagi developer, jangan berhenti pada kode yang ditulis sendiri. Bagi admin server, jangan menganggap website aman hanya karena masih berjalan normal. Dan bagi pemilik bisnis, pastikan ada proses yang jelas untuk mengetahui versi komponen, memasang pembaruan, serta memeriksa indikasi kompromi.
Sebab, keamanan sebuah aplikasi tidak hanya ditentukan oleh apa yang kita tulis, tetapi juga oleh fondasi yang menjalankannya.
Referensi
About the author
I am an enthusiastic researcher and developer with a passion for using technology to innovate in business and education.
Comments
Join the discussionNo comments yet. Be the first to comment.
