Badai PHP2Shell: Kronologi, Cara Kerja, dan Panduan Bertahan

Apa Itu PHP2Shell?

PHP2Shell adalah sebutan untuk dua kerentanan kritis pada runtime inti PHP yang diumumkan pada Oktober 2026. Kerentanan tersebut tercatat sebagai CVE-2026-109618 dan CVE-2026-109619. Keduanya berkaitan dengan pengelolaan memori ketika permintaan web mengalami kondisi kesalahan tertentu. Dalam kondisi yang memungkinkan eksploitasi, penyerang jarak jauh tanpa autentikasi dapat menjalankan kode pada server yang rentan.

Risiko ini penting karena PHP digunakan untuk membangun berbagai aplikasi web, termasuk sistem berbasis WordPress, Drupal, Joomla, Laravel, dan aplikasi PHP khusus. Namun, menyebut sebuah produk sebagai berbasis PHP tidak otomatis membuktikan setiap instalasinya dapat dieksploitasi dengan cara yang sama. Risiko nyata bergantung pada versi runtime, konfigurasi, cara server memproses permintaan, dan ketersediaan patch.

Istilah remote code execution atau RCE berarti pihak luar dapat membuat sistem menjalankan instruksi yang tidak semestinya melalui jaringan. Kode tersebut umumnya berjalan dengan hak akses proses PHP atau akun layanan web, bukan otomatis dengan hak administrator penuh. Meskipun begitu, dampaknya bisa meluas jika akun layanan memiliki izin berlebihan, kredensial tersimpan di lingkungan aplikasi, atau server terhubung ke sistem internal lainnya.

PHP2Shell bukan sekadar persoalan plugin yang usang atau kesalahan pada satu baris kode aplikasi. Akar masalahnya berada pada runtime PHP itu sendiri. Karena itu, pembaruan plugin, tema, atau framework saja tidak cukup untuk memperbaiki runtime yang masih rentan.

Kronologi PHP2Shell: Dari Pelaporan hingga Patch

Kronologi membantu administrator memahami mengapa kecepatan respons menjadi faktor penting. Berdasarkan advisori keamanan PHP, laporan peneliti, dan pemberitaan keamanan yang terbit pada 20–21 Oktober 2026, perkembangan utama berlangsung dalam waktu singkat.

Kronologi ini tidak berarti setiap website PHP sudah diserang. Artinya, pemilik sistem tidak boleh menunggu bukti kompromi sebelum menutup celah yang telah diketahui. Untuk sistem yang terpapar internet, setiap jam keterlambatan memperpanjang periode risiko.

Sumber: PHP release archive, Cloudflare, dan Wiz Research.

Cara Kerja PHP2Shell dan Dua Kerentanan Utamanya

Untuk memahami PHP2Shell, kita perlu mengenal cara runtime mengelola memori. Saat server menerima permintaan HTTP, PHP menyiapkan data untuk permintaan tersebut. Setelah pemrosesan selesai, runtime harus membersihkan data sementara dan memastikan tidak ada bagian dari permintaan lama yang digunakan kembali secara keliru.

Masalah muncul ketika jalur penanganan kesalahan tertentu membuat status internal tidak konsisten. Penyerang dapat menyusun permintaan khusus untuk memicu kondisi itu. Bergantung pada kerentanan dan lingkungan, hasilnya dapat berupa pembacaan memori sensitif, gangguan layanan, atau eksekusi kode jarak jauh.

1. CVE-2026-109618: korupsi memori ketika kehabisan memori

Kerentanan pertama berkaitan dengan penanganan kondisi out of memory (OOM). PHP menggunakan mekanisme untuk keluar dari konteks pemrosesan ketika kesalahan fatal seperti kehabisan memori terjadi. Pada jalur tertentu, proses tersebut dapat meninggalkan data internal yang belum diinisialisasi dengan benar. Tahap pembersihan permintaan kemudian berpotensi memperlakukan data tersebut seolah-olah valid.

