Lewati ke konten
KEAMANAN SIBER / PHP2SHELL

Pahami PHP2Shell. Lindungi bisnis Anda.

Dua kerentanan pada inti PHP dapat berdampak pada website, data, dan operasional bisnis. Pahami apa yang perlu diperiksa, apa yang perlu diperbaiki, dan bagaimana menyusun respons bersama tim Anda.

Perbaikan PHP tersediaReferensi ditinjau 22 Oktober 2026
PHP2ShellCVE-2026-109618
CVE-2026-109619
LETAK MASALAH

Pada runtime PHP.

Runtime memproses permintaan web dan menjalankan kode aplikasi. Perbaikan perlu menjangkau setiap runtime dan worker yang aktif.

Model sederhana · kondisi nyata berbeda menurut deployment.

↗
Baca riset di php2shell.com

Rujukan riset, dampak, dan panduan upgrade dari tim pengungkapan PHP2Shell.

php2shell.com
01 / MEMAHAMI MASALAH

Apa itu PHP2Shell?

PHP2Shell adalah nama untuk dua kerentanan pada runtime PHP yang dapat memungkinkan eksekusi kode jarak jauh (RCE) tanpa login. Dampaknya bergantung pada build, integrasi server, konfigurasi, dan alur aplikasi. Ini persoalan runtime, sehingga pembaruan plugin atau dependensi aplikasi saja tidak cukup.

Pembaruan WordPress, plugin, atau dependensi aplikasi tetap penting. Untuk PHP2Shell, runtime PHP di bawahnya juga harus diperbarui.

Sumber: PHP
CVE-2026-10961801

Kerusakan saat memori habis

CVE-2026-109618: kegagalan memori dapat meninggalkan data internal tidak valid. RCE dikonfirmasi pada mod_php; analisis mendukung kerentanan FPM, tetapi advisory ini belum mendemonstrasikan eksploit FPM lengkap.

Sumber: PHP advisory ↗
CVE-2026-10961902

State tertinggal antarpemintaan

CVE-2026-109619: state permintaan dapat tertinggal di worker setelah memorinya dilepas. Eksploitasi memerlukan jalur penghasil dan pemakai state pada worker yang sama. Jalur FPM tervalidasi bergantung pada operasi aplikasi yang sesuai.

Sumber: PHP advisory ↗

Siapa yang perlu memeriksa?

Pemilik website berbasis PHP, tim IT, penyedia hosting, dan agensi yang mengelola situs klien. WordPress, Drupal, Joomla, Laravel, dan aplikasi PHP kustom termasuk contoh ekosistem yang perlu diinventarisasi. Nama platform saja tidak menentukan apakah suatu instalasi dapat dieksploitasi.

02 / DAMPAK PADA BISNIS

Dampak pada data, akses, dan operasional.

Dampak bergantung pada konfigurasi, alur aplikasi, dan hak akses worker. Kerentanan bukan bukti bahwa organisasi telah mengalami kompromi.

01

Kerahasiaan data

Riset mendemonstrasikan pembacaan memori proses PHP. Rahasia atau data permintaan dapat terekspos tanpa harus mengeksekusi kode terlebih dahulu.

Sumber ↗
02

Akses & integritas sistem

Eksekusi kode sebagai akun worker dapat membuka akses ke file, aplikasi, atau kredensial yang diizinkan untuk akun tersebut. Hak akses menentukan luas dampaknya.

Sumber ↗
03

Kelangsungan operasional

Respons dapat memerlukan pembatasan akses, penggantian worker, atau pemulihan layanan. Rencanakan dampak pada transaksi, upload, integrasi, dan pekerjaan terjadwal bersama pemilik bisnis.

Rekomendasi operasional
03 / DARI PEMAHAMAN KE TINDAKAN

Respons yang jelas, berdasarkan bukti.

Mulai dari cakupan aset dan pemiliknya. Batasi paparan bila diperlukan, terapkan patch PHP, lalu verifikasi runtime aktif dan alur bisnis. Investigasi dapat berjalan paralel jika ada dugaan kompromi.

  1. 01

    Petakan

    Inventaris aplikasi, runtime PHP, semua origin, dan pemilik layanan.

  2. 02

    Batasi

    Kurangi paparan sistem kritis dan simpan bukti yang tersedia.

  3. 03

    Perbaiki

    Koordinasikan patch vendor, uji kompatibilitas, dan ganti worker lama.

  4. 04

    Investigasi

    Tinjau aktivitas mencurigakan dan kebutuhan pemulihan bersih.

  5. 05

    Validasi

    Periksa bukti tiap backend dan uji alur bisnis yang penting.

  6. 06

    Cegah

    Tetapkan pemilik patch, dukungan versi, logging, dan cadangan.

Perbaikan PHP tersedia

Perbaiki PHP yang benar-benar berjalan.

Batas rilis upstream yang diperbaiki ditunjukkan di bawah. Paket distribusi dapat memiliki backport; cocokkan build lengkap dengan advisory vendor. Ganti worker lama dan periksa seluruh backend.

Sumber: PHP ↗
CabangPerbaikan minimum
PHP 8.2.x8.2.35
PHP 8.3.x8.3.36
PHP 8.4.x8.4.27
PHP 8.5.x8.5.12

WAF, workaround konfigurasi, atau hasil scanner negatif tidak membuktikan origin sudah ditambal. Patch juga tidak menghapus persistence dari kompromi sebelumnya.

Ingin menyiapkan inventaris bersama tim IT?

Panduan interaktif dan ruang kerja lokal tersedia untuk membantu menyusun tugas, pemilik, dan bukti.

Buka panduan & ruang kerja
04 / BANTUAN UNTUK TIM ANDA

Butuh bantuan menyusun rencana respons?

Ceritakan situasi organisasi Anda kepada Samsu Sempena. Diskusikan cakupan PHP, koordinasi dengan hosting atau software house, dan langkah respons yang perlu diprioritaskan.

Yang dapat dibahas bersama

  • Menyepakati cakupan aset, pemilik, dan bukti yang perlu dikumpulkan.
  • Menetapkan prioritas pembatasan, patch, dan investigasi sesuai dampak bisnis.
  • Menyusun handoff ke IT, penyedia hosting, atau software house.
  • Menentukan bukti validasi dan kriteria penerimaan layanan.

Cakupan bantuan dan langkah berikutnya disepakati setelah konteks awal ditinjau.

Mulai percakapan

Tulis ringkasan awal, tinjau drafnya, lalu kirim melalui aplikasi email Anda. Isi inquiry tidak dikirim atau disimpan oleh halaman ini.

Contoh: hosting terkelola, beberapa website klien, atau aplikasi PHP lama. Cukup konteks awal; jangan sertakan kata sandi, token, atau log sensitif.

Atau email langsungsamsu@holocare.app ↗
05 / REFERENSI

Mulai dari sumber yang tepat.

php2shell.com memberikan ringkasan riset dan dampaknya. Untuk keputusan patch, cocokkan advisory PHP dengan paket dan lingkungan vendor Anda. Tanggal publikasi ditampilkan jika tersedia.

Halaman edukasi ini tidak memindai atau memverifikasi infrastruktur Anda. Penilaian aktual memerlukan bukti dari pengelola sistem.