Baru-baru ini, ekosistem pengembangan web diguncang oleh terungkapnya dua kerentanan tingkat kritis dengan skor CVSS 9.2 pada inti PHP. Kerentanan ini memungkinkan penyerang melakukan Remote Code Execution (RCE) server takeover secara penuh untuk menjalankan kode berbahaya bahkan tanpa memerlukan autentikasi apa pun.
Dua kerentanan ini didokumentasikan dalam GitHub Security Advisories CVE-2026-109619 dan CVE-2026-109618. Keduanya merujuk pada kelemahan fundamental tentang bagaimana PHP menangani manajemen memori ketika berhadapan dengan eror atau interupsi sistem, terutama di lingkungan seperti mod_php dan PHP-FPM.
Membedah Dua Celah Keamanan PHP#
Masalah utama dari kedua kerentanan ini berakar dari cara kerja internal PHP (terutama pada lingkungan worker yang hidup secara persisten seperti PHP-FPM atau mod_php) dalam mengelola alokasi memori dan state ketika memproses request secara bersamaan.
1. RCE via Stale Global State CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp)#
Kerentanan pertama mengeksploitasi memori yang sudah dibebaskan (Use-After-Free / UAF) melalui state global pada worker PHP yang tidak sempat dibersihkan.
Bagaimana kerentanan ini bekerja?#
Dalam arsitekturnya, sebuah worker PHP akan terus hidup (persisten) untuk melayani berbagai request HTTP secara bergantian. Worker ini menyimpan beberapa konfigurasi dan status (state) global seperti informasi eror, sesi (session), atau ekstensi yang menunjuk ke memori milik request yang sedang berjalan. Idealnya, sebelum memori request dibebaskan, state global ini wajib di-reset.
Namun, ketika request tersebut terhenti secara tiba-tiba oleh eror fatal (seperti gagal kompilasi, kehabisan memori, atau maximum execution time exceeded), siklus hidup terputus prematur. PHP kemudian membebaskan memori dari request tersebut, tetapi lupa me-reset referensinya. Akibatnya, worker tersebut menahan dangling pointer penunjuk ke alamat memori yang sudah kedaluwarsa.
Ketika penyerang mengirimkan request kedua ke worker yang sama, komponen tertentu seperti proses pembacaan file konfigurasi INI atau fitur session upload progress akan mengakses pointer yang rusak tadi sebelum inisialisasi normal bekerja. Dengan memanipulasi susunan memori (heap layout), penyerang dapat menyusupkan dan mengeksekusi payload milik mereka.
2. RCE via OOM Corruption CVE-2026-109618 (GHSA-w8hw-w9fx-j79w)#
Kerentanan kedua juga berakar dari manajemen memori, namun spesifik menyasar mekanisme Out-of-Memory (OOM) bawaan PHP.
Bagaimana kerentanan ini bekerja?#
Secara historis, saat batas memori (memory_limit) terlampaui, PHP menggunakan perintah tingkat sistem yang disebut longjmp() untuk “melompat” keluar dari rutinitas yang sedang berjalan dan langsung menuju ke prosedur penutupan request (shutdown procedure).
Kelemahan terjadi jika longjmp() ini tereksekusi sangat awal (saat memori request belum terinisialisasi secara sempurna). Penyerang mengeksploitasi celah ini dengan sengaja menguras alokasi memori PHP secepat mungkin. Caranya adalah dengan membanjiri server melalui muatan multipart form data yang ekstrem seperti mengirimkan jumlah header tak terbatas atau menumpuk nama field input dalam jumlah masif.
Begitu PHP kehabisan memori saat mem-parsing form ini, eksekusi dipaksa melompat ke prosedur penutupan. Celakanya, prosedur penutupan ini akan mencoba membaca data request yang berantakan dan kondisinya korup akibat terpotong OOM tadi. Kondisi memori yang korup inilah yang dimanfaatkan peretas untuk meraih kendali eksekusi (RCE).
Versi yang Terdampak#
Kedua kerentanan Kritis ini mencakup jangkauan yang luas pada berbagai rilis aktif PHP saat ini:
| Versi PHP | Rilis yang Rentan | Rilis yang Aman (Patch) |
|---|---|---|
PHP 8.5 | Di bawah 8.5.12 | 8.5.12 |
PHP 8.4 | Di bawah 8.4.27 | 8.4.27 |
PHP 8.3 | Di bawah 8.3.36 | 8.3.36 |
PHP 8.2 | Di bawah 8.2.35 | 8.2.35 |
Mitigasi Sementara (Jika belum bisa update)#
Jika server belum bisa diperbarui segera, beberapa workaround administratif yang bisa diterapkan untuk menekan risiko antara lain:
Nonaktifkan Limit Memori Request: Atur
memory_limit=-1padaphp.ini. Hal ini akan mencabut batas memori spesifik pada request, yang mana sering dimanipulasi peretas untuk memancing terjadinya OOM corruption secara sengaja.Matikan Upload Progress Sesi: Khusus untuk pengguna PHP-FPM, pastikan konfigurasi session.
upload_progress.enabled=0diterapkan agar peretas tidak bisa menggunakan upload sessions sebagai vektor serangan memori.WAF (Web Application Firewall): Blokir format multipart request sepenuhnya di tingkat frontend (seperti pada Nginx) apabila aplikasi web Anda memang tidak menggunakan fitur unggah berkas (file upload).
Segera Update PHP!#
Cek versi PHP Anda saat ini dengan perintah berikut:
php -v