Secara konseptual, ini menyerupai formulir administrasi yang tetap diproses meskipun beberapa kolom penting belum diisi. Perbedaannya, yang terdampak adalah pointer dan struktur memori di tingkat runtime, sehingga akibatnya jauh lebih serius daripada kesalahan validasi formulir biasa.

2. CVE-2026-109619: penggunaan kembali status global yang sudah tidak valid

Kerentanan kedua berkaitan dengan status global yang masih merujuk pada memori permintaan sebelumnya, padahal memori tersebut sudah dibebaskan. Situasi ini dikenal sebagai use-after-free. Jika status lama digunakan sebelum diatur kembali dengan benar, runtime dapat membaca atau memproses data yang seharusnya tidak lagi digunakan.

Advisori menjelaskan bahwa jalur terkait status permintaan dan fungsi upload progress dapat menjadi relevan dalam kondisi tertentu. Akan tetapi, administrator tidak seharusnya menganggap menonaktifkan satu fitur saja sebagai penyelesaian menyeluruh. Kedua kerentanan memerlukan pembaruan runtime yang sesuai.

Mengapa serangan ini tidak selalu membutuhkan login?

Autentikasi aplikasi berlangsung di tingkat aplikasi, sedangkan masalah PHP2Shell berada pada runtime yang menerima dan memproses permintaan. Pada jalur eksploitasi yang telah didemonstrasikan, penyerang dapat mencapai kondisi rentan tanpa terlebih dahulu masuk ke akun website. Dalam lingkungan tertentu, eksploitasi dapat berlangsung sebelum logika aplikasi dijalankan.

Konsekuensinya, mengandalkan password kuat, pembatasan halaman admin, atau validasi formulir tidak cukup. Kontrol tersebut tetap penting, tetapi tidak menggantikan patch pada komponen yang rentan.

Artikel ini sengaja tidak memberikan payload eksploitasi atau perintah untuk mengambil alih server. Untuk administrator, informasi tersebut tidak diperlukan untuk melakukan mitigasi. Identifikasi versi, penerapan patch, dan pemeriksaan indikator kompromi merupakan langkah defensif yang lebih tepat.

Dampak PHP2Shell terhadap Website dan Bisnis

Dampak potensial bergantung pada hak akses proses PHP, data yang dapat dijangkau, segmentasi jaringan, serta kemampuan pemantauan organisasi. Pada skenario yang berhasil dieksploitasi, risikonya meliputi beberapa kategori berikut.

Pencurian data dan kredensial

Penyerang yang memperoleh akses ke proses aplikasi mungkin mencoba membaca konfigurasi, token API, kredensial database, file unggahan, atau data pelanggan yang dapat dijangkau oleh akun layanan. Jika kredensial tersebut memiliki hak luas atau digunakan kembali di banyak sistem, dampak dapat menyebar ke layanan lain.

Perubahan website dan pemasangan web shell

Kode berbahaya dapat digunakan untuk mengubah konten, menambahkan file yang tidak sah, memasang mekanisme akses ulang, atau mengalihkan pengunjung ke situs berbahaya. Perubahan semacam ini dapat merusak reputasi merek dan kepercayaan pengguna.

Gangguan operasional dan biaya pemulihan

Serangan dapat mengakibatkan proses PHP crash, layanan melambat, website tidak tersedia, atau tim teknis harus melakukan investigasi dan pemulihan. Biaya tidak hanya berupa infrastruktur, tetapi juga waktu kerja, potensi kehilangan transaksi, dan kewajiban komunikasi kepada pihak terdampak.

Perluasan akses ke sistem lain

Jika server memiliki akses jaringan ke database, penyimpanan cadangan, sistem administrasi, atau layanan internal, penyerang mungkin berusaha memperluas akses. Inilah alasan mengapa pembatasan hak akses dan segmentasi jaringan tetap penting walaupun patch telah diterapkan.

Versi PHP dan Infrastruktur yang Terdampak

