Apakah Situs Anda Sudah Aman dari “PHP2Shell”?

Ditulis dari sudut pandang admin HestiaCP di Ubuntu 22.04 (jammy) dengan tumpukan ondrej/php + ondrej/apache2 + MariaDB 10.11 + NodeSource. Target pembaca: admin web/panel hosting, terutama pengguna HestiaCP & Cloudflare.

Pada 21 Oktober 2026, tim PHP merilis pembaruan keamanan kritis yang menutup dua kerentanan eksekusi kode jarak jauh (Remote Code Execution) di PHP — populer disebut “PHP2Shell”. Skor CVSS-nya 9.2 dan tidak perlu autentikasi: attacker cukup mengirim request tertentu ke aplikasi web yang rentan, dan kode mereka jalan di server Anda.

Apa yang terjadi?

Dua CVE baru diperbaiki:

CVE	Ringkasan	Dampak
CVE-2026-109618	kelemahan pada parsing/evaluasi input di path tertentu PHP	RCE unauthenticated
CVE-2026-109619	bentuk lain dari bug yang sama di komponen inti	RCE unauthenticated

Yang membuat ini serius: PHP ada di sekitar 3 dari 4 situs web di internet, dan kerentanannya berlaku pada banyak konfigurasi umum (PHP-FPM/mod_php) tanpa butuh login, upload khusus, atau konfigurasi aneh. CISA juga telah memasukkannya ke katalog kerentanan yang diketahui dieksploitasi (KEV) — artinya in-the-wild exploitation sudah terjadi, bukan sekadar teori.

Versi mana yang sudah aman?

Versi PHP	Status	Perbaikan
8.5.x	didukung	8.5.12
8.4.x	didukung	8.4.27
8.3.x	didukung	8.3.36
8.2.x	didukung	8.2.35
8.1 dan sebelumnya	EOL — tidak ada rilis resmi	tidak akan dirilis oleh php.net

Pemesanannya penting untuk dipahami: untuk 8.1 ke bawah tidak ada patch resmi. Tim keamanan PHP hanya memberikan minimal backport ke pihak yang membangun paket sistem operasi (distro Linux), jadi kalau server Anda masih menjalankan PHP 5.6 / 7.x / 8.0 / 8.1 — jangan berharap “nanti masuk update apt” dengan sendirinya.

Cara cepat memeriksa server Anda

# Versi PHP di CLI
php -v

# Semua versi PHP-FPM yang terpasang (umum di panel multiphp)
ls /etc/php/
# atau jika memakai HestiaCP:
sudo /usr/local/hestia/bin/v-list-sys-php

Kemudian cek versi yang dipakai setiap situs aktif Anda:

• HestiaCP: per domain, lihat Web → domain → edit → template PHP (atau CLI: v-list-web-domain USER DOMAIN), yang menentukan versi PHP-FPM yang dilayani.
• Jika versinya < 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 → belum patch. Perbarui sekarang.

Langkah perbaikan

1. Perbarui PHP via package manager

Ubuntu/Debian dengan PPA ondrej/php (seperti server HestiaCP saya):

apt-get update
apt-get upgrade php*        # atau: apt-get install --only-upgrade php8.3 php8.2

Catatan pengalaman di server saya: apt-get update sempat menampilkan error 503 Service Unavailable dari ppa.launchpadcontent.net/ondrej/php (PPA utama patch PHP — kalau di-skip, patch bisa kelewat!) dan error perubahan Label di PPA ondrej/apache2 yang wajib diterima eksplisit:

apt-get update --allow-releaseinfo-change
apt-get update            # ulang hingga tanpa error, baru upgrade

2. Metode resmi HestiaCP (repo sury)

HestiaCP punya prosedur resmi untuk memastikan versi PHP yang dipakai panel berasal dari repositori yang benar. Di Debian, sumber resminya adalah packages.sury.org/php — hapus file sumber ondrej yang lama, pasang keyring, dan tambahkan repo sury:

#!/usr/bin/env bash
set -euo pipefail

apt-get update
apt-get install -y lsb-release ca-certificates curl gnupg

codename="$(lsb_release -sc)"
arch="$(dpkg --print-architecture)"

# Remove any old ondrej/sury source files
grep -rl ondrej /etc/apt/sources.list.d 2>/dev/null | xargs -r rm -f

