Apakah website atau server saya terdampak PHP2Shell?

Jawaban singkat

Jika website Anda berjalan di PHP dan melayani request web, anggap website Anda terdampak sampai Anda memastikan dua hal: versi PHP yang benar-benar dipakai web server, dan apakah paketnya sudah memuat patch.

• Versi yang sudah memuat perbaikan: PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 (php.net). Per 24 Oktober 2026 belum ada rilis PHP yang lebih baru.

• PHP 8.1 ke bawah tidak mendapat rilis resmi baru. Pilihannya: patch dari vendor/distro, backport source dari tim PHP, atau upgrade (php.net).

• Versi di distro Linux bisa terlihat "lama" padahal sudah di-patch. Cek di tracker distro, jangan hanya membandingkan angka (Ubuntu, Debian).

Apa itu PHP2Shell?

PHP2Shell adalah nama untuk dua celah kritis di inti PHP. Perbaikannya dirilis pada 21 Oktober 2026. Keduanya bisa memungkinkan eksekusi kode jarak jauh tanpa login (php.net).

Tingkat keparahan: CVSS v4.0 9.2 (Critical) untuk keduanya menurut tim PHP (php.net). NVD sudah selesai menganalisis keduanya (status "Analyzed") dengan skor CVSS v3.1 9.8 untuk CVE-2026-109618 dan 8.1 untuk CVE-2026-109619 (NVD, 109618, NVD, 109619).

Celah ini ada di PHP itu sendiri, bukan di WordPress, Laravel atau plugin Anda. Kode aplikasi yang rapi tidak otomatis melindungi: di Apache mod_php, serangan terjadi sebelum kode aplikasi mulai berjalan (GHSA-w8hw).

Percobaan eksploitasi sudah meluas. Amazon melaporkan bahwa PHP2Shell kini menjadi sasaran percobaan eksploitasi secara luas, dari beberapa pelaku berbeda. Percobaan paling awal yang diketahui tercatat pada 17 Oktober 2026, empat hari sebelum pengumuman publik (AWS Security Blog). watchTowr juga mengamati eksploitasi di internet sejak 21 Oktober (watchTowr). Amazon menyebut belum jelas apakah percobaan itu berhasil di sistem nyata. BSSN juga meminta pengelola website segera mengambil langkah pengamanan (Kompas Tekno).

SAPI mana yang terdampak?

Menurut tim PHP, semua instalasi PHP yang melayani request web berisiko, dan risiko tertinggi ada di mod_php (php.net):

Nilai SAPI diambil dari manual php_sapi_name(). Advisory tidak memasukkan PHP command line (cli) dalam kategori "melayani request web". Meski begitu, tetap update semuanya.

Cara cek: shared hosting / cPanel

Di shared hosting, versi PHP server biasanya diurus penyedia hosting. Anda tetap bisa mengecek versi yang dipakai website Anda.

1. Lihat versi per domain. Di cPanel, buka Software → MultiPHP Manager. Halaman ini menampilkan versi PHP tiap domain dan apakah PHP-FPM aktif (dokumentasi cPanel). Di sebagian hosting, menunya bernama Select PHP Version. Di WordPress, versi PHP juga terlihat di Alat → Kesehatan Situs → Info → Server (Hipwee).

   • Menu-menu ini sering hanya menampilkan "PHP 8.3", tanpa nomor patch lengkap. Lanjutkan ke langkah 2.

2. Lihat versi persis dan SAPI dengan phpinfo. Buat file sementara dengan nama yang sulit ditebak di folder website, misalnya cek-7f3a.php:

   <?php phpinfo();

   Buka di browser, lalu catat:

   • PHP Version di bagian atas (misalnya 8.3.36);

   • Server API (misalnya LiteSpeed V8.x, FPM/FastCGI, Apache 2.0 Handler, CGI/FastCGI);

   • nilai session.upload_progress.enabled (relevan untuk mitigasi, lihat di bawah).

   Hapus file ini segera setelah dicek. phpinfo menampilkan versi PHP, informasi server dan data lingkungan server (manual phpinfo) ke siapa pun yang tahu URL-nya.

3. Bandingkan dengan versi yang sudah di-patch: 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 atau lebih baru (php.net).

4. Tanyakan ke hosting jika versinya di bawah itu, atau jika Anda masih di PHP 8.1 ke bawah. Contoh pesan ke support:

   "Apakah PHP di server akun saya sudah memuat patch CVE-2026-109618 dan CVE-2026-109619 (PHP2Shell)? Versi yang terlihat di phpinfo: [versi], Server API: [SAPI]. Jika belum, kapan dijadwalkan, dan apakah saya bisa pindah ke 8.2.35 atau lebih baru sekarang?"

5. Jika memungkinkan, pindah versi lewat MultiPHP Manager / Select PHP Version ke cabang yang didukung (8.2 ke atas), lalu tes website Anda. Plugin atau kode lama bisa rusak saat naik versi.

Cara cek: VPS / server sendiri

