Pada 21 Oktober 2026, tim PHP merilis pembaruan keamanan untuk mengatasi dua kerentanan kritis, CVE-2026-109618 dan CVE-2026-109619, dengan skor CVSS v4.0 sebesar 9,2 dari 10. Kedua celah ini berpotensi memungkinkan penyerang menjalankan kode berbahaya dari jarak jauh tanpa autentikasi (unauthenticated remote code execution).
Kerentanan tersebut berkaitan dengan pengelolaan memori dan data internal PHP saat memproses permintaan pengguna. Pengguna PHP disarankan segera memperbarui versi PHP ke versi yang telah diperbaiki untuk mengurangi risiko keamanan server.
Apa Kerentanan CVE-2026-109618 & CVE-2026-109619?
Kedua kerentanan ditemukan pada inti PHP (PHP runtime) dan berkaitan dengan pengelolaan memori serta status internal ketika PHP memproses HTTP request. Meskipun mekanisme pemicunya berbeda, keduanya dapat membuka peluang bagi penyerang untuk menjalankan kode berbahaya pada server dalam kondisi tertentu.
CVE-2026-109618 (RCE via OOM Corruption)
CVE-2026-109618 terjadi ketika PHP kehabisan memori (out-of-memory atau OOM) saat memproses request. Pada versi yang rentan, kondisi ini dapat menghentikan proses sebelum data internal selesai disiapkan, sehingga data yang belum siap digunakan bisa salah ditangani saat proses pembersihan memori (cleanup).
Kondisi tersebut dapat dimanfaatkan untuk menjalankan kode dari jarak jauh (Remote Code Execution atau RCE). Menurut advisory resmi PHP, dampak ini telah dikonfirmasi pada konfigurasi Apache mod_php tertentu, termasuk melalui request tanpa autentikasi sebelum kode aplikasi dijalankan.
CVE-2026-109619 (RCE via Stale Global State)
CVE-2026-109619 terjadi ketika PHP masih menyimpan status internal dari request sebelumnya, meskipun memori yang digunakan sudah dibebaskan. Jika request berikutnya menggunakan status tersebut sebelum PHP memperbaruinya, sistem dapat mengakses data yang sudah tidak valid.
Kondisi ini berpotensi dimanfaatkan untuk menjalankan kode dari jarak jauh pada server. Salah satu jalur serangan berkaitan dengan fitur session.upload_progress, tetapi menonaktifkan fitur tersebut saja belum cukup untuk mengatasi seluruh risiko kerentanan ini.
Siapa yang Berisiko Terkena Dampaknya?
Kerentanan ini akan memengaruhi instalasi PHP yang melayani request web, termasuk pada lingkungan berikut:
- Apache mod_php, yaitu integrasi PHP yang berjalan sebagai modul Apache.
- PHP-FPM, yang umum digunakan bersama Nginx atau Apache.
- php-cgi, yaitu PHP yang berjalan melalui antarmuka CGI.
- LiteSpeed, termasuk konfigurasi yang menjalankan aplikasi PHP.
- FrankenPHP, yaitu server aplikasi yang mendukung PHP.
Tingkat risiko dan jalur eksploitasi dapat berbeda berdasarkan konfigurasi server. PHP menyebut Apache mod_php sebagai lingkungan dengan risiko tertinggi karena eksploitasi telah didemonstrasikan sebelum kode aplikasi dijalankan. Hal ini berarti perlindungan pada tingkat aplikasi saja tidak cukup untuk mengatasi masalah tersebut.
Dari sisi aplikasi, website berbasis WordPress, Laravel, CodeIgniter, dan sistem lain yang menggunakan PHP perlu memeriksa versi runtime yang digunakan. Kerentanan ini berada pada implementasi PHP, bukan hanya pada satu CMS atau framework. Karena itu, mengganti plugin atau memperbarui kode aplikasi saja tidak otomatis memperbaikinya apabila runtime PHP yang digunakan masih rentan.
Apa Saja Risiko yang Ditimbulkan?
Kedua kerentanan ini perlu diprioritaskan karena berpotensi menimbulkan beberapa dampak keamanan.
Eksekusi Kode dari Jarak Jauh
Penyerang dapat berpotensi menjalankan kode berbahaya melalui request yang dibuat secara khusus tanpa harus login terlebih dahulu. Jika berhasil, kode tersebut berjalan dengan hak akses proses PHP yang dieksploitasi.
Kebocoran dan Manipulasi Data
Jika proses PHP berhasil diambil alih, penyerang berpotensi mengakses atau memanipulasi data yang dapat dijangkau oleh akun layanan tersebut. Dampaknya bergantung pada hak akses proses, konfigurasi server, dan pemisahan antaraplikasi.
Gangguan Layanan Website
Kondisi kehabisan memori dan kesalahan pemrosesan dapat mengganggu stabilitas worker PHP. Dalam skenario tertentu, proses dapat berhenti atau layanan website mengalami gangguan.
Risiko terhadap Lingkungan Server
Jika proses PHP memiliki akses luas ke file, kredensial, atau layanan lain, eksploitasi dapat memperbesar dampak insiden. Karena itu, pembatasan hak akses dan isolasi antaraplikasi tetap penting sebagai bagian dari pertahanan berlapis. Keberadaan kerentanan tidak otomatis berarti sebuah server telah diserang. Namun, karena dampaknya dapat serius, administrator perlu segera memeriksa versi PHP dan menerapkan pembaruan keamanan.
Baca juga: Tips Tuning PHP-FPM untuk Performa Server Website Lebih Stabil
Versi PHP Terdampak dan Pembaruan yang Tersedia
Tim PHP telah merilis versi yang memperbaiki kedua kerentanan tersebut. Berikut versi perbaikannya.
Versi PHP |
Versi dengan perbaikan |
PHP 8.5 |
8.5.12 |
PHP 8.4 |
8.4.27 |
PHP 8.3 |
8.3.36 |
PHP 8.2 |
8.2.35 |
Pengguna perlu memperbarui PHP ke versi perbaikan yang sesuai dengan cabang versi yang digunakan. Jika menggunakan paket dari distribusi Linux atau vendor dukungan jangka panjang, periksa advisory vendor karena perbaikan dapat didistribusikan melalui paket yang dikelola vendor.
PHP 8.1 dan versi lebih lama tidak lagi menerima pembaruan rutin dari proyek PHP. Meski demikian, beberapa distribusi dan vendor dukungan jangka panjang dapat menyediakan perbaikan backport. Tim PHP juga menyebutkan tersedianya minimal source-backports untuk PHP 7.4, 8.0, dan 8.1. Status perbaikan harus dikonfirmasi kepada vendor atau pengelola paket yang digunakan.
Langkah Mitigasi yang Harus Dilakukan
Pembaruan PHP merupakan satu-satunya solusi yang bisa dilakukan. Jika pembaruan belum dapat dilakukan, beberapa konfigurasi sementara dapat mengurangi paparan terhadap jalur serangan tertentu. Namun, langkah-langkah berikut tidak menjamin instalasi menjadi aman sepenuhnya.
1. Periksa & Perbarui versi PHP
Langkah pertama adalah memeriksa versi PHP yang digunakan. Jika memiliki akses terminal, jalankan perintah berikut:
php -v
Perintah tersebut menampilkan versi PHP CLI. Versi yang digunakan website bisa berbeda, sehingga administrator juga perlu memeriksa PHP-FPM, Apache, LiteSpeed, container, atau control panel hosting.
Selanjutnya, perbarui PHP ke versi yang telah diperbaiki melalui repository resmi sistem operasi, vendor paket, atau mekanisme pembaruan dari penyedia hosting. Setelah pembaruan, restart layanan terkait jika diperlukan dan verifikasi bahwa website benar-benar menggunakan versi yang sudah diperbaiki.
2. Mitigasi Sementara untuk CVE-2026-109618
CVE-2026-109618 berkaitan dengan kegagalan alokasi memori. Jika pembaruan belum memungkinkan, advisory PHP menyebutkan beberapa langkah berikut.
Atur memory_limit=-1 secara administratif
Pengaturan ini menghilangkan batas memori per request yang dapat memicu kondisi kehabisan memori secara terkontrol melalui batas PHP. Contoh penerapannya adalah melalui konfigurasi administratif PHP-FPM pool atau Apache. Pastikan pengaturan tersebut tidak dapat ditimpa aplikasi dan tidak ada konfigurasi lain yang kembali menetapkan batas memori terbatas.
Namun, langkah ini tidak menutup seluruh jalur serangan. Kegagalan alokasi memori pada tingkat sistem operasi masih dapat memicu kondisi rentan.
Batasi ukuran dan kompleksitas request
Advisory PHP merekomendasikan pembatasan post_max_size dengan nilai konservatif:
-
Gunakan post_max_size = 8M untuk aplikasi yang tidak memerlukan unggahan file.
-
Gunakan post_max_size = 32M jika aplikasi membutuhkan unggahan file.
-
Pastikan upload_max_filesize lebih kecil daripada post_max_size.
Selain itu, terapkan pembatasan di tingkat web server atau reverse proxy terhadap ukuran request setelah didekodekan, jumlah field input, jumlah bagian multipart, jumlah header, dan kedalaman struktur input. Pembatasan tersebut juga harus mencakup request yang tidak memiliki Content-Length yang dapat digunakan.
Gunakan batas container atau cgroup secara hati-hati
Batas sumber daya container atau cgroup dapat digunakan untuk membantu membatasi dampak terhadap ketersediaan layanan. Namun, konfigurasi ini bukan pengganti pembaruan PHP. Hindari penggunaan RLIMIT_AS atau RLIMIT_DATA sebagai mitigasi untuk kerentanan ini karena kegagalan alokasi yang ditimbulkannya dapat memicu jalur OOM yang rentan.
3. Mitigasi Sementara untuk CVE-2026-109619
CVE-2026-109619 berkaitan dengan status internal yang tertinggal setelah memori dibebaskan. Beberapa langkah berikut dapat mengurangi risiko pada jalur serangan tertentu.
Nonaktifkan session upload progress
Jika aplikasi tidak membutuhkan fitur ini, tambahkan pengaturan berikut pada konfigurasi PHP yang diterapkan sebelum request diproses:
session.upload_progress.enabled=0
Pengaturan dapat diterapkan melalui php.ini, konfigurasi PHP-FPM pool, atau konfigurasi server yang sesuai. Setelah perubahan, restart seluruh worker PHP agar konfigurasi berlaku. Jangan mengandalkan ini_set() atau konfigurasi .user.ini pada PHP-FPM untuk mitigasi ini karena pengaturan harus berlaku sebelum proses parsing request dimulai.
Khusus PHP 8.5, nonaktifkan fatal error backtraces
Untuk PHP 8.5, advisori menyebutkan pengaturan berikut untuk memblokir jalur tertentu yang telah dikonfirmasi:
fatal_error_backtraces=0
Terapkan melalui konfigurasi yang sesuai dan restart seluruh worker. Mitigasi ini hanya menutup jalur fatal backtrace yang telah dikonfirmasi, bukan semua kemungkinan eksploitasi.
Audit pengaturan dan error yang dapat dipicu penyerang
Periksa pengaturan per request yang tidak valid atau sudah deprecated, terutama jika menghasilkan diagnostik sebelum proses inisialisasi selesai. Audit juga jalur aplikasi yang dapat memicu fatal error atau timeout, termasuk callback, pemrosesan unggahan dan impor file, serta proses pembersihan setelah request selesai.
Pengaturan seperti error_reporting, display_errors, dan operator @ bukan mitigasi yang efektif untuk kerentanan ini. Menyembunyikan pesan error tidak mencegah PHP mengakses status internal yang sudah tidak valid.
4. Periksa Log & Indikasi Mencurigakan
Setelah pembaruan atau penerapan mitigasi, periksa log PHP dan web server untuk membantu mengidentifikasi gangguan maupun aktivitas yang tidak biasa.
Beberapa hal yang layak ditinjau antara lain:
- Lonjakan error kehabisan memori atau Allowed memory size exhausted.
- Worker PHP-FPM yang berhenti secara tidak normal atau proses Apache yang mengalami crash.
- Request multipart yang tidak biasa, termasuk request dengan banyak bagian atau field bertingkat.
- Proses anak yang tidak dikenal dan dijalankan oleh PHP atau web server.
- File PHP, plugin, tema, atau tugas terjadwal baru yang tidak dikenal.
Indikator tersebut tidak selalu membuktikan eksploitasi, tetapi dapat menjadi dasar pemeriksaan lebih lanjut. Tidak ditemukannya indikator dalam log juga bukan jaminan bahwa server tidak pernah diserang. Jika terdapat indikasi kompromi, lakukan investigasi keamanan. Memperbarui PHP memperbaiki kerentanan, tetapi tidak otomatis menghapus file berbahaya atau perubahan yang mungkin telah dibuat penyerang sebelum pembaruan.
5. Rencanakan Migrasi dari PHP
Jika server menggunakan PHP 8.1 atau versi lebih lama, verifikasi ketersediaan perbaikan melalui vendor paket atau penyedia dukungan jangka panjang. Untuk penggunaan jangka panjang, rencanakan migrasi ke versi PHP yang masih didukung. Periksa kompatibilitas framework, CMS, plugin, ekstensi, dan dependensi sebelum menerapkannya pada server produksi.
Pengujian di lingkungan staging dapat membantu mengidentifikasi masalah kompatibilitas lebih awal dan mengurangi risiko gangguan layanan saat migrasi.
Catatan Penting: PHP 8.2 Akan Mencapai End of Life
PHP 8.2 dijadwalkan mencapai end of life pada 31 Desember 2026. Setelah masa dukungan berakhir, versi tersebut tidak lagi menerima perbaikan keamanan rutin dari proyek PHP.
Pengguna PHP 8.2 sebaiknya mulai merencanakan migrasi ke versi yang lebih baru dan masih didukung. Perencanaan sejak awal memberi waktu untuk menguji kompatibilitas aplikasi, memperbarui dependensi, dan mengurangi risiko gangguan operasional.
Baca juga:Optimasi Website dengan PHP-FPM dan Keunggulan Utamanya
Kesimpulan
CVE-2026-109618 dan CVE-2026-109619 merupakan dua kerentanan kritis pada PHP yang berkaitan dengan pengelolaan memori dan status internal request. Keduanya berpotensi memungkinkan eksekusi kode dari jarak jauh tanpa autentikasi dalam kondisi tertentu.
Pemilik website, developer, dan administrator server perlu segera memeriksa versi PHP yang digunakan dan memperbaruinya ke versi yang telah diperbaiki. Jika pembaruan belum dapat dilakukan, konfigurasi sementara dapat mengurangi paparan pada jalur serangan tertentu, tetapi tidak menggantikan pembaruan keamanan.
Menjaga runtime PHP tetap diperbarui, membatasi hak akses proses, memeriksa log, dan merencanakan migrasi versi merupakan bagian penting dari pengelolaan keamanan infrastruktur digital. Dengan langkah yang terencana, organisasi dapat mengurangi risiko terhadap website dan aplikasi yang bergantung pada PHP.
Referensi
PHP.net. (2026). PHP Security Announcement. Baca selengkapnya
PHP-src GitHub. CVE-2026-109618: RCE via OOM Corruption. Baca advisori
PHP-src GitHub. CVE-2026-109619: RCE via Stale Global State. Baca advisori