# Fetch the signing key first
curl -fsSL https://packages.sury.org/php/apt.gpg | gpg --dearmor -o /usr/share/keyrings/sury-keyring.gpg

# Add the repository
echo "deb [arch=${arch} signed-by=/usr/share/keyrings/sury-keyring.gpg] https://packages.sury.org/php/ ${codename} main" \
  > /etc/apt/sources.list.d/php.list

apt-get update

Setelah itu baru jalankan apt-get upgrade untuk semua paket php*. Di Ubuntu, HestiaCP tetap memakai PPA ondrej/php yang setara (sury memang versi Debian-nya). Perhatian: baris rm -f di atas menghapus semua file sumber yang menyebut “ondrej” — jalankan script ini hanya di Debian; di Ubuntu itu justru menghapus PPA PHP utama Anda.

3. Restart semua PHP-FPM worker

Setelah paket naik, wajib restart service PHP-FPM versi yang dipakai situs aktif; kalau tidak, worker lama (proses yang tetap berjalan dengan modul lama) masih melayani request:

systemctl restart php8.2-fpm php8.3-fpm
# HestiaCP:
sudo /usr/local/hestia/bin/v-restart-web-backend

4. Bersihkan versi PHP EOL yang tak terpakai

Kalau Anda memakai panel multiphp, hapus tumpukan lama yang tak dipakai — mengurangi permukaan serangan dan ukuran upgrade:

sudo /usr/local/hestia/bin/v-delete-web-php 7.4
sudo /usr/local/hestia/bin/v-delete-web-php 8.1
# dan seterusnya untuk 5.6 / 7.0 / 7.1 / 7.2 / 7.3 / 8.0

Perintah ini akan menolak dijalankan bila versi masih dipakai domain — aman untuk mencegah kecelakaan. Untuk domain yang masih butuh versi lama (aplikasi warisan), migrasi ke >= 8.2 adalah satu-satunya jalan; tes dulu di staging.

Di server HestiaCP saya sendiri, daftar upgrade menunjukkan 288+ paket, termasuk tumpukan PHP 5.6, 7.0–7.4, dan 8.0–8.3 dari PPA ondrej/php yang tertinggal sejak lama — padahal situs aktif hanya memakai beberapa versi. Setiap versi PHP terpasang = permukaan serangan tambahan. v-delete-web-php untuk versi yang tidak dipakai adalah salah satu pembersihan paling berguna setelah insiden ini.

5. Kalau tidak bisa upgrade segera

• Isolasi: pindahkan aplikasi ke PHP versi ter-update di container yang terpisah.
• Layer WAF: Cloudflare/AWS WAF/ModSecurity bisa membantu menahan eksploit umum, tapi bukan patch — WAF bisa dilewati sesuai kecocokan rule, jadikan sebagai jaminan, bukan perpanjangan umur tak berbatas.
• Batas waktu: rencanakan upgrade dalam hari, bukan bulan — kerentanannya sudah dieksploitasi.

Pelajaran dari insiden ini

1. Multiphp itu pedang bermata dua — fleksibel, tapi server yang “memiliki semua versi PHP” memiliki seluruh kerentanan semua versi PHP. Audit dan hapus versi yang tak dipakai.
2. PHP EOL bukan akhir dunia, tapi juga bukan zona aman — pasca-RCE seperti ini, versi EOL berarti Anda menerima paket backport yang tidak dijamin oleh php.net. Rencanakan migrasi sejak EOL diumumkan.
3. Restart service setelah patch — banyak admin lupa, lalu mengira sudah aman padahal RAM masih menjalankan biner lama.
4. Verifikasi, jangan asumsi — cek langsung dari server (v-list-sys-php/php -v), bukan karena halaman tidak tampak error.

Sumber

• Pengumuman resmi PHP Foundation & advisory CVE-2026-109618/109619
• CISA Known Exploited Vulnerabilities Catalog (entri 2026-10)
• BleepingComputer, “Critical PHP security fix … actively exploited” (21 Okt 2026)
• Forum HestiaCP, “Heads up: upcoming critical PHP security release”
• Panduan PHP EOL: https://www.php.net/supported-versions.php

Note sebelum publikasi: siapkan foto banner PHP; sertakan screenshot v-list-sys-php sebelum/sesudah upgrade sebagai bukti; verifikasi ulang ringkasan CVE pada advisory resmi.