PHP2Shell Masuk Katalog KEV CISA 26 Oktober 2026: Eksploitasi Terkonfirmasi, Tenggat Patch Hari Ini
PHP2Shell Masuk Katalog KEV CISA 26 Oktober 2026: Eksploitasi Terkonfirmasi, Tenggat Patch Hari Ini
Pada 26 Oktober 2026, badan keamanan siber Amerika Serikat (CISA) memasukkan dua celah PHP2Shell, CVE-2026-109618 dan CVE-2026-109619, ke dalam katalog Known Exploited Vulnerabilities (KEV) setelah eksploitasi di dunia nyata terkonfirmasi. Artinya, celah ini bukan lagi sekadar risiko teoretis: penyerang sudah terbukti memakainya untuk menjalankan kode di server yang belum diperbarui, dan tenggat perbaikan yang ditetapkan CISA untuk instansi federal jatuh pada hari ini, 29 Oktober 2026.
Apa itu PHP2Shell?
PHP2Shell adalah sebutan untuk sepasang celah keamanan di inti bahasa PHP itu sendiri, bukan di framework, CMS, atau plugin tertentu. Keduanya memungkinkan penyerang tanpa login (unauthenticated) menjalankan kode sembarangan di server (remote code execution/RCE), dan keduanya diberi skor CVSS v4.0 sebesar 9,2 yang masuk kategori kritis.
| Celah Jenis masalah Dampak | ||
| CVE-2026-109618 | Korupsi memori saat PHP kehabisan memori (out-of-memory) di tengah request | RCE tanpa autentikasi |
| CVE-2026-109619 | Status internal request yang tertinggal setelah memorinya dibebaskan (use-after-free) | RCE tanpa autentikasi |
Yang membuat PHP2Shell berbahaya adalah lokasinya: celah ini hidup di interpreter PHP, sehingga hampir semua cara PHP melayani website terdampak — PHP-FPM, Apache dengan mod_php, php-cgi, FrankenPHP, hingga LiteSpeed. PHP menilai risiko tertinggi ada pada Apache dengan mod_php, karena serangan yang didemonstrasikan di sana berjalan sebelum kode aplikasi apa pun dieksekusi. Tidak ada plugin keamanan atau update framework yang bisa menutup celah ini dari dalam kode Anda; satu-satunya perbaikan tuntas adalah memperbarui PHP-nya.
Sebagai konteks skala, PHP menjalankan sekitar 70% situs web di internet, dan estimasi Censys yang dikutip The Hacker News menyebut lebih dari 32,51 juta layanan PHP masih menjalankan versi yang rentan.
Apa yang berubah pada 26 Oktober 2026?
Kronologinya penting karena menunjukkan bagaimana status celah ini bergeser dalam sepekan:
| Tanggal Kejadian | |
| 20 Oktober 2026 | Tim keamanan PHP memberi pemberitahuan awal soal rilis keamanan darurat |
| 21 Oktober 2026 | PHP merilis patch: 8.5.12, 8.4.27, 8.3.36, dan 8.2.35; CISA menerbitkan alert dan mendesak patch segera, namun saat itu belum melihat eksploitasi yang berhasil |
| 23 Oktober 2026 | CISA memperbarui alert-nya dengan aturan deteksi SIGMA dan panduan mitigasi |
| 24 Oktober 2026 | Peneliti keamanan mengonfirmasi RCE terhadap sistem honeypot — bukan sekadar crash, melainkan eksekusi kode yang berhasil |
| 26 Oktober 2026 | CISA memasukkan kedua CVE ke katalog KEV, dengan tenggat 29 Oktober 2026 untuk instansi sipil federal AS |
| 27 Oktober 2026 | Media keamanan (The Hacker News, BleepingComputer, The Register) melaporkan konfirmasi eksploitasi aktif tersebut |
Perubahan status inilah inti berita kali ini. Pada 21 Oktober, CISA sudah memperingatkan tetapi belum mengamati eksploitasi yang berhasil. Pada 24 Oktober, Adel Karimi dari tim deteksi dan respons Perplexity mengonfirmasi RCE terhadap honeypot yang menjalankan Apache mod_php dengan PHP 8.4.26. Dua hari kemudian CISA mengubah statusnya: kedua celah resmi tercatat sebagai "known exploited". Katalog KEV hanya menerima celah dengan bukti eksploitasi aktif, sehingga masuknya PHP2Shell adalah sinyal prioritas terkuat dari lembaga publik.
Untuk pembaca di Indonesia, satu hal perlu diluruskan: tenggat 29 Oktober 2026 secara hukum hanya mengikat instansi sipil federal Amerika Serikat berdasarkan Binding Operational Directive (BOD) 26-04. Tenggat itu bukan kewajiban hukum bagi perusahaan Indonesia, tetapi CISA mendorong semua organisasi untuk memprioritaskan perbaikan celah KEV — praktisnya, jika instansi federal diberi tiga hari sejak pencatatan KEV, situs yang menghadap internet tidak seharusnya menunggu jadwal maintenance kuartalan berikutnya.
Versi PHP mana yang aman dan mana yang rentan?
Aturannya sederhana: setiap rilis sebelum versi perbaikan di cabangnya rentan, dan setiap cabang yang masih didukung punya satu versi perbaikan.
| Cabang PHP Versi perbaikan | |
| 8.5 | 8.5.12 |
| 8.4 | 8.4.27 |
| 8.3 | 8.3.36 |
| 8.2 | 8.2.35 |
| 8.1 dan lebih lama | Tidak ada rilis resmi dari proyek PHP (end of life) |
Cek versi yang sedang berjalan di server Anda dengan perintah berikut:
Jika hasilnya di bawah versi perbaikan pada cabang yang sama — misalnya 8.4.26 atau 8.3.35 — server Anda masih rentan. Untuk PHP 8.1 dan lebih lama, proyek PHP tidak menerbitkan patch resmi: pindah ke cabang yang masih didukung atau pakai backport dari distributor Linux/LTS vendor Anda. Perlu dicatat, nomor versi di php -v bisa tetap sama setelah backport karena perbaikannya berupa revisi paket — verifikasi lewat nomor revisi paket, bukan hanya nomor versi.
Ini juga momen yang tepat untuk mengingat tenggat lain yang berdekatan: dukungan keamanan PHP 8.2 berakhir pada 31 Desember 2026. Jika Anda masih di 8.2, patch ke 8.2.35 sekarang, tetapi rencanakan pindah ke 8.3 atau 8.4 sebelum akhir tahun — artikel kami soal akhir masa dukungan PHP 8.2 membahas jalurnya.
Bagaimana cara memastikan server sudah diperbarui?
Langkahnya berbeda tergantung siapa yang mengelola server Anda.
1. Jika Anda memakai shared hosting (cPanel dan sejenisnya)
Anda biasanya tidak bisa memperbarui PHP sendiri di level sistem, tetapi Anda bisa memilih versi PHP yang dipakai akun Anda:
- Masuk ke cPanel, buka menu Select PHP Version atau MultiPHP Manager.
- Ubah versi PHP untuk domain Anda ke versi perbaikan yang tersedia (misalnya 8.3.36 atau 8.4.27), lalu uji login, checkout, dan formulir kontak.
- Jika versi perbaikan belum tersedia di panel, hubungi dukungan hosting dan sebutkan nomor CVE agar tiket Anda langsung dipahami.
Jangan berasumsi hosting sudah menambal hanya karena Anda "tidak mengubah apa-apa" — versi PHP di panel adalah yang menentukan.
2. Jika Anda mengelola VPS atau server sendiri
- Perbarui paket PHP lewat package manager server atau rebuild image Docker Anda, lalu verifikasi dengan
php -v. - Restart layanan PHP (PHP-FPM atau Apache) setelah update — versi baru tidak aktif sebelum prosesnya di-restart. Ini langkah yang paling sering terlewat.
- Uji alur kritis (login, checkout, callback pembayaran) di staging bila memungkinkan; untuk container, rebuild dari base image yang sudah diperbarui dan lakukan rolling replacement.
3. Jika Anda membeli source code (misalnya Laravel atau WordPress)
Perlu dipahami dengan tegas: update framework, tema, atau plugin tidak memperbaiki PHP2Shell. Source code Laravel atau WordPress Anda bisa berada di versi terbaru, tetapi selama runtime PHP di server masih rentan, celahnya tetap terbuka. Urutannya adalah: patch PHP dulu, lalu uji aplikasi. Panduan umum mengamankan website setelah membeli source code kami bahas di artikel checklist keamanan setelah beli source code.
Apakah situs yang sudah di-patch otomatis aman?
Belum tentu — dan inilah bagian yang paling sering dilewatkan. Patch menutup celah ke depan, tetapi tidak menghapus akses yang mungkin sudah didapat penyerang sebelum patch dipasang. Laporan eksploitasi sudah beredar sejak 21 Oktober, dan sebagian aktivitas bahkan dilaporkan terjadi sebelum detail celah dipublikasikan. Jika server Anda sempat terekspos dalam rentang itu, periksa: file yang baru dibuat atau diubah di luar jadwal deploy (terutama folder upload dan cache), akun admin atau API key baru yang tidak Anda kenali, cron job yang tidak Anda buat, dan pola request tidak biasa di log akses.
Jika menemukan indikasi penyusupan, patch saja tidak cukup: bersihkan artefak penyerang, putar (rotate) semua kredensial dan API key, lalu pertimbangkan restore dari backup sebelum tanggal paparan. Bila ragu, libatkan penyedia hosting atau pihak keamanan.
Kabar lain yang jangan sampai mengaburkan prioritas
Pada Jumat, 24 Oktober 2026, tim keamanan PHP juga membagikan mitigasi untuk celah RCE lain, CVE-2026-115560, yang saat itu belum memiliki patch dan hanya bisa dieksploitasi pada kombinasi konfigurasi dan kode aplikasi yang tidak biasa. Jangan sampai kabar ini membalik prioritas Anda: patch PHP2Shell sekarang, lalu evaluasi apakah konfigurasi Anda termasuk dalam skenario CVE-2026-115560.
Cara ini tidak cocok jika...
- Anda menjalankan PHP hanya di mesin lokal tanpa melayani request web dari internet — risikonya jauh lebih rendah, meskipun tetap disarankan memperbarui.
- Server Anda memakai runtime yang dikelola penuh oleh platform — periksa pengumuman platform tersebut; tanggung jawab patch mungkin ada di mereka.
- Aplikasi Anda terkunci di PHP 8.1 atau lebih lama — solusinya bukan menunda selamanya, melainkan mitigasi sementara (seperti menonaktifkan session upload progress bila tidak dipakai) sambil merencanakan migrasi. Mitigasi sementara tidak setara dengan patch.
Kesimpulan
Dalam delapan hari, PHP2Shell bergerak dari "rilis keamanan darurat" menjadi "dieksploitasi secara aktif dan tercatat di KEV". Tenggat CISA untuk instansi federal jatuh hari ini, 29 Oktober 2026 — dan meskipun tenggat itu tidak mengikat perusahaan Indonesia secara hukum, logikanya berlaku universal: celah yang sudah terbukti dieksploitasi tidak boleh menunggu. Cek php -v Anda hari ini, pastikan angkanya minimal 8.5.12, 8.4.27, 8.3.36, atau 8.2.35 sesuai cabang, restart layanannya, dan periksa tanda penyusupan bila server sempat terekspos sebelum patch.
Untuk konteks patch awalnya, baca juga artikel kami saat PHP2Shell pertama kali diumumkan. Dan jika Anda merencanakan upgrade berikutnya, jadwal rilis PHP 8.6 bisa membantu menyusun waktunya — tetapi jangan jadikan itu alasan menunda patch hari ini.
FAQ
Apa itu Katalog KEV CISA?
KEV (Known Exploited Vulnerabilities) adalah katalog yang dikelola CISA berisi celah keamanan yang terbukti dieksploitasi di dunia nyata. Masuknya sebuah CVE ke KEV adalah sinyal prioritas tertinggi, karena katalog ini hanya menerima celah dengan bukti eksploitasi aktif.
Apakah tenggat 29 Oktober 2026 berlaku untuk perusahaan Indonesia?
Tidak secara hukum. Tenggat itu berasal dari BOD 26-04 dan hanya mengikat instansi sipil federal AS. Namun CISA mendorong semua organisasi memprioritaskan celah KEV, sehingga tenggat itu tetap patokan praktis yang baik.
Versi PHP berapa yang memperbaiki PHP2Shell?
PHP 8.5.12, 8.4.27, 8.3.36, dan 8.2.35, yang dirilis 21 Oktober 2026. Versi apa pun di bawah angka tersebut pada cabang yang sama masih rentan.
Apakah update Laravel atau WordPress memperbaiki PHP2Shell?
Tidak. Celahnya ada di interpreter PHP, bukan di framework atau CMS. Update aplikasi tidak menutup celah ini; hanya update runtime PHP yang bisa.
Saya memakai shared hosting dan tidak bisa update PHP sendiri, apa yang harus dilakukan?
Ubah versi PHP akun Anda lewat MultiPHP Manager/Select PHP Version di cPanel ke versi perbaikan yang tersedia, lalu uji situs Anda. Jika versi perbaikan belum tersedia, hubungi dukungan hosting dan sebutkan nomor CVE-2026-109618 dan CVE-2026-109619.
Bagaimana cara tahu apakah server saya sudah disusupi sebelum di-patch?
Periksa file baru/diubah di luar jadwal deploy, akun atau API key yang tidak dikenal, cron job asing, dan pola request tidak biasa di log akses. Jika ada indikasi, bersihkan artefak, putar semua kredensial, dan pertimbangkan restore dari backup sebelum tanggal paparan.
Apakah PHP2Shell sama dengan celah TokenGuard Laravel?
Tidak. TokenGuard adalah celah authentication bypass di Laravel, sementara PHP2Shell adalah celah di runtime PHP itu sendiri dan memengaruhi semua aplikasi PHP, bukan hanya Laravel.
Artikel Terkait
Cara Menulis README & Dokumentasi Source Code yang Membuat Pembeli Percaya (Panduan 2026)
30 Oct 2026
Laravel 13.39.0 Rilis 27 Oktober 2026: Model Tanpa Primary Key, restoreOrCreate & Dampaknya untuk Source Code Kamu
28 Oct 2026
Cara Membuat Fitur Lupa Password di Laravel: Reset Password via Email yang Aman (Panduan 2026)
28 Oct 2026
WordPress 7.2 Beta 2 Dijadwalkan 27 Oktober 2026: Uji Ulang, Bukan Update Massal
28 Oct 2026