Jawaban singkat
Di shared hosting, PHP yang menjalankan website Anda dipasang dan di-update oleh penyedia hosting, bukan oleh Anda. Jadi untuk PHP2Shell (CVE-2026-109618 dan CVE-2026-109619), tugas Anda ada tiga:
Cek versi PHP website Anda (langkah 1 di bawah).
Kirim pesan ke support hosting dan minta mereka mengonfirmasi bahwa PHP sudah di versi yang memuat perbaikan: 8.5.12, 8.4.27, 8.3.36 atau 8.2.35, atau paket vendor yang sudah memuat patch (php.net). Pesannya siap disalin di langkah 2.
Baca jawabannya dengan teliti. "Sudah kami tangani" belum tentu berarti sudah di-patch. Langkah 3 berisi jawaban yang sering muncul dan apa yang perlu ditanyakan balik.
BSSN meminta pemilik dan pengelola website bertindak: cek versi PHP, update ke versi yang sudah di-patch, pastikan seluruh PHP ikut di-update lalu layanan di-restart, dan batasi akses atau isolasi layanan sementara bila perlu (BSSN di X, 24 Okt; Kompas Tekno). Di shared hosting, sebagian besar langkah itu hanya bisa dikerjakan hosting. Halaman ini membantu Anda memintanya dengan jelas.
Langkah 1: catat versi PHP website Anda
Sebelum menghubungi hosting, catat dua hal: versi PHP lengkap (misalnya 8.3.36, bukan hanya "8.3") dan Server API (misalnya LiteSpeed atau FPM/FastCGI). Cara menemukannya lewat cPanel, menu Select PHP Version, WordPress Kesehatan Situs atau phpinfo ada di Apakah website saya terdampak PHP2Shell?.
Lalu tempel versi itu ke Cek Versi PHP. Alat ini membandingkan versi Anda dengan versi yang sudah di-patch. Pengecekan berjalan di browser Anda, dan versi yang Anda tempel tidak dikirim ke mana pun.
Jika hasilnya di bawah versi yang sudah di-patch, atau Anda tidak bisa melihat nomor versi lengkap, lanjut ke langkah 2.
Langkah 2: kirim pesan ini ke support hosting
Kirim lewat tiket support, bukan live chat, supaya jawabannya tertulis dan bisa Anda simpan. Ganti bagian dalam kurung siku.
Halo tim support,
Saya pemilik akun [nama akun / domain]. Terkait PHP2Shell (CVE-2026-109618 dan CVE-2026-109619), mohon konfirmasi tertulis untuk hal berikut:
Versi PHP persis yang sekarang melayani domain [domain]. Di phpinfo saya terlihat versi [versi] dengan Server API [SAPI]. Apakah versi ini sudah memuat perbaikan untuk kedua CVE tersebut (rilis upstream 8.5.12, 8.4.27, 8.3.36 atau 8.2.35)?
Jika nomor versinya lebih rendah dari itu tetapi patch dipasang lewat paket vendor, mohon sebutkan nama dan versi paketnya, dan apakah changelog paket tersebut mencantumkan CVE-2026-109618 dan CVE-2026-109619.
Apakah semua versi PHP lain yang bisa saya pilih di panel (Select PHP Version / MultiPHP Manager) juga sudah di-patch? Jika ada yang belum, versi mana?
Apakah semua proses PHP (LiteSpeed/lsphp, PHP-FPM atau Apache) sudah di-restart setelah update?
Apakah
session.upload_progress.enabledsudah dimatikan di level server, seperti yang disarankan tim PHP sampai rilis berikutnya?Jika belum di-patch: tanggal berapa patch dijadwalkan, dan langkah sementara apa yang diterapkan sampai saat itu?
Terima kasih.
Kenapa tiap poin ada di pesan itu:
Poin 1: yang menentukan adalah nomor rilis lengkap, misalnya 8.3.36, bukan hanya 8.3 (php.net). Menu PHP di panel bisa hanya menampilkan "8.3", jadi minta nomor lengkapnya.
Poin 2: tim PHP menyebut distro Linux dan vendor LTS sudah menerima patch lebih dulu, dan meminta pengguna mengecek paket dari vendornya (php.net). Paket seperti itu bisa tetap bernomor lama padahal sudah di-patch. Contohnya, Ubuntu 24.04 mencatat paket php8.3 versi 8.3.6-0ubuntu0.24.04.13 sebagai sudah diperbaiki (Ubuntu). Changelog paket adalah cara mengeceknya: Google Cloud menyarankan mencari kedua nomor CVE di changelog paket PHP (Google Cloud).
Poin 3: di shared hosting Anda bisa pindah versi lewat panel. Versi yang Anda pilih sekarang mungkin sudah di-patch, tapi versi lain di daftar belum tentu.
Poin 4: memperbarui paket di disk saja tidak cukup. Proses PHP yang sedang berjalan masih memakai kode lama sampai di-restart (Google Cloud). BSSN juga meminta layanan di-restart setelah update (Kompas Tekno).
Poin 5: tim PHP menyarankan setting ini tetap mati sampai rilis berikutnya, karena ada celah terkait yang jarang terjadi, CVE-2026-115560, yang belum diperbaiki rilis 21 Oktober (php.net, 23 Okt). Setting ini harus dipasang di konfigurasi server, bukan lewat
.user.ini(php.net), jadi di shared hosting biasanya hanya hosting yang bisa memasangnya.Poin 6: jawaban "sedang kami proses" tanpa tanggal tidak bisa Anda pegang.
Langkah 3: membaca jawaban hosting
| Jawaban hosting | Artinya | Yang Anda lakukan |
|---|---|---|
| "Sudah 8.3.36" (atau 8.5.12, 8.4.27, 8.2.35, atau lebih baru) | Versi itu memuat perbaikan (php.net). | Cek sendiri: buka phpinfo lagi, tempel versinya ke Cek Versi PHP. Lalu lanjut ke bagian "Setelah di-patch". |
| "Versinya 8.3.x lama, tapi sudah di-patch vendor" | Bisa benar (lihat contoh Ubuntu di atas). | Minta nama paket, versinya, dan baris changelog yang menyebut kedua CVE. |
| "Server kami dilindungi WAF / firewall" | WAF hanya lapisan tambahan. Google Cloud menyebut aturan WAF seperti Cloud Armor sebagai kontrol pengganti sementara, dan upgrade PHP tetap diperlukan untuk menutup celahnya (Google Cloud). | Tanyakan tanggal update PHP-nya. |
| "Upload progress sudah kami matikan" | Itu mitigasi untuk satu jalur serangan. Tim PHP menegaskan hanya update yang menutup celah ini sepenuhnya (php.net). | Bagus sebagai tambahan. Tetap tanyakan versi dan tanggal update. |
| "Sudah di-update" tanpa menyebut restart | Proses lama bisa masih berjalan (Google Cloud). | Tanyakan apakah semua proses PHP sudah di-restart, lalu cek ulang phpinfo. |
| "PHP 8.1 / 7.4 tidak kami update lagi" | Proyek PHP memang tidak merilis update untuk 8.1 ke bawah (php.net). | Pindah ke 8.3 atau lebih baru lewat menu PHP di panel, jika website Anda mendukungnya dan hosting sudah mem-patch versi itu. 8.2 hanya mendapat patch sampai 31 Desember 2026 (php.net). Tes website Anda setelah pindah: plugin atau tema lama bisa rusak setelah naik versi. |
| Tidak ada jawaban, atau "sedang diproses" tanpa tanggal | Status belum jelas. | Lihat bagian berikut. |
Jika hosting belum bisa (atau tidak mau) patch
Pindah ke versi PHP yang sudah di-patch lewat panel, jika hosting sudah mem-patch versi lain di daftar (poin 3 di pesan Anda). Pilih 8.3 atau lebih baru jika website Anda mendukungnya, karena 8.2 hanya mendapat patch sampai 31 Desember 2026 (php.net). Tes website setelah pindah.
Batasi akses atau tutup sementara. BSSN menyarankan membatasi akses jaringan ke sistem yang terdampak atau mengisolasi layanan yang terhubung langsung ke internet bila belum bisa update (Kompas Tekno). NCSC Inggris dan Canadian Centre for Cyber Security (Kanada) juga menyarankan mempertimbangkan untuk menutup sistem dari internet sampai bisa diperbaiki (NCSC, Cyber Centre Kanada). Di shared hosting, artinya: minta hosting membatasi akses ke website Anda, atau aktifkan mode maintenance sampai PHP-nya di-patch.
Pertimbangkan pindah hosting ke penyedia yang bisa menunjukkan versi PHP yang sudah di-patch secara tertulis.
Simpan jawaban tertulis hosting. Jika nanti ada masalah, Anda punya catatan kapan PHP di-patch.
Setelah di-patch: periksa apakah sempat dimasuki
Patch menutup celahnya, tapi tidak menghapus apa pun yang mungkin sudah masuk sebelumnya. Amazon menemukan percobaan eksploitasi yang tercatat pada 17 Oktober 2026, sebelum celah ini diumumkan, jadi periksa setidaknya sejak tanggal itu (AWS). Yang bisa dicek sendiri di shared hosting dan apa yang perlu diminta ke hosting ada di bagian "Di shared hosting" halaman cek kompromi.
Sudah ada yang benar-benar dibobol?
Belum jelas. Amazon (21 Oktober) melaporkan percobaan eksploitasi yang meluas, tetapi menyebut belum jelas apakah ada yang akan berhasil di sistem sungguhan (AWS). Canadian Centre for Cyber Security (pembaruan 23 Oktober) menulis bahwa proof of concept sudah ada, dan belum ada eksploitasi aktif yang teridentifikasi saat itu, sambil mengingatkan bahwa kondisi ini bisa cepat berubah (Cyber Centre Kanada). Jangan menunggu kepastian: meminta konfirmasi patch ke hosting cukup dengan satu tiket.
Ingin kami yang mengurus ke hosting?
Kami sudah mengecek dan mem-patch host PHP yang kami kelola untuk klien (website WordPress, WooCommerce dan Moodle). Untuk website Anda, kami cek versi PHP dan SAPI yang benar-benar dipakai, bukan hanya angka di panel, dan cek tanda kompromi. Di shared hosting, kami pindahkan versi PHP jika panel hosting mengizinkan. Jika tidak, PHP-nya milik penyedia hosting, dan kami kirimkan permintaan yang persis ke penyedia hosting Anda. Laporan tertulis berisi temuan Anda terima di hari yang sama Anda mengirim permintaan. Untuk server yang kami patch sendiri, status akhirnya kami tulis apa adanya: dicek dan di-patch.