Administrator situs web dan pengelola server diminta segera memeriksa serta memperbarui instalasi PHP menyusul pengungkapan dua kerentanan kritis, yakni CVE-2026-109618 dan CVE-2026-109619. Keduanya memperoleh skor CVSS v4.0 9,2 dan menjadi perhatian karena rincian teknisnya beredar beberapa jam sebelum pembaruan keamanan resmi dirilis.
Tim keamanan PHP sebelumnya mengumumkan rilis keamanan di luar jadwal untuk 21 Oktober 2026 pukul 14.00 UTC. Temuan yang dibahas berkaitan dengan fitur session.upload_progress, sebuah mekanisme pemantauan kemajuan unggahan yang telah tersedia sejak PHP 5.4.0 dan secara bawaan aktif pada banyak instalasi.
Jutaan server PHP terlihat dari internet
Analisis Internet Scanning VirusTotal memperkirakan sekitar 5,1 juta alamat IP menjalankan PHP. Dari jumlah itu, sekitar 3,8 juta masih memiliki sedikitnya satu port yang terbuka ketika pemetaan dilakukan pada 21 Oktober 2026.
Namun, hanya sekitar 1,1 juta server yang secara terbuka mencantumkan versi PHP melalui header HTTP seperti X-Powered-By. Artinya, kira-kira empat dari lima server PHP tidak mengumumkan nomor versinya. Penyembunyian itu dapat terjadi karena pengaturan expose_php = Off, penghapusan header, atau penggunaan reverse proxy.
Ketiadaan banner versi bukan berarti teknologi PHP tidak dapat dikenali. Jejak lain seperti cookie PHPSESSID, karakteristik aplikasi WordPress, Laravel dan Nextcloud, serta header khusus framework masih dapat digunakan untuk mengenali layanan berbasis PHP.
Mayoritas versi yang terlihat sudah berstatus EOL
Data VirusTotal memperlihatkan persoalan yang lebih besar dari sekadar dua CVE tersebut. Di antara server yang mengungkapkan versinya, sekitar 272 ribu menjalankan cabang PHP yang masih didukung, yaitu PHP 8.2 hingga 8.5.
Sebaliknya, sekitar 758 ribu menjalankan cabang PHP 5.4 hingga 8.1 yang telah mencapai end of life (EOL). Cabang-cabang tersebut tidak lagi memperoleh perbaikan keamanan resmi dari proyek PHP. PHP 7.4 sendiri terdeteksi pada sekitar 187 ribu alamat IP, sedangkan PHP 5.4 terlihat pada sekitar 119 ribu IP.
Sekitar 88 ribu server lainnya menggunakan PHP 5.2 atau 5.3. Kedua versi lama itu mendahului keberadaan fitur session.upload_progress, tetapi tetap memiliki risiko keamanan serius karena sudah sangat lama tidak didukung.
Bahkan sistem yang relatif mutakhir hanya memiliki waktu respons yang sempit. Sekitar 85 ribu alamat IP teridentifikasi memakai rilis terbaru sebelum pembaruan darurat, yaitu PHP 8.2.34, 8.3.35, 8.4.26, dan 8.5.11.
WordPress hingga Laravel masuk permukaan paparan
Dari sisi perangkat lunak server web, Apache terlihat pada sekitar 2,9 juta host PHP dan nginx pada sekitar 1,48 juta host. LiteSpeed berada di urutan berikutnya dengan kurang lebih 90 ribu host.
Untuk lapisan aplikasi, WordPress mendominasi dengan sekitar 538 ribu alamat IP, disusul Laravel sekitar 141 ribu dan Nextcloud sekitar 107 ribu. Roundcube serta phpMyAdmin menambah sekitar 25 ribu sasaran bernilai tinggi karena berkaitan dengan webmail dan administrasi basis data.
Paparan juga terkonsentrasi secara geografis dan pada penyedia infrastruktur tertentu. Amerika Serikat mencakup sekitar 920 ribu host PHP dengan sedikitnya satu port terbuka. AWS, DigitalOcean, Alibaba, OVHcloud, dan Hetzner termasuk penyedia yang menampung bagian besar infrastruktur tersebut. Konsentrasi ini dapat membantu mitigasi apabila penyedia segera menerapkan perubahan konfigurasi atau aturan WAF secara luas.
Risiko tidak berhenti pada layanan web
Server PHP kerap mengekspos layanan lain pada alamat IP yang sama. Sekitar 394 ribu host juga membuka port 22 yang umumnya digunakan SSH, sekitar 233 ribu membuka port 3306 untuk MySQL, dan sekitar 68 ribu membuka port 3389 untuk Remote Desktop Protocol.
Kombinasi layanan tersebut penting dalam penentuan prioritas. Server PHP dengan database atau akses administratif yang langsung terbuka ke internet dapat menimbulkan dampak lebih besar apabila aplikasi web berhasil ditembus.
Langkah mitigasi yang perlu dilakukan
- Segera pasang pembaruan. Gunakan rilis PHP yang telah diperbaiki untuk cabang 8.2, 8.3, 8.4, atau 8.5 melalui php.net maupun repositori resmi sistem operasi.
- Rencanakan migrasi dari versi EOL. PHP 8.1 dan versi yang lebih lama tidak lagi menerima perbaikan keamanan resmi. Periksa apakah distributor atau vendor menyediakan backport sambil menyiapkan peningkatan ke cabang yang didukung.
- Nonaktifkan upload progress sebagai langkah sementara. Sebelum pembaruan dapat diterapkan, atur
session.upload_progress.enabled = Offdiphp.iniatau konfigurasi pool, lalu muat ulang PHP-FPM, Apache, atau LSAPI. Langkah ini dapat mengganggu indikator kemajuan unggahan yang bergantung pada fitur tersebut. - Jangan menganggap mitigasi sebagai pengganti patch. Analisis komunitas menunjukkan bahwa penonaktifan fitur upload progress mungkin tidak menutup seluruh vektor. Pembaruan PHP tetap menjadi perlindungan utama.
- Batasi permintaan multipart. Apabila aplikasi tidak membutuhkan unggahan berkas, blokir atau periksa permintaan
multipart/form-datasebelum mencapai PHP. - Pastikan WAF tidak dapat dilewati. Aturan pada layanan edge hanya efektif bila server asal tidak dapat diakses langsung dari internet. Batasi koneksi origin hanya dari alamat IP reverse proxy atau CDN yang digunakan.
- Prioritaskan aset berisiko tinggi. Dahulukan sistem yang mengekspos PHP bersama SSH, MySQL, RDP, panel administrasi, atau aplikasi bernilai tinggi seperti webmail dan pengelola database.
- Periksa log dan lakukan threat hunting. Cari aktivitas unggahan multipart yang tidak lazim, pembuatan sesi mencurigakan, perubahan file, proses PHP yang anomali, dan koneksi keluar yang tidak dikenal.
Data pemetaan bukan bukti kerentanan
VirusTotal menegaskan bahwa angka-angka tersebut menggambarkan jejak PHP yang dapat diamati dari internet, bukan jumlah host yang telah dipastikan rentan. Tidak semua server yang terdeteksi otomatis terdampak, sebab status kerentanan tetap bergantung pada versi, konfigurasi, backport vendor, dan kontrol keamanan yang diterapkan.
Meski demikian, skala penggunaan PHP dan banyaknya instalasi EOL menunjukkan bahwa jendela paparan dapat sangat besar. Organisasi sebaiknya tidak hanya memeriksa banner versi, tetapi juga melakukan inventaris internal, memastikan seluruh cabang PHP tercatat, dan memverifikasi pembaruan pada setiap lingkungan produksi maupun pengembangan.
