Celah PHP2Shell: Cek Situs Web Anda Minggu Ini

Sejak 21 Oktober 2026, dua celah di mesin PHP sendiri, yang dijuluki PHP2Shell, memungkinkan penyerang menjalankan perintah di server web tanpa login sama sekali. Perbaikannya ada di PHP 8.5.12, 8.4.27, 8.3.36, dan 8.2.35; PHP 8.1 ke bawah tidak mendapat rilis resmi. Hari ini juga, tanyakan ke penyedia hosting atau pengembang Anda: versi PHP mana yang melayani tiap situs, dan apakah perbaikannya sudah masuk.

PHP adalah bahasa pemrograman di balik sebagian besar situs bisnis. Per 27 Oktober 2026, W3Techs mencatat PHP dipakai 69,2% situs yang bahasa server-nya diketahui. Profil perusahaan di WordPress, halaman pemesanan kamar hotel, aplikasi admin internal yang dibangun dengan Laravel atau CodeIgniter, sampai skrip kecil penerima notifikasi dari penyedia pembayaran: semuanya berjalan di atas PHP, tercatat atau tidak di daftar aset Anda.

Mengapa memperbarui WordPress tidak menolong kali ini?

Celahnya ada di mesinnya, bukan di WordPress, tema, atau plugin. Alfons Tanujaya dari Vaksincom menyampaikan hal yang sama ke detikInet pada 22 Oktober: banyak pengelola situs merasa aman karena WordPress dan plugin-nya sudah mutakhir, padahal lubangnya ada di PHP milik server. CISA, lembaga siber Amerika Serikat, menulis hal serupa dalam peringatannya: semua instalasi PHP yang melayani permintaan web terdampak, apa pun aplikasi di atasnya.

Ada yang lebih berat lagi. Serangan ini terjadi sebelum kode aplikasi Anda sempat berjalan. Tim keamanan PHP menilai risiko tertinggi ada pada Apache dengan mod_php, yaitu konfigurasi yang menjalankan PHP langsung di dalam web server. Satu permintaan dari orang asing sudah cukup untuk memicu serangan, sebelum satu baris pun kode situs Anda dijalankan.

Apa yang terjadi, dan kapan?

Kedua celah tercatat sebagai CVE-2026-109618 dan CVE-2026-109619. CVE adalah nomor identitas publik yang diberikan industri keamanan untuk tiap celah; kebanyakan pemindai dan dasbor patch mengacu ke nomor ini. Baris pertama tabel paling perlu diingat: ada yang sudah mencoba empat hari sebelum publik tahu. Jadi, kalau Anda memeriksa server, tarik mundur setidaknya sampai 17 Oktober.

Bagaimana celah di mesin PHP bisa menjadi pintu masuk?

Bayangkan PHP sebagai loket layanan dengan beberapa petugas. Tiap petugas adalah satu worker: ia menerima permintaan satu pengunjung, membersihkan dan menyiapkan meja, mengerjakan tugasnya, lalu merapikan meja untuk pengunjung berikutnya. Dua celah ini merusak rutinitas itu di dua titik yang berbeda.

Celah pertama, CVE-2026-109618, soal meja yang kehabisan tempat. Kalau petugas kehabisan memori di tengah menyiapkan meja, PHP langsung membatalkan pekerjaan dan lompat ke tahap beres-beres, yang mengira meja sudah tertata lengkap. Formulir yang baru terisi separuh dibaca seolah-olah sudah utuh. Penyerang bisa sengaja memancing kondisi kehabisan memori itu lewat unggahan formulir yang dibentuk khusus, dan tetap di dalam batas normal server. Tim PHP memastikan celah ini menghasilkan remote code execution penuh, yaitu penyerang menjalankan perintahnya sendiri di server Anda, lewat HTTP biasa pada Apache dengan mod_php dalam pengaturan bawaan.

Celah kedua, CVE-2026-109619, soal catatan yang tertinggal di meja. Petugas bisa menyimpan rujukan ke berkas pengunjung sebelumnya padahal berkasnya sudah dihancurkan. Beberapa proses berjalan sebelum meja dibereskan dan membaca catatan basi itu: fitur pemantau progres unggahan sesi, jejak kesalahan (backtrace) yang dibuat PHP 8.5 saat terjadi fatal error, dan peringatan pengaturan keliru di berkas .htaccess. Dua permintaan yang dirancang khusus dan jatuh ke petugas yang sama sudah cukup. Petugas yang lebih banyak menurunkan peluang per permintaan, tetapi tidak menghilangkan kondisinya.