1. Versi CLI (bisa berbeda dengan yang dipakai web server):

   php -v

   Versi PHP di laptop developer atau di CLI belum tentu sama dengan versi di server hosting (Kompas Tekno). Lanjutkan juga ke langkah 2 dan 3.

2. Cari semua PHP yang melayani web:

   # PHP-FPM yang berjalan (nama service berbeda per distro, mis. php8.3-fpm atau php-fpm)
   systemctl list-units --type=service | grep -i php
   ps aux | grep -E 'php-fpm|php-cgi|lsphp|frankenphp' | grep -v grep
   
   # Apache mod_php
   apachectl -M 2>/dev/null | grep -i php     # atau: httpd -M

   Jika apachectl -M menampilkan php_module (atau php7_module), Anda memakai mod_php, SAPI dengan risiko tertinggi (php.net).

3. Versi dari sisi web: pasang phpinfo sementara seperti di bagian shared hosting, catat PHP Version dan Server API, lalu hapus.

4. Cek paket distro, bukan hanya nomor versi. Distro mem-backport patch ke versi lama, jadi php -v yang menunjukkan versi "lama" belum tentu berarti rentan. Contoh yang tercatat fixed untuk kedua CVE:

   • Ubuntu 24.04: php8.3 8.3.6-0ubuntu0.24.04.13, padahal nomor upstream-nya 8.3.6 (Ubuntu);

   • Debian 12 (bookworm): php8.2 8.2.35-1~deb12u1; Debian 13 (trixie): php8.4 8.4.27-1~deb13u1 (Debian).

   Pentestit juga menyarankan memakai tracker distro dan mengecek halaman kedua CVE secara terpisah, karena vendor bisa menerbitkannya di hari berbeda (Pentestit).

   dpkg -l | grep -E '^ii\s+php'     # Debian/Ubuntu
   rpm -qa | grep -i php             # RHEL/Alma/Rocky

   Bandingkan versi paket dengan tracker keamanan distro Anda.

5. Docker/container: image PHP yang Anda build sendiri harus di-build ulang dengan PHP yang sudah di-patch, lalu di-deploy ulang (Google Cloud).

6. Setelah update, restart semua worker PHP (php-fpm, Apache, LiteSpeed) supaya perbaikannya berlaku (watchTowr). Setelah itu, cek ulang phpinfo.

Ingin mengetes dari luar? Searchlight Cyber merilis php2shell-scanner (open source) untuk mengetes apakah sebuah host terekspos kedua CVE (Help Net Security). Perhatikan: scanner ini sengaja memicu kondisi out-of-memory, dan setiap path yang dites bisa menerima probe dengan total sekitar 29 MiB. Searchlight Cyber, pembuat scanner ini, menyebut cara ini pada dasarnya berisiko (Help Net Security). Jalankan hanya pada server milik Anda sendiri, di luar jam sibuk.

Versi yang sudah di-patch

Sumber: php.net, GHSA-w8hw, GHSA-6wmf. Akhir dukungan 8.2: php.net.

PHP 8.1, 8.0, 7.4 atau lebih lama: tidak ada rilis resmi

Proyek PHP tidak merilis update untuk 8.1 ke bawah (php.net). Pilihan Anda, urut dari yang paling disarankan:

1. Upgrade ke cabang yang didukung (8.2.35+, idealnya 8.4/8.5), lalu tes aplikasi.

2. Patch dari vendor/distro. Beberapa distro dan vendor LTS menyediakan backport. Contohnya, Ubuntu mencatat fix untuk php8.1 (22.04) dan php7.4 (20.04). Fix untuk php7.4 dan versi yang lebih lama butuh Ubuntu Pro (Ubuntu).

3. Build dari source dengan backport resmi tim PHP untuk 7.4, 8.0 dan 8.1 (php.net).

4. PHP 7.3 ke bawah (termasuk PHP 5): tidak ada backport resmi dari tim PHP. Menurut watchTowr, cabang lama ini, termasuk PHP 5, ikut terdampak (watchTowr). Jika server Anda memakai Ubuntu lama, Ubuntu Pro mencatat fix untuk php7.2 (18.04), php7.0 (16.04) dan php5 (14.04); dua yang terakhir lewat add-on Legacy Support (Ubuntu). Selain itu: upgrade, atau putus server dari internet / taruh di belakang VPN atau WAF sampai bisa upgrade (Huntress). NCSC Inggris menyarankan untuk mempertimbangkan mematikan sistem yang tidak bisa segera dimitigasi, dan mengecek tanda kompromi sebelum upgrade atau mitigasi (NCSC).

5. Pengguna rpms.remirepo.net: pada 21 Oktober repo ini belum punya paket update, dan Help Net Security menyarankan pindah ke paket distro atau build dari source (Help Net Security). Status terbarunya belum kami konfirmasi.

Mitigasi sementara (bukan pengganti update)

Tim PHP menegaskan bahwa hanya update yang menutup celah ini sepenuhnya. Langkah-langkah berikut hanya mengurangi jalur serangan tertentu (php.net):

