Website Anda tampak normal, tetapi di lapisan yang tidak terlihat dari dashboard, PHP di server baru saja mendapat perbaikan untuk dua celah yang serius. Tim keamanan PHP merilis pembaruan pada 21 Oktober 2026 untuk menutup dua kerentanan PHP yang dapat memungkinkan penyerang menjalankan kode di server tanpa perlu login. Karena PHP menjalankan banyak website di dunia, termasuk WordPress, kabar ini relevan bagi sebagian besar pemilik website.
Dalam artikel ini, kami akan membahas tentang dua temuan kerentanan kritis pada PHP, apa yang sudah Rumahweb lakukan, cara mengecek versi PHP, dan langkah yang perlu Anda ambil sesuai jenis layanan Anda.
Ringkasan Cepat
- PHP merilis versi 8.5.12, 8.4.27, 8.3.36, dan 8.2.35 pada 21 Oktober 2026 untuk memperbaiki dua kerentanan kritis, CVE-2026-109618 dan CVE-2026-109619. Keduanya dapat memungkinkan remote code execution (RCE) tanpa autentikasi.
- Semua instalasi PHP yang melayani web berisiko, termasuk PHP-FPM, mod_php, php-cgi, FrankenPHP, dan LiteSpeed. Tim PHP menyatakan tidak ada mitigasi yang lengkap dan update adalah satu-satunya pilihan yang aman.
- Rumahweb telah menerapkan patch di server hosting. Di server CloudLinux, perbaikan diterapkan lewat backport sehingga nomor versi PHP bisa tetap sama.
- Pengguna VPS dan dedicated server perlu memeriksa semua versi PHP yang terpasang dan menerapkan patch sendiri.
Apa yang Diumumkan Tim Keamanan PHP?
Linimasa 20 sampai 26 Oktober 2026
- 20 Oktober. Tim keamanan PHP memberi pemberitahuan awal tentang rilis keamanan yang akan datang untuk dua kerentanan kritis, masing-masing berskor CVSS v4.0 9.2.
- 21 Oktober. PHP merilis 8.5.12, 8.4.27, 8.3.36, dan 8.2.35 beserta security advisory. Waktunya sesuai jadwal, yaitu sekitar pukul 14:00 UTC atau 21:00 WIB.
- 23 Oktober. PHP menerbitkan advisory informasional tentang session upload progress yang terkait CVE-2026-115560 (dibahas di bagian akhir artikel).
- 26 Oktober. PHP memperbarui build Windows (8.5.12-1, 8.4.27-1, 8.3.36-1, dan 8.2.35-1) dengan Brotli 1.2.1 untuk memperbaiki CVE-2026-111497. Ini kerentanan terpisah di dekompresi Brotli yang bisa terjangkau lewat ekstensi cURL jika dekompresi otomatis respons HTTP diaktifkan. Fitur ini mati secara default, tetapi aplikasi dan library HTTP dapat mengaktifkannya.
Versi PHP yang Memuat Perbaikan
| Cabang PHP | Versi dengan perbaikan | Catatan |
|---|---|---|
| 8.5 | 8.5.12 | Didukung |
| 8.4 | 8.4.27 | Didukung |
| 8.3 | 8.3.36 | Didukung |
| 8.2 | 8.2.35 | Mencapai end of life pada 31 Desember 2026 |
| 8.1 dan lebih lama | Tidak ada rilis resmi dari proyek PHP | Lihat bagian “Jika Masih Memakai PHP 8.1 atau Lebih Lama” |
| 8.6.0 RC4 | Memuat perbaikan | Hanya untuk pengujian, jangan dipakai di produksi |
Penjelasan CVE-2026-109618 dan CVE-2026-109619
Penjelasan berikut mengikuti tingkat detail yang dipublikasikan tim PHP. Rincian teknis lengkap tersedia di advisory resminya, yaitu GHSA-w8hw-w9fx-j79w dan GHSA-6wmf-4rv5-p3rp.
Also Read
CVE-2026-109618, RCE karena Kerusakan Data saat Memori Habis
Saat memori server habis, PHP bisa terhenti pada saat data internal sebuah request baru terisi sebagian. Proses pembersihan request setelah itu dapat menganggap data yang belum utuh tersebut sebagai data yang valid. Kondisi inilah yang membuka jalan bagi eksekusi kode.
CVE-2026-109619, RCE karena State Lama yang Masih Terpakai
Pada celah ini, data internal milik satu request bisa tetap tersisa setelah memori pendukungnya dibebaskan. Request berikutnya yang ditangani worker yang sama dapat memakai data usang itu sebelum proses inisialisasi normal mengatur ulangnya.
Siapa yang Berisiko?
Semua instalasi PHP yang melayani permintaan web berisiko, baik PHP-FPM, Apache dengan mod_php, php-cgi, FrankenPHP, maupun LiteSpeed. Risikonya paling tinggi pada mod_php, karena tim PHP menyebut adanya eksploitasi yang didemonstrasikan, yaitu satu request tanpa login dapat memicu serangan sebelum kode aplikasi dijalankan.
Karena itu, pada skenario tersebut perlindungan di level aplikasi, misalnya plugin keamanan, tidak bisa menjadi pengganti update PHP. Kedua celah berskor CVSS v4.0 9.2, yang masuk kategori kritis.
Mengapa Update WordPress atau Plugin Tidak Memperbaiki Celah Ini
PHP bukan bagian dari WordPress. PHP adalah perangkat lunak server yang menjalankan WordPress dan aplikasi web lainnya, dan umumnya dipasang serta dikelola penyedia hosting. Konsekuensinya, pembaruan otomatis WordPress, plugin, atau tema tidak mengubah versi PHP di server. Memperbarui CMS tetap penting untuk keamanan secara umum, tetapi perbaikan untuk kedua CVE ini hanya bisa datang dari pembaruan PHP itu sendiri.
Apa yang Sudah Rumahweb Lakukan?
Dari dua rilis pengumuman tersebut, Rumahweb melakukan beberapa tindakan penting untuk menutup celah keamanan PHP pada layanan shared hosting. Berikut beberapa hal yang kami lakukan:
1. Mendisable session.upload_progress.enabled pada server
Langkah pertama yang dilakukan Rumahweb adalah menonaktifkan pengaturan session.upload_progress.enabled di server hosting. Tim PHP mencantumkan pengaturan ini sebagai mitigasi untuk CVE-2026-109619, lalu menyarankannya juga terkait CVE-2026-115560.
Dampaknya, fitur progres upload berbasis sesi PHP tidak berfungsi, sehingga aplikasi yang memakai fitur tersebut perlu menyesuaikan. Langkah ini melengkapi, bukan menggantikan, patch keamanan yang dijelaskan berikut.
2. Versi PHP Default Dinaikkan dari 7.4 ke 8.4
Selain patch keamanan, versi PHP default (native) di server hosting diperbarui dari PHP 7.4 menjadi PHP 8.4. Perubahan ini hanya berlaku untuk konfigurasi PHP default. Jika sebelumnya Anda memilih versi PHP tertentu lewat PHP Selector, versi tersebut tidak berubah.
3. Patch Keamanan di Seluruh Server Hosting
Rumahweb telah memperbarui patch keamanan PHP pada seluruh server hosting ke versi yang sudah diperbaiki, sesuai ketersediaan patch, untuk meminimalkan risiko akibat kedua kerentanan ini.
Mengapa Versi PHP Bisa Tidak Berubah?
Di server hosting Rumahweb yang memakai CloudLinux, pembaruan keamanan PHP diterapkan lewat backport. Artinya, perbaikan dimasukkan ke paket PHP yang sudah ada tanpa mengubah nomor versi upstream ke versi terbaru. Versi PHP yang memperoleh perbaikan pada Alt-PHP dan EA-PHP mencakup PHP 5.2 sampai 8.5.
Akibatnya, nomor versi saja belum tentu menunjukkan apakah server sudah diperbaiki. Namun, hingga artikel ini diterbitkan, semua versi PHP telah berhasil kami update ke versi terbaru.
Bagaimana Cara Mengecek Versi PHP Yang Aktif di Hosting?
Bagi Anda yang menggunakan layanan shared hosting dengan cPanel, cara termudah untuk memastikan versi PHP yang digunakan adalah dengan membuat file phpinfo. Berikut contoh pembuatannya:
- Buatlah file dengan nama info.php di directory root domain Anda.
- Isi file tersebut dengan script phpinfo seperti berikut:
<?php
phpinfo();
?>Setelah itu, akses file tersebut melalui url https://namadomainanda/info.php.
Bagi anda pengguna layanan VPS, cek versi PHP juga bisa mengikuti cara yang sama seperti di atas. Namun, Anda juga bisa menggunakan terminal (ssh) untuk pengecekannya. Berikut contoh command prompt yang bisa digunakan;
php -vPerintah ini menampilkan versi PHP untuk command line, yang bisa berbeda dengan versi yang dipakai web server. Selain itu, pada sistem yang memakai backport, nomor versi tidak mencerminkan status patch. Jika paket PHP Anda berasal dari vendor, periksa changelog paketnya dan cari nomor CVE, selama vendor mencantumkannya.
rpm -q --changelog nama-paket-php | grep -i CVE-2026-109618
apt changelog nama-paket-php | grep -i CVE-2026-109618Perintah pertama untuk distribusi berbasis RPM dan yang kedua untuk Debian atau Ubuntu. Ganti nama-paket-php dengan nama paket yang terpasang di server Anda.
Apa yang Harus Dilakukan Pemilik Website?
Berikut adalah beberapa hal yang dapat Anda lakukan untuk memastikan aplikasi dapat berfungsi dengan baik dan aman dari issue php ini.
Karena Rumahweb sudah menerapkan patch di server hosting, Anda tidak perlu menambal PHP sendiri. Yang perlu Anda lakukan adalah sebagai berikut.
- Periksa versi PHP yang dipakai website Anda melalui phpinfo atau melalui konfigurasi versi php di cPanel.
- Pastikan website berjalan normal setelah perubahan default PHP. Jika ada kendala, sesuaikan versi PHP seperti dijelaskan di atas.
- Gunakan branch PHP yang masih didukung. PHP 8.3, 8.4, dan 8.5 saat ini didukung, sedangkan PHP 8.2 berakhir dukungannya pada 31 Desember 2026.
- Perbarui CMS, plugin, dan tema ke versi terbaru agar kompatibel dan aman.
- Hubungi tim support jika Anda ragu dengan status website Anda.
Pengguna VPS atau Dedicated Server
Pada VPS dan dedicated server, Andalah yang bertanggung jawab menerapkan patch update. Langkah yang disarankan sebagai berikut.
- Periksa semua versi PHP yang terpasang dan dipakai oleh website atau aplikasi, karena satu server bisa menjalankan beberapa versi sekaligus.
- Terapkan patch untuk CVE-2026-109618 dan CVE-2026-109619 pada setiap versi yang terdampak. Gunakan pembaruan paket dari vendor Anda (distribusi Linux, CloudLinux, atau panel kontrol), atau pasang versi 8.5.12, 8.4.27, 8.3.36, atau 8.2.35. Vendor Linux dan LTS telah menerima patch lebih awal, jadi cek paket terbaru dari mereka.
- Restart PHP-FPM atau web server agar proses yang berjalan memakai versi baru.
- Verifikasi hasilnya lewat versi atau changelog paket, lalu uji website.
- Pertimbangkan migrasi ke versi PHP yang masih mendapat dukungan keamanan reguler jika Anda masih memakai versi lama, dengan tetap memperhatikan kompatibilitas aplikasi.
Jika Anda memakai PHP di Windows, gunakan build terbaru bersufiks -1 yang memuat Brotli 1.2.1.
Jika belum bisa update segera pada VPS
Tim PHP menegaskan bahwa langkah berikut hanya mengurangi paparan pada jalur serangan tertentu dan tidak membuat instalasi aman. Pasang di php.ini, pool PHP-FPM, atau konfigurasi server, lalu restart semua worker.
| Pengaturan | Tujuan | Catatan |
|---|---|---|
memory_limit=-1 | Menghilangkan kegagalan batas memori PHP yang dipakai CVE-2026-109618 | Terapkan agar aplikasi tidak bisa menimpanya, misalnya lewat php_admin_value. Satu request bisa memakai seluruh memori yang tersedia, dan kegagalan alokasi memori di level bawah masih bisa mencapai jalur yang rentan |
post_max_size rendah | Membatasi ukuran request. PHP menyarankan 8M untuk aplikasi tanpa upload file dan 32M jika upload diperlukan | upload_max_filesize harus di bawah post_max_size |
session.upload_progress.enabled=0 | Memblokir jalur sesi yang dipakai pada serangan CVE-2026-109619 yang telah diverifikasi | Fitur progres upload berbasis sesi tidak akan berfungsi. Tidak memblokir varian lain |
fatal_error_backtraces=0 | Pada PHP 8.5, memblokir jalur backtrace fatal error yang telah dikonfirmasi | Fatal error tidak lagi menyertakan backtrace |
Gunakan batas memori container atau cgroup sebagai pembatas ketersediaan, dan jangan menggantinya dengan RLIMIT_AS atau RLIMIT_DATA karena justru bisa memicu kegagalan alokasi yang rentan.
Jika Masih Memakai PHP 8.1 atau Lebih Lama
PHP 8.1 dan versi yang lebih lama tidak lagi menerima rilis dari proyek PHP. Meski begitu, tim PHP menyediakan backport source minimal untuk PHP 7.4, 8.0, dan 8.1 bagi yang membangun dari source, dan sebagian vendor Linux serta LTS menyediakan backport sendiri. Di server hosting Rumahweb yang memakai CloudLinux, perbaikan untuk versi lama diterapkan lewat backport seperti dijelaskan di atas.
Meskipun begitu, versi lama tetap bukan solusi jangka panjang. Rencanakan migrasi ke cabang yang masih didukung, uji dulu di lingkungan staging, dan pastikan aplikasi, tema, dan plugin kompatibel.
Kerentanan Lanjutan: CVE-2026-115560 dan Session Upload Progress
Update ke 8.5.12, 8.4.27, 8.3.36, atau 8.2.35 tidak memperbaiki CVE-2026-115560, kerentanan terpisah yang terkait session upload progress. PHP menyarankan menonaktifkan session.upload_progress.enabled=0 sampai rilis bugfix reguler berikutnya, dan advisory lengkapnya akan terbit bersama rilis tersebut. Jika Anda sudah menerapkan pengaturan itu sebagai mitigasi untuk CVE-2026-109619, pertahankan.
Menurut PHP, celah ini hanya bisa terjadi pada kombinasi konfigurasi dan kode aplikasi yang tidak lazim. Aplikasi harus mengatur session.serialize_handler ke php_binary atau php_serialize di konfigurasi, lalu mengubahnya ke php saat runtime dengan ini_set() sebelum memanggil session_start(), sementara session upload progress masih aktif. Aplikasi yang tidak pernah mengubah serialize handler saat runtime bisa tetap mengaktifkan fitur tersebut.
Pengaturan ini perlu diterapkan di level server, yaitu di php.ini, pool PHP-FPM, atau konfigurasi server, bukan lewat ini_set() atau .user.ini. Jika Anda memakai hosting, tanyakan kepada penyedia apakah pengaturan ini sudah diterapkan. Jika Anda mengelola server sendiri, terapkan dan restart semua worker.
Seperti yang kami sampaikan, session.upload_progress pada layanan shared hosting telah kami disable sejak tanggal 21 Oktober setelah release 2 CVE ini dipublikasi.
FAQ
Berikut pertanyaan populer tentang kerentanan PHP CVE-2026-109618 dan CVE-2026-109619.
Apa itu CVE-2026-109618 dan CVE-2026-109619?
Keduanya adalah kerentanan kritis di PHP dengan skor CVSS v4.0 9.2 yang dapat memungkinkan remote code execution tanpa autentikasi, dan diperbaiki pada PHP 8.5.12, 8.4.27, 8.3.36, dan 8.2.35.
Apakah update WordPress atau plugin cukup memperbaiki kerentanan PHP ini?
Tidak. PHP adalah perangkat lunak server, jadi update WordPress, plugin, dan tema tidak mengubah versi PHP. Perbaikan harus diterapkan pada PHP di level server.
Mengapa nomor versi PHP saya tidak berubah padahal sudah dipatch?
Pada sistem yang memakai backport, seperti CloudLinux, perbaikan dimasukkan ke paket PHP yang ada tanpa mengubah nomor versi upstream. Karena itu, nomor versi saja belum tentu menunjukkan status patch.
Apakah PHP 8.1 atau yang lebih lama aman?
PHP 8.1 ke bawah tidak lagi menerima update dari proyek PHP, sehingga keamanannya bergantung pada backport dari vendor. Pastikan lingkungan Anda menerapkan backport tersebut, atau pindah ke versi yang masih didukung.
Apa yang harus dilakukan pengguna VPS atau dedicated server?
Periksa semua versi PHP yang terpasang, terapkan patch untuk kedua CVE pada setiap versi terdampak, restart PHP-FPM atau web server, lalu verifikasi hasilnya. Pertimbangkan migrasi ke versi yang masih didukung.
Penutup
Kerentanan PHP CVE-2026-109618 dan CVE-2026-109619 adalah celah yang serius karena dapat memungkinkan eksekusi kode tanpa login, dan tim PHP menegaskan bahwa update adalah satu-satunya pilihan yang aman. Rumahweb telah menerapkan patch di server hosting, sedangkan pengguna VPS dan dedicated server perlu memeriksa dan memperbarui PHP sendiri.
Jangan lupa bahwa update WordPress tidak memperbaiki celah ini, dan nomor versi PHP pada sistem backport bisa tidak berubah.
Referensi
- PHP.net, News Archive 2026 (pengumuman rilis, security advisory, dan advisory informasional)
- GitHub Security Advisory GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
- GitHub Security Advisory GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
- PHP 8.5.12 release notes
- PHP.net, Supported Versions
- Wordfence, PSA: Upcoming Critical PHP Security Release.
- Rumahweb, Pemberitahuan Pembaruan Keamanan PHP dan Penyesuaian Versi PHP.
- Cloudlinux Statuspage
- cPanel. Critical-PHP-Security-Release