Dalam dua kasus itu, perintah berjalan atas nama akun web server sendiri. Akun ini bisa membaca konfigurasi aplikasi Anda: kata sandi database, berkas .env yang menyimpan kunci server dari penyedia pembayaran, akun email. Dari situ, menanam web shell, halaman tersembunyi yang menjalankan perintah apa pun yang dikirim ke sana, tinggal rutinitas. Kasus add-on Nextcloud awal bulan ini memperlihatkan seperti apa bersih-bersihnya.

Anda di versi mana, dan apakah ada perbaikannya?

Sumber: halaman versi yang didukung dan akhir dukungan di php.net, serta FAQ watchTowr tentang cabang yang tidak didukung.

Dua baris terbawah bukan kasus langka. Angka W3Techs per 27 Oktober 2026: 7,7% situs PHP masih di PHP 5 dan 26,6% di PHP 7, dengan 73,4% pengguna PHP 7 ada di 7.4. Di antara situs PHP 8, 5,7% memakai 8.0 dan 14,9% memakai 8.1. Kalau dijumlahkan (hitungan saya, bukan W3Techs), sekitar 48% situs PHP berjalan di cabang yang tidak lagi diperbaiki proyek PHP. Pratama Persadha dari CISSReC mengutip data Censys ke Bisnis: sekitar 1,5 juta dari 2,6 juta host PHP yang terhubung internet belum ditambal pada hari pengumuman. Ardi Sutedja dari Indonesia Cyber Security Forum, di artikel yang sama, memperkirakan puluhan sampai ratusan ribu situs web di Indonesia terbuka. Anggap itu perkiraan, bukan hasil hitung.

Ada dua jebakan saat memeriksa. Pertama, perbaikan yang disalin ke versi lama (backport) tidak mengubah nomor versi: ea-php81 di cPanel tetap melapor 8.1.x setelah pembaruan 21 Oktober, dan paket Debian atau Ubuntu berperilaku sama. Buktinya adalah baris changelog yang menyebut nomor CVE, bukan angka versi. Kedua, php -v di terminal bisa berbeda dari PHP yang sebenarnya melayani situs Anda; imbauan Komdigi dan panduan pembaruan detikInet sama-sama mengingatkan hal ini.

Apa yang perlu Anda periksa minggu ini?

Sebagian besar usaha kecil menyewa tempat di server bersama atau terkelola, jadi pihak hosting yang menambal. Itu tidak menghapus tugas Anda; tugasnya berubah menjadi memastikan.

Kalau situs Anda di shared hosting atau hosting terkelola:

1. Cari tahu cabangnya. Di cPanel ada di MultiPHP Manager atau Select PHP Version; panel lain punya menu serupa. Catat cabang untuk semua situs dan subdomain, bukan hanya situs utama.
2. Ajukan tiga pertanyaan ke hosting. Versi PHP mana yang melayani situs saya? Apakah perbaikan CVE-2026-109618 dan CVE-2026-109619 sudah dipasang, dan bagaimana membuktikannya, terutama di 7.4, 8.0, atau 8.1 yang nomor versinya tidak berubah? Kapan Apache, PHP-FPM, atau proses PHP LiteSpeed dimulai ulang setelah pembaruan? Berkas yang sudah ditambal belum berarti apa-apa sebelum worker-nya dimulai ulang.
3. Kalau panel hanya menawarkan 7.x, 8.0, atau 8.1 dan hosting tidak bisa menunjukkan backport, pindahkan situs ke 8.2 ke atas setelah diuji di salinan uji (staging), atau pindah ke hosting yang bisa menjawab tiga pertanyaan tadi.

Kalau Anda mengelola server, VPS, atau kontainer sendiri:

1. Periksa yang benar-benar berjalan. php-fpm -v dan apachectl -M memberi gambaran lebih jelas daripada php -v. Lalu cari nomor CVE di changelog paket.
2. Perbarui, lalu mulai ulang semua worker. Untuk kontainer, bangun ulang image di atas base yang sudah diperbaiki; memulai ulang kontainer tidak mengganti biner di dalamnya, seperti dicatat ProjectDiscovery.
3. Tangkap biner lama yang masih di memori. Proses yang dimulai sebelum pembaruan tetap menjalankan kode lama walaupun berkas di disk sudah berganti.
4. Pasang pengaturan sementara, apa pun kondisinya. Advisory PHP menyebut session.upload_progress.enabled=0, dan di 8.5 fatal_error_backtraces=0, ditambah post_max_size yang kecil serta pemblokiran unggahan multipart (format kiriman formulir yang membawa berkas) di alamat yang tidak pernah menerima berkas. Kata tim PHP sendiri: tidak ada mitigasi yang lengkap, pembaruan satu-satunya pilihan aman. Firewall seperti milik Cloudflare memberi jeda beberapa jam, bukan rasa aman.
5. Tarik mundur ke 17 Oktober. Berkas PHP baru atau berubah di folder situs, pola web shell, worker PHP yang memunculkan shell, koneksi keluar yang tidak dikenal, akun admin CMS baru. Kalau server sempat terjangkau dari internet dalam keadaan belum ditambal, ganti kata sandi database, kunci API, dan kunci penanda sesi, sekalipun Anda tidak menemukan apa-apa.