• Set session.upload_progress.enabled=0 di php.ini, pool FPM atau konfigurasi server, lalu restart semua worker. Jangan andalkan ini_set() atau .user.ini FPM. Tim PHP juga menyarankan agar setting ini tetap dipakai sampai bugfix release berikutnya, karena ada jalur RCE lain yang jarang terjadi (CVE-2026-115560). Jalur itu hanya muncul jika aplikasi mengganti session.serialize_handler saat berjalan (php.net, 23 Okt).

• Khusus PHP 8.5: set fatal_error_backtraces=0, lalu restart worker.

• Pakai post_max_size rendah (8M jika tidak ada upload, 32M jika ada) dan batasi ukuran request di web server/proxy.

• Hanya untuk VPS/server sendiri: tim PHP menyebut memory_limit=-1, dikunci lewat php_admin_value, sebagai mitigasi yang pun tidak lengkap. Hati-hati: setting ini menghapus batas memori PHP, sehingga satu request bisa memakai memori sebanyak yang ada di server (manual PHP). Jika memakainya, pasang batas memori container atau cgroup sebagai batas ketersediaan, seperti saran tim PHP. Di shared hosting, setting ini bukan wewenang Anda; serahkan ke penyedia hosting.

• Jangan pakai RLIMIT_AS/RLIMIT_DATA, karena justru bisa memicu jalur yang rentan.

• Cloudflare sudah memasang aturan WAF awal untuk vektor exploit yang diketahui, untuk semua pelanggan termasuk paket gratis (Help Net Security). WAF hanya lapisan tambahan, bukan perbaikan (Google Cloud).

Sudah update. Apakah sudah selesai?

Update menutup celahnya, tapi tidak menghapus apa pun yang mungkin sudah masuk sebelumnya. Periksa log, file dan proses sejak 17 Oktober 2026, tanggal percobaan eksploitasi paling awal yang diketahui (AWS Security Blog).

Huntress belum menerbitkan indikator kompromi (IOC) yang terkonfirmasi, tapi memperkirakan eksploitasi akan terlihat sebagai (Huntress):

• proses PHP/web server (php-fpm, php-cgi, httpd, apache2) yang menjalankan sh, bash, curl, wget, nc, python atau perl;

• file baru atau webshell di folder web;

• cron job, scheduled task atau akun baru.

Jika ada tanda kompromi: isolasi server dan simpan log web server serta log PHP (Huntress). Lalu ganti kredensial akses yang tersimpan di server, termasuk akses database (Kompas Tekno). Wiz menunjukkan jalur kebocoran memori yang bisa membuka password, token, API key dan sertifikat, bahkan tanpa eksekusi kode (Wiz).

Mitos dan fakta

Hanya klaim yang tercatat di sumber publik.

"CVSS-nya 10.0."
Salah. Tim PHP menilai kedua CVE dengan CVSS v4.0 9.2 (php.net). Angka 10.0 berasal dari bocoran awal, dan Pentestit sudah menandainya sebagai salah (Pentestit).

"Kedua bug itu sama-sama soal session upload progress, jadi cukup matikan upload progress."
Salah. CVE-2026-109618 adalah bug out-of-memory. Upload progress hanya salah satu jalur yang terkonfirmasi untuk CVE-2026-109619 (Pentestit, GHSA-6wmf). Mematikannya membantu, tapi bukan perbaikan (php.net).

"Cukup taruh session.upload_progress.enabled = Off di .user.ini."
Saran ini sempat beredar. Artikel Pentestit masih mencantumkannya di bagian langkah respons, walau catatan update-nya menyebut saran itu sudah dicabut. Tim PHP meminta agar ini_set() dan .user.ini FPM tidak diandalkan, karena setting ini harus sudah aktif sebelum request diproses. Pasang di php.ini, pool FPM atau konfigurasi server (php.net). Di shared hosting tanpa akses tersebut, minta penyedia hosting yang memasangnya.

"70% website terdampak." (klarifikasi angka)
Angka sekitar 70% yang dikutip media adalah porsi website yang memakai PHP, di antara situs yang bahasa sisi server-nya bisa diidentifikasi W3Techs, bukan jumlah website yang rentan (Kompas Tekno). Belum ada hitungan resmi tentang berapa website yang terdampak. Satu-satunya cara mengetahui status website Anda adalah dengan mengecek versinya.

Ingin kami yang cek dan patch?

Kami cek versi PHP, SAPI dan paket yang benar-benar dipakai website Anda, lalu patch, upgrade atau backport (PHP 7.4–8.1), restart semua worker, dan cek tanda kompromi. Laporan tertulis berisi temuan Anda terima di hari yang sama Anda mengirim permintaan, dan patch diterapkan paling lambat satu hari kerja setelahnya. Di shared hosting yang tidak mengizinkan pindah versi, PHP-nya milik penyedia hosting, dan kami kirimkan permintaan yang persis ke penyedia hosting Anda. Status akhirnya kami tulis di laporan yang sama: dicek dan di-patch.

Lihat cakupan dan ajukan cek & patch →