PHP menyebut sejumlah versi perbaikan untuk cabang yang masih didukung. Gunakan tabel berikut sebagai panduan awal dan cocokkan kembali dengan advisori resmi serta paket yang disediakan vendor sistem operasi atau penyedia hosting Anda.

Nomor versi di atas adalah versi perbaikan yang diumumkan untuk cabang terkait, bukan jaminan bahwa setiap paket distribusi memiliki nomor versi yang sama. Beberapa vendor melakukan backport patch ke paket lama. Oleh sebab itu, verifikasi status paket melalui dokumentasi vendor, bukan hanya membandingkan nomor versi yang terlihat.

Kerentanan ini berhubungan dengan runtime PHP, sehingga administrator perlu memeriksa PHP-FPM, Apache dengan mod_php, php-cgi, FrankenPHP, LiteSpeed, container, dan seluruh lingkungan lain yang memproses permintaan web PHP. Jangan hanya memeriksa satu website jika satu VPS menjalankan banyak domain atau aplikasi.

Website WordPress, Joomla, Drupal, Laravel, dan sistem custom perlu diperiksa berdasarkan runtime yang benar-benar digunakan. Memperbarui CMS atau framework tanpa memperbaiki runtime PHP tidak menyelesaikan masalah di lapisan tersebut.

Panduan Mengatasi PHP2Shell: Langkah Prioritas

Berikut urutan kerja praktis untuk pemilik website, tim IT, dan administrator server. Lakukan perubahan melalui prosedur yang terkontrol, khususnya pada sistem produksi yang melayani transaksi atau layanan penting.

1. Inventarisasi seluruh aset PHP

Catat setiap domain, VPS, server fisik, container, staging environment, job terjadwal, dan aplikasi internal yang menggunakan PHP. Identifikasi versi CLI dan versi yang benar-benar dipakai oleh web server karena keduanya bisa berbeda.

Jika Anda menggunakan panel hosting, periksa versi PHP per domain. Jika menggunakan container, periksa image yang dijalankan dan konfigurasi deployment. Inventarisasi juga penting untuk menemukan subdomain lama yang sudah terlupakan tetapi masih aktif.

2. Prioritaskan sistem yang terpapar internet

Mulai dari server produksi, aplikasi yang menyimpan data pelanggan, sistem transaksi, dan layanan yang dapat diakses publik. Jika patch tidak dapat dipasang segera dan risiko dinilai tidak dapat diterima, pertimbangkan membatasi atau menghentikan sementara akses publik sampai pembaruan bisa dilakukan dengan aman.

3. Cadangkan data dan konfigurasi secara aman

Pastikan cadangan database, file aplikasi, konfigurasi, dan informasi deployment tersedia. Simpan cadangan secara terpisah dengan akses terbatas. Backup harus dilindungi karena kredensial atau file cadangan yang dapat diakses dari server rentan juga dapat menjadi sasaran.

Jangan menunda patch secara tidak perlu hanya untuk melakukan proses backup yang panjang. Sesuaikan prosedur dengan tingkat kritikal sistem, dan pastikan cadangan tidak menimpa bukti insiden jika ada indikasi kompromi.

4. Terapkan pembaruan PHP yang telah diperbaiki

Gunakan paket resmi PHP atau paket yang telah diperbaiki oleh vendor sistem operasi maupun penyedia hosting. Pilih versi yang kompatibel dengan aplikasi dan masih didukung. Uji pada staging jika tersedia, tetapi jangan menjadikan pengujian sebagai alasan untuk menunda perlindungan pada server yang berisiko tinggi.

Setelah pembaruan, restart atau reload layanan yang relevan sesuai dokumentasi platform agar proses PHP benar-benar menggunakan binary atau paket yang baru. Pada lingkungan container, pastikan image yang diperbaiki sudah dibangun, dipasang, dan dijalankan; memperbarui file di repository saja tidak memperbaiki container yang masih berjalan.

5. Verifikasi versi runtime setelah patch

Periksa versi PHP dari lingkungan yang melayani permintaan web, bukan hanya terminal. Lakukan pengujian halaman, API, upload file, autentikasi, antrean pekerjaan, dan fungsi utama aplikasi. Periksa log startup untuk memastikan tidak ada proses lama yang masih berjalan.

