Tim PHP pada 21 Oktober 2026 menerbitkan security advisory yang menambal dua kerentanan kritis berpotensi memungkinkan unauthenticated remote code execution. Patch keamanan PHP RCE ini hadir lewat PHP 8.5.12, 8.4.27, 8.3.36, dan 8.2.35. PHP menegaskan update segera karena mitigasi parsial tidak membuat instalasi aman sepenuhnya.
Patch keamanan PHP RCE: versi dan runtime terdampak
PHP menyatakan semua instalasi yang melayani request web berisiko. Daftar runtime mencakup PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, dan LiteSpeed. PHP menempatkan risiko tertinggi pada mod_php karena serangan dapat terjadi sebelum kode aplikasi berjalan. Peringatan itu bukan berarti runtime lain bebas ancaman.
WordPress, Laravel, Symfony, atau framework lain tetap bergantung pada interpreter PHP di server. Memperbarui plugin atau package Composer saja tidak menutup celah di lapisan runtime.
Admin sebaiknya menjalankan php -v pada CLI. Verifikasi juga versi FPM, CGI, atau modul web karena keduanya sering berbeda di hosting shared, panel kontrol, atau image container. Beberapa server menjalankan lebih dari satu pool PHP untuk situs berbeda. Satu vhost sudah patch belum menjamin seluruh properti web aman.
Anda perlu update melalui paket distro resmi, vendor LTS, atau build sumber terpercaya. Restart worker PHP atau web server agar binary patch benar-benar aktif. PHP menyebut distribusi Linux dan vendor LTS menerima patch lebih awal. Tim yang mengandalkan repositori pihak ketiga seperti rpms.remirepo.net sebaiknya beralih ke paket distro atau build sumber agar patch darurat tidak tertunda. Pada Windows, sumber dan binary ada di halaman unduhan resmi PHP dengan changelog per branch.
Dua CVE dan batas penjelasan
CVE-2026-109618 berkaitan dengan RCE via korupsi out-of-memory. Penanganan OOM dapat menginterupsi PHP saat inisialisasi data request internal belum rampung. Proses cleanup lalu dapat memperlakukan data invalid seolah valid.
CVE-2026-109619 menyangkut RCE via stale global state. State internal milik request dapat bertahan setelah PHP melepaskan memori backing. Request berikutnya pada worker yang sama dapat menyentuh state tersebut sebelum inisialisasi normal.
Artikel ini sengaja tidak memuat payload exploit, trigger request, atau uraian memori untuk exploit. Detail teknis penuh ada pada advisory resmi PHP dan entri GHSA terkait. Pemberitahuan pra-rilis PHP pada 20 Oktober 2026 sudah menandai dua kerentanan kritis dengan rating CVSS v4.0 9.2. Vendor hosting sebaiknya menyiapkan upgrade sebelum tanggal rilis.
Kedua CVE menargetkan mekanisme internal request worker. Aplikasi yang memakai opcode cache, upload besar, atau callback berat tetap bergantung pada patch interpreter meski kode aplikasi sudah mengikuti praktik keamanan modern. WordPress core terbaru atau Laravel patch terbaru tidak menutup masalah bila PHP di belakangnya masih versi vulnerable.
PHP EOL dan ecosystem PHP
PHP 8.1 dan versi lebih lama tidak lagi menerima update upstream rutin dari proyek PHP. Distribusi Linux atau vendor LTS tertentu bisa backport perbaikan. Tim keamanan PHP juga menyediakan minimal source backport untuk PHP 7.4, 8.0, dan 8.1 bagi yang membangun dari sumber tanpa akses vendor LTS.
PHP 8.2 akan mencapai end of life pada 31 Desember 2026 menurut catatan rilis 8.2.35. Perencanaan upgrade branch tetap relevan setelah patch darurat ini.
Tim yang baru menangani patch keamanan Symfony Oktober 2026 perlu menambahkan langkah verifikasi interpreter PHP ke playbook yang sama. Pola serupa muncul saat celah RCE ada di lapisan aplikasi, seperti pada cek WordPress Bricksforge setelah RCE. Kali ini sumber masalahnya ada di runtime, bukan plugin tunggal.
Mitigasi patch keamanan PHP RCE sementara
Bila update belum memungkini, advisory PHP mencantumkan langkah pengurangan risiko spesifik per CVE. Contohnya pengaturan memory_limit, batas post_max_size, boundary container, menonaktifkan session.upload_progress, restart worker, serta opsi fatal_error_backtraces pada PHP 8.5. Setiap langkah hanya menutup jalur tertentu. PHP menegaskan update tetap satu-satunya solusi lengkap.
Setelah deploy patch, uji halaman kritis, upload bila ada, dan pantau error log FPM atau Apache. Jika Anda sempat menerapkan mitigasi sementara, catat pengaturan php.ini atau pool FPM yang Anda ubah agar tidak tertinggal setelah upgrade. Tim juga perlu menerapkan proses serupa saat menangani upgrade keamanan CodeIgniter 4.7.5 di stack PHP lain.
Memahami vektor serangan umum pada website membantu tim memprioritaskan monitoring pasca-update tanpa mengganti kewajiban naik versi PHP. Bila bukti eksploitasi aktif muncul di lingkungan Anda, isolasi worker, rotasi kredencial, dan forensik log tetap wajib. Patch mencegah serangan baru, bukan menghapus akses yang mungkin sudah terjadi sebelumnya.
