Hampir separuh situs web di dunia berjalan di atas PHP, dan di Indonesia angkanya terasa lebih besar lagi: dari situs pemerintah daerah, toko daring, portal kampus, sampai ribuan situs WordPress UMKM di paket hosting bersama. Karena itu, pengumuman dua celah kritis PHP pada 21 Oktober 2026, yang dijuluki PHP2Shell, bukan sekadar berita untuk tim keamanan. Ini urusan setiap orang yang mengelola server web.
Artikel ini membedah apa yang diketahui sejauh ini tentang CVE-2026-109618 dan CVE-2026-109619, mengapa pembaruan aplikasi seperti WordPress saja tidak cukup, bagaimana memeriksa dan menambal server Anda, serta apa yang perlu dilakukan jika Anda curiga sudah disusupi. Informasi eksploitasi masih berubah cepat, jadi bagian status di bawah sengaja ditulis dengan hati-hati.
Apa yang Terjadi
Tim PHP merilis versi perbaikan 8.5.12, 8.4.27, 8.3.36, dan 8.2.35 pada 21 Oktober 2026 sekitar pukul 14.00 UTC, bersamaan dengan publikasi advisory keamanan di GitHub. Dua kerentanan diperbaiki sekaligus, keduanya berpotensi menghasilkan remote code execution (RCE) tanpa autentikasi:
- CVE-2026-109618 ("RCE via OOM corruption"): saat penanganan kehabisan memori (out-of-memory), data internal permintaan yang belum terinisialisasi sepenuhnya dianggap valid ketika proses pembersihan berjalan.
- CVE-2026-109619 ("RCE via stale global state"): sebuah use-after-free di mana state milik satu permintaan tetap ada setelah memorinya dibebaskan, lalu dapat dipakai worker untuk permintaan berikutnya. Peneliti juga melaporkan bahwa bug ini dapat membocorkan isi memori seperti kata sandi, token, kunci API, dan sertifikat tanpa harus sampai ke RCE.
Keduanya dinilai CVSS v4.0 9,2 (Critical) oleh PHP sebagai CNA, sedangkan NVD memberi CVSS v3.1 9,8. Perbedaan skor ini bukan sekadar beda versi rumus: NVD menilai kompleksitas serangan rendah, sementara PHP menilainya tinggi dengan prasyarat serangan tertentu. Bagi praktisi, pesan utamanya sama: perlakukan sebagai prioritas tertinggi untuk server yang menghadap internet.
Siapa yang Terdampak
Yang terdampak adalah PHP yang melayani permintaan web: Apache mod_php, PHP-FPM, php-cgi, FrankenPHP, dan LiteSpeed. PHP sendiri menilai risiko tertinggi ada pada mod_php. Untuk CVE-2026-109618, RCE telah divalidasi lewat HTTP terhadap mod_php; untuk PHP-FPM, analisis kode sumber mendukung adanya kerentanan namun belum ada exploit FPM lengkap yang didemonstrasikan. Untuk CVE-2026-109619, jalur RCE lewat sesi telah divalidasi pada mod_php dan FPM, dengan jalur FPM bergantung pada operasi aplikasi tertentu.
Poin penting bagi pengembang aplikasi: peneliti menyatakan exploit tidak bergantung pada aplikasi. Sebuah halaman "Hello World" pada versi PHP yang rentan pun dapat dieksploitasi, dan pengujian dilakukan terhadap WordPress, Drupal, dan Joomla. Artinya, memperbarui plugin atau CMS tidak menutup celah ini. Yang harus diperbarui adalah runtime PHP-nya.
Versi yang Terdampak dan Diperbaiki
- PHP 8.5.x sebelum 8.5.12, 8.4.x sebelum 8.4.27, 8.3.x sebelum 8.3.36, 8.2.x sebelum 8.2.35 dinyatakan terdampak oleh PHP.
- PHP 8.1 ke bawah sudah tidak didukung. Tidak ada rilis resmi; yang tersedia hanya source backport minimal untuk 7.4, 8.0, dan 8.1 di repositori GitHub, atau paket dari vendor LTS/distribusi.
- Sejumlah peneliti menyebut versi lama hingga PHP 5.4 juga terdampak, namun hal ini belum dikonfirmasi oleh PHP. NVD mencantumkan semua versi sebelum 8.2.35 tanpa batas bawah, yang lebih merupakan cara penulisan konfigurasi NVD daripada pernyataan resmi PHP.
- PHP 8.2 akan mencapai end of life pada 31 Desember 2026, jadi ini momen yang baik untuk merencanakan migrasi ke 8.3 atau lebih baru.
Status Eksploitasi: Informasi yang Saling Bertentangan
Per 22 Oktober 2026, gambaran eksploitasi belum seragam, dan kita sebaiknya jujur soal itu:
- CISA dan Canadian Centre for Cyber Security menyatakan belum mengamati eksploitasi saat peringatan mereka terbit. Kedua CVE belum masuk katalog Known Exploited Vulnerabilities (KEV) CISA pada katalog versi 2026.10.21.
- Di sisi lain, Amazon melaporkan percobaan eksploitasi di jaringan honeypot MadPot sejak 17 Oktober 2026, empat hari sebelum pengungkapan publik. watchTowr, Cloudflare, dan Hadrian juga melaporkan aktivitas atau percobaan serangan, meskipun belum jelas berapa yang berhasil. Patchstack menyebut telemetrinya baru menunjukkan probing.
Kesimpulan praktis: anggap jendela risiko sudah terbuka sejak sebelum patch tersedia. Jangan menunggu CVE ini masuk KEV untuk bertindak. Ketika celah pra-autentikasi tanpa ketergantungan aplikasi sudah punya analisis teknis publik, pemindaian massal biasanya hanya soal waktu.
Langkah 1: Inventaris PHP di Seluruh Infrastruktur
Kesalahan umum adalah hanya memeriksa server utama. PHP sering bersembunyi di tempat lain: container image lama, panel hosting, appliance, dan paket yang dibundel aplikasi. Mulailah dengan memeriksa versi yang benar-benar dipakai web server, karena versi CLI bisa berbeda dari FPM atau modul Apache.
#!/usr/bin/env bash
# Audit cepat PHP pada satu host (jalankan sebagai root)
echo "== PHP CLI =="; php -v 2>/dev/null | head -n 1
echo "== PHP-FPM =="
for b in /usr/sbin/php-fpm* /usr/sbin/php*-fpm /opt/remi/php*/root/usr/sbin/php-fpm; do
[ -x "$b" ] && echo "$b" && "$b" -v 2>/dev/null | head -n 1
done
echo "== Apache mod_php =="
apachectl -M 2>/dev/null | grep -i php || echo "mod_php tidak dimuat"
echo "== Nilai konfigurasi yang dimuat web server =="
php -i 2>/dev/null | grep -E "session.upload_progress.enabled|memory_limit|post_max_size"
echo "== Container yang memakai image PHP =="
docker ps --format '{{.Names}}\t{{.Image}}' 2>/dev/null | grep -i php || true
Catat setiap host, versinya, dan jenis SAPI-nya (mod_php, FPM, dan seterusnya). Prioritaskan sistem yang menghadap internet, dan di antara itu yang memakai mod_php.
Langkah 2: Tambal dan Restart
Perbarui ke 8.5.12, 8.4.27, 8.3.36, atau 8.2.35 atau paket distribusi yang sudah di-backport. Jika Anda memakai distribusi seperti Debian, Ubuntu, atau RHEL, periksa changelog paket: vendor sering mempertahankan nomor versi lama sambil membawa patch keamanan, jadi cari referensi CVE di changelog, bukan hanya nomor versinya.
Setelah pembaruan, restart Apache, PHP-FPM, dan semua worker PHP yang berjalan lama. Tanpa restart, proses lama tetap memakai biner lama di memori. Ini sering terlewat pada server yang pembaruan paketnya berjalan otomatis namun layanannya tidak dimuat ulang.
# Contoh pada Debian/Ubuntu dengan PHP-FPM
sudo apt update && sudo apt install --only-upgrade php8.3-fpm php8.3-cli
sudo systemctl restart php8.3-fpm
sudo systemctl restart apache2 # atau nginx bila FPM berada di belakangnya
php-fpm8.3 -v # verifikasi ulang versi
Langkah 3: Mitigasi Sementara Bila Belum Bisa Menambal
Tim PHP menyediakan mitigasi sementara. Ingat: ini bukan pengganti patch dan tidak menutup varian lain.
- CVE-2026-109618: atur
memory_limit=-1(sebaiknya tidak dapat di-override aplikasi), batasipost_max_size, dan batasi ukuran permintaan di web server atau reverse proxy. HindariRLIMIT_ASatauRLIMIT_DATA, karena kegagalan alokasi justru dapat memicu jalur yang rentan. - CVE-2026-109619: set
session.upload_progress.enabled=0(danfatal_error_backtraces=0pada PHP 8.5) lewat php.ini, konfigurasi pool FPM, atau server. Jangan memakaiini_set()atau.user.ini, lalu restart semua worker.
Jika tidak ada yang bisa dilakukan, kontrol kompensasi yang disarankan lembaga seperti NCSC Inggris, NSA, dan CISA adalah mematikan sistem sampai bisa diperbaiki, atau mengisolasinya dari internet (rekomendasi CERT-EU). WAF dapat memberi perlindungan parsial, tetapi bukan pengganti patch.
Langkah 4: Periksa Tanda-Tanda Kompromi
Saran Amazon: mulai investigasi dari 17 Oktober 2026, bukan dari tanggal pengungkapan. Belum ada IOC resmi dari PHP, CERT-EU, atau NCSC. Satu-satunya daftar IP datang dari Amazon, dan Amazon sendiri mencatat IP tersebut mencakup infrastruktur anonimisasi bersama sehingga sebaiknya dipakai untuk investigasi, bukan pemblokiran otomatis.
Petunjuk dari peneliti, bukan bukti, yang layak dicari di log:
- Cookie
PHPSESSIDpada respons yang ukurannya sangat besar atau tidak wajar. - Permintaan multipart yang tidak biasa, diikuti galat batas memori atau HTTP 500 berulang.
- Worker PHP yang crash atau restart tanpa penjelasan.
- Proses
php-fpm,httpd, atauapache2yang menjalankan shell atau interpreter, atau tool seperticurldanwget; serta berkas web shell baru di web root.
Peneliti menegaskan bahwa ketiadaan sinyal bukan bukti sistem aman. Bila ada indikasi kuat, perlakukan sebagai insiden: isolasi host, ambil salinan forensik (memori, log, web root) sebelum membersihkan, lalu rotasi seluruh kredensial yang pernah berada di server, termasuk kunci API, token, dan sertifikat, mengingat sifat kebocoran memori pada CVE-2026-109619.
# Cari proses web yang menjadi induk shell atau tool unduh
ps -eo pid,ppid,user,cmd --forest | grep -E "(php-fpm|apache2|httpd)" -A2 | grep -E "sh -c|bash|curl|wget|python|perl"
# Cari berkas PHP yang berubah sejak 17 Okt 2026 di web root
find /var/www -type f -name "*.php" -newermt "2026-10-17" -printf '%TY-%Tm-%Td %TH:%TM %p\n' | sort
Konteks Hukum bagi Organisasi Indonesia
Jika server yang terdampak menyimpan data pribadi, kebocoran memori yang membuka kata sandi dan token bukan hanya masalah teknis. Undang-Undang No. 27 Tahun 2022 tentang Pelindungan Data Pribadi mewajibkan pengendali data menjaga keamanan data dan, bila terjadi kegagalan pelindungan, memberitahukan subjek data dan lembaga yang berwenang dalam jangka waktu yang ditentukan. Dokumentasikan jadwal penambalan, hasil pemeriksaan log, dan keputusan Anda; catatan itu akan sangat berharga jika terjadi insiden atau audit. Untuk penyelenggara sistem elektronik, UU ITE juga menuntut sistem yang andal dan aman.
Pelajaran yang Lebih Luas bagi Tim Web
Insiden ini mengingatkan beberapa hal yang sering diabaikan:
- Runtime adalah bagian dari permukaan serangan. Banyak tim memantau CVE pada plugin dan framework, namun jarang pada interpreter dan modul server di bawahnya.
- Patch tanpa restart tidak selesai. Tambahkan verifikasi versi proses yang sedang berjalan ke checklist rilis.
- Versi yang sudah EOL adalah utang keamanan. PHP 8.1 ke bawah tidak mendapat rilis resmi. Peta jalan migrasi harus disiapkan sebelum celah berikutnya datang, bukan sesudahnya.
- Jendela sebelum pengungkapan itu nyata. Percobaan eksploitasi yang tercatat empat hari sebelum publikasi berarti pemeriksaan log harus melampaui tanggal advisory.
- Kurangi ketergantungan pada satu lapisan. Pemisahan hak akses proses web, egress filtering, dan segmentasi jaringan membatasi dampak walau exploit berhasil.
Penutup
PHP2Shell menggabungkan hampir semua hal yang membuat sebuah kerentanan berbahaya: pra-autentikasi, tidak bergantung pada aplikasi, menyentuh runtime yang dipakai jutaan situs, dan sudah ada laporan percobaan sebelum patch tersedia. Kabar baiknya, perbaikannya jelas: perbarui ke versi yang ditambal, restart semua worker, dan periksa log sejak 17 Oktober. Mulailah dari server yang menghadap internet, lalu rambah ke sisanya.
Tim Siberindo dapat membantu audit inventaris PHP, threat hunting, dan pemeriksaan forensik digital bila Anda menemukan indikasi kompromi. Karena status eksploitasi terus berubah, pantau advisory resmi PHP, CISA, dan katalog KEV sebelum mengambil keputusan.
Sumber: advisory dan rilis keamanan PHP (21 Okt 2026), ringkasan teknis Rescana dan Brandefense, peringatan CISA/NSA/Canadian Centre for Cyber Security, CERT-EU, serta laporan Amazon, watchTowr, Patchstack, dan Cloudflare yang dikutip media keamanan.