Jangan menampilkan informasi PHP lengkap ke publik melalui halaman diagnostik. Gunakan pemeriksaan internal yang dibatasi aksesnya dan hapus kembali file diagnostik setelah selesai.

6. Periksa indikasi kompromi

Patch memperbaiki kerentanan, tetapi tidak otomatis menghapus web shell, akun ilegal, tugas terjadwal, atau kredensial yang mungkin sudah dicuri. Tinjau log HTTP, log PHP, log sistem, perubahan file, akun baru, cron job, proses yang berjalan, dan koneksi keluar yang tidak biasa.

Cari pola yang tidak wajar, seperti lonjakan permintaan POST multipart, error kehabisan memori, crash worker, file PHP baru yang tidak dikenal, atau proses anak yang tidak lazim dari worker web. Tidak satu pun indikator tersebut membuktikan PHP2Shell dengan sendirinya; gabungkan beberapa bukti dan cocokkan dengan waktu serta konteks sistem.

7. Jika ada indikasi serangan, lakukan respons insiden

Batasi akses server yang dicurigai, pertahankan salinan log dan bukti, dan libatkan tim keamanan atau penyedia infrastruktur. Hindari menghapus file atau memasang ulang sistem secara tergesa-gesa sebelum bukti penting disimpan. Bila kompromi terkonfirmasi, pulihkan dari sumber yang diketahui bersih, perbaiki akar masalah, rotasi kredensial dari perangkat yang aman, dan tinjau akses sistem terkait.

8. Gunakan WAF dan pembatasan jaringan sebagai lapisan tambahan

WAF, rate limiting, pembatasan akses administratif, segmentasi jaringan, dan monitoring dapat mengurangi paparan atau membantu mendeteksi aktivitas mencurigakan. Namun, kontrol tersebut tidak menggantikan pembaruan PHP. Jangan menganggap pemblokiran pola HTTP tertentu sebagai bukti bahwa seluruh jalur eksploitasi sudah tertutup.

Mengumpulkan Data, Menentukan Metrik, dan Membaca Pola Serangan

Respons keamanan yang baik bukan sekadar memasang patch, tetapi juga memastikan keputusan dibuat berdasarkan data yang dapat diverifikasi. Pengumpulan data yang terstruktur membantu tim menentukan sistem mana yang harus ditangani lebih dahulu, mengukur keberhasilan mitigasi, dan menemukan indikasi kompromi yang mungkin terlewat.

Tahap 1: Kumpulkan data dari sumber yang relevan

• Inventaris aset: alamat host, aplikasi, pemilik sistem, versi PHP, metode deployment, status dukungan, dan tingkat paparan internet.
• Log web: waktu permintaan, metode HTTP, kode status, alamat sumber jika tersedia, user agent, ukuran permintaan, dan pola endpoint.
• Log runtime: error PHP, kondisi out-of-memory, restart worker, crash, serta pesan fatal error.
• Telemetri host: proses yang berjalan, perubahan file, akun baru, tugas terjadwal, dan koneksi jaringan keluar.
• Status patch: versi paket sebelum dan sesudah pembaruan, waktu restart, hasil verifikasi, dan sistem yang belum selesai ditangani.

Kumpulkan hanya data yang dibutuhkan, batasi hak akses, lindungi log dari perubahan, dan hindari menyimpan data pribadi yang tidak relevan. Sinkronisasi waktu server juga penting agar urutan kejadian dari berbagai sumber dapat dibandingkan secara akurat.

Tahap 2: Bersihkan dan validasi informasi

Log dapat mengandung duplikasi, nilai kosong, format waktu berbeda, alamat IP dari proxy, atau pesan yang tidak berkaitan dengan serangan. Normalisasikan timestamp ke zona waktu yang konsisten, bedakan alamat klien dengan proxy tepercaya, deduplikasi kejadian, dan pisahkan log produksi dari staging.

Jangan menghapus semua baris error hanya karena terlihat berulang. Pengulangan bisa menjadi sinyal serangan, sementara error normal bisa terjadi akibat deployment atau lonjakan trafik. Beri label pada kejadian berdasarkan konteks, lalu pertahankan data mentah untuk investigasi.

Tahap 3: Tentukan metrik yang benar-benar membantu keputusan

Tahap 4: Baca pola, bukan sekadar angka

Contohnya, lonjakan permintaan multipart bersamaan dengan error OOM, restart worker yang berulang, dan munculnya file asing memiliki bobot investigasi lebih tinggi daripada satu error tunggal. Sebaliknya, lonjakan error yang tepat terjadi setelah deployment resmi mungkin menunjukkan masalah kompatibilitas. Bandingkan data dengan baseline harian, perubahan konfigurasi, dan aktivitas pengguna yang sah.

Gunakan korelasi waktu antara log web, runtime, dan sistem operasi. Periksa apakah ada proses yang muncul segera setelah permintaan anomali, apakah file berubah pada waktu yang sama, serta apakah koneksi keluar mengarah ke tujuan yang tidak dikenal. Simpan tingkat keyakinan setiap temuan agar dugaan tidak disamakan dengan insiden yang sudah terkonfirmasi.

Tahap 5: Ubah temuan menjadi tindakan terukur

Jika aset belum dipatch, tetapkan penanggung jawab dan tenggat. Jika terdapat indikator kompromi, eskalasi ke prosedur respons insiden. Jika patch telah berhasil dan tidak ditemukan indikasi serangan, lanjutkan pemantauan dan dokumentasikan hasilnya. Jika aplikasi gagal setelah upgrade, perbaiki kompatibilitas tanpa kembali membiarkan server terbuka dalam kondisi rentan.

Pendekatan berbasis data membuat tim dapat menjawab tiga pertanyaan penting: apa yang diketahui, seberapa kuat buktinya, dan tindakan apa yang paling mengurangi risiko sekarang.

Strategi Pencegahan Jangka Panjang

PHP2Shell memperlihatkan mengapa keamanan infrastruktur tidak boleh bergantung pada respons darurat sesekali. Organisasi perlu membangun siklus pengelolaan aset, pembaruan, pemantauan, dan pemulihan yang berjalan secara rutin.

Terapkan manajemen patch berkala

Tetapkan jadwal pemeriksaan advisori keamanan, kebijakan tingkat prioritas berdasarkan tingkat keparahan, dan prosedur pengujian pembaruan. Kerentanan kritis yang dapat diakses dari internet harus memiliki jalur eskalasi khusus, bukan menunggu jadwal pemeliharaan bulanan berikutnya.

Kurangi hak akses proses PHP

Gunakan akun layanan dengan hak minimum, batasi akses tulis ke direktori yang memang diperlukan, pisahkan kredensial per aplikasi, dan hindari menaruh rahasia di direktori publik. Segmentasi jaringan dapat membatasi dampak jika suatu aplikasi berhasil ditembus.

Lindungi backup dan siapkan pemulihan

Buat backup berkala, simpan salinan terpisah, batasi hak penghapusan, dan uji proses pemulihan. Backup yang belum pernah diuji belum tentu dapat digunakan ketika insiden benar-benar terjadi.

Pantau aplikasi dan infrastruktur secara terintegrasi

Gabungkan monitoring ketersediaan, log aplikasi, log sistem, status patch, dan perubahan file. Tetapkan siapa yang menerima peringatan, kapan harus melakukan eskalasi, dan bagaimana bukti insiden disimpan.

Buat prosedur respons insiden yang realistis

Dokumentasikan cara mengisolasi server, menghubungi penyedia hosting, mempertahankan log, merotasi kredensial, memulihkan aplikasi, serta memberi tahu pihak terkait jika diperlukan. Lakukan latihan berkala supaya tim tidak harus merancang seluruh prosedur saat sedang menghadapi serangan.

FAQ PHP2Shell