# Yang melayani web, bukan hanya CLI
php-fpm -v; php -v; apachectl -M 2>/dev/null | grep -i php

# Bukti perbaikan di Debian/Ubuntu dan keluarga RHEL (backport tidak mengubah nomor versi)
apt changelog php8.3-fpm 2>/dev/null | grep -m1 CVE-2026-109618
rpm -q --changelog ea-php81-php-cli 2>/dev/null | grep -m1 CVE-2026-109618

# Worker yang masih menjalankan biner lama
grep -l '(deleted)' /proc/[0-9]*/maps 2>/dev/null | head

# Pemeriksaan pasca-patch, sejak 17 Oktober
find /var/www -type f -name '*.php' -newermt '2026-10-17'
grep -rlE 'eval\(|base64_decode\(|shell_exec\(|passthru\(' /var/www

Perintah pemeriksaan mengikuti daftar SecureLayer7 dan saran CISA untuk mengawasi proses PHP yang meluncurkan shell. Satu catatan: kalau log akses Anda berganti tiap minggu, hasil pencarian log yang bersih untuk pekan 17 Oktober sudah tidak membuktikan banyak.

Apa yang paling terancam di hotel, pembayaran, dan aplikasi lama?

Halaman pemesanan kamar atau portal web di depan sistem hotel adalah contoh PHP yang menghadap internet, dan yang seperti itu diserang lebih dulu. Begitu pula alamat kecil penerima notifikasi pembayaran: biasanya ia menyimpan kunci server penyedia di .env, dan penyerang yang sudah bisa menjalankan kode membacanya dalam hitungan detik. Kalau server semacam itu terbuka di internet tanpa tambalan setelah 17 Oktober, ganti kunci penyedia pembayaran sebagai bagian dari bersih-bersih, bukan sebagai pekerjaan susulan.

Aplikasi internal lama adalah kasus yang lebih sulit. Aplikasi CodeIgniter 3 atau Laravel 5 di PHP 7.4 tidak bisa lompat ke 8.3 dalam seminggu; kodenya akan rusak di belasan tempat. Yang bisa dilakukan minggu ini: pakai backport dari distribusi atau cPanel, taruh aplikasi di belakang VPN supaya tidak lagi terjangkau dari internet, lalu rencanakan kenaikan versi bertahap. Artikel tentang menyelamatkan sistem lama memakai urutan itu: stabilkan dulu, baru benahi.

Lapisan di bawah aplikasi yang tidak pernah masuk daftar

PHP tidak tercantum di composer.json, jadi pemindai dependensi tidak melihatnya. Snyk menyatakan terus terang bahwa pemindai open-source miliknya tidak akan melaporkan dua CVE ini karena runtime bukan dependensi yang dideklarasikan, dan pemindaian kontainer melewatkan image resmi php: karena PHP di sana dikompilasi dari kode sumber. Inventaris yang Anda butuhkan justru lebih sederhana dan lebih membosankan: untuk tiap situs, cabang PHP-nya apa, siapa yang memperbarui, dan bagaimana memverifikasinya. Masukkan juga akhir dukungan PHP 8.2 pada 31 Desember 2026, sembilan minggu dari sekarang, ke daftar yang sama.

Pelajaran kedua soal waktu. Cloudflare sudah memasang aturan beberapa jam sebelum rilis; Amazon melihat percobaan empat hari sebelumnya. Kebijakan patch yang menunggu nomor CVE, atau menunggu jendela pemeliharaan bulanan, sudah tidak sesuai dengan kecepatan kejadian seperti ini.

Kalau situs Anda dikelola vendor atau penyedia IT, tanyakan tiga hal minggu ini: cabang PHP mana yang melayani tiap situs, bagaimana mereka membuktikan perbaikannya sudah masuk, dan apakah worker sudah dimulai ulang serta log sudah ditinjau sejak 17 Oktober. Penyedia yang menjawab dalam sehari sedang mengelola server Anda. Yang tidak bisa menjawab, sebatas menyediakan tempat. Kalau di tempat Anda ada aplikasi PHP lama yang tidak ada yang berani menyentuh, saya bersedia memakai sesi perkenalan gratis 15 menit untuk membahas seperti apa kenaikan versi bertahapnya.