Kerentanan Kritis RCE "PHP2SHELL" (CVE-2026-109618 & CVE-2026-109619) pada Runtime PHP

By Wildan Ramadhan in Peringatan Keamanan

Peringatan Keamanan
Tim Tanggap Insiden Siber Pemerintah Kota Tasikmalaya (TasikmalayaKota-CSIRT) menerbitkan peringatan keamanan tingkat kritis menindaklanjuti pengumuman resmi dari The PHP Security Team (php.announce pesan #509) yang dikirimkan oleh Jakub Zelenka pada Selasa, 20 Oktober 2026 pukul 19:33:47 UTC [1].

Pembaruan keamanan darurat tersebut resmi dirilis pada Rabu, 21 Oktober 2026 pukul 13:30 UTC (20:30 WIB) menurut CERT-EU, lebih awal dari jadwal semula pukul 14:00 UTC, untuk menutup dua celah keamanan kritis yang masing-masing memiliki skor CVSS v4.0 sebesar 9.2 (Critical) [1] [5].

Dalam dokumen GitHub Security Advisory resmi dari repositori inti PHP (php/php-src) dan buletin keamanan CERT-EU, kedua kerentanan ini diidentifikasi sebagai CVE-2026-109618 (GHSA-w8hw-w9fx-j79w) [2] dan CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp) [3], atau dikenal secara kolektif sebagai "PHP2Shell" [5].

Kedua kerentanan ini berkaitan dengan pengelolaan memori pada proses inisialisasi dan pembersihan siklus permintaan HTTP di tingkat mesin inti PHP (engine). Pada jalur eksploitasi tertentu, khususnya Apache mod_php, serangan dapat terjadi sebelum kode aplikasi PHP dijalankan [2] [3].

Oleh karena itu, mekanisme keamanan di tingkat kode aplikasi (seperti autentikasi login, validasi input, maupun penggunaan framework modern seperti Laravel, CodeIgniter, atau WordPress) tidak dapat dijadikan pengganti pembaruan runtime PHP untuk mencegah eksploitasi kerentanan tersebut [2] [3] [5].

Analisis Sebab-Akibat (Mekanisme Celah & Dampak)


Pada arsitektur server web modern (seperti Apache mod_php dan PHP-FPM), satu proses pekerja (worker process) dapat digunakan secara berulang untuk melayani banyak permintaan HTTP secara bergantian [2] [3]. Kerentanan PHP2Shell terjadi akibat kegagalan mesin PHP dalam menginisialisasi atau membersihkan status memori secara benar ketika terjadi penghentian mendadak (error/bailout) maupun ketika worker menangani permintaan berikutnya [2] [3].

A. Rincian Sebab-Akibat CVE-2026-109618 (GHSA-w8hw-w9fx-j79w) — Out-of-Memory (OOM) Corruption

  • Klasifikasi CWE & Skor CVSS: CWE-824 (Access of Uninitialized Pointer) dengan skor CVSS v4.0 9.2 (Critical) (AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H) [2] [6].
  • Akar Masalah (Root Cause): Ketika sebuah permintaan HTTP kehabisan memori (Out-of-Memory / OOM) di tengah proses inisialisasi, PHP menghentikan eksekusi secara mendadak menggunakan mekanisme internal longjmp() saat struktur data internal baru terinisialisasi sebagian [2].
  • Pemicu Serangan (Sebab): Penyerang jarak jauh mengirimkan permintaan HTTP yang dirancang secara khusus, misalnya dengan struktur input kompleks atau banyaknya bagian dan header multipart/form-data, untuk memaksa kondisi Out-of-Memory pada fase pemrosesan permintaan. Permintaan tersebut tidak harus berukuran sangat besar karena pemrosesan internal PHP dapat mengonsumsi memori jauh lebih banyak dibandingkan ukuran data yang dikirimkan [2].
  • Kegagalan Sistem (Proses): Saat fase pembersihan memori (shutdown cleanup), PHP dapat memperlakukan pointer atau struktur memori yang belum selesai diinisialisasi sebagai data yang valid, sehingga memicu korupsi memori internal [2].
  • Dampak Akhir (Akibat): Eksekusi Kode Jarak Jauh (Remote Code Execution / RCE) tanpa autentikasi, potensi pengungkapan informasi memori (memory disclosure), atau berhentinya layanan (crash / DoS) [2] [5].

B. Rincian Sebab-Akibat CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp) — Use-After-Free via Stale Global State

  • Klasifikasi CWE & Skor CVSS: CWE-416 (Use After Free) dengan skor CVSS v4.0 9.2 (Critical) (AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H) [3] [6].
  • Akar Masalah (Root Cause): Status internal (internal global state) dari suatu permintaan masih menyimpan referensi ke blok memori yang telah dibebaskan (freed). Kondisi ini dapat terjadi akibat fatal error, kegagalan pembersihan status, atau operasi tertentu yang meninggalkan referensi memori tidak valid [3].
  • Pemicu Serangan (Sebab): Salah satu jalur eksploitasi yang telah dikonfirmasi memanfaatkan permintaan POST bertipe multipart/form-data yang menyertakan parameter PHP_SESSION_UPLOAD_PROGRESS melalui fitur session.upload_progress.enabled yang aktif secara default di PHP. Namun, terdapat jalur eksploitasi lain yang melibatkan penanganan error dan status internal PHP [3].
  • Kegagalan Sistem (Proses): Ketika proses worker yang sama kembali melayani permintaan berikutnya, worker tersebut dapat mengakses dan menggunakan kembali referensi memori yang sudah basi (stale state) sebelum sempat diatur ulang (reset) [3].
  • Dampak Akhir (Akibat): Eksekusi Kode Jarak Jauh (Remote Code Execution / RCE) tanpa autentikasi pada proses worker PHP serta potensi pengungkapan informasi sensitif dari memori proses [3] [5].

C. Rantai Dampak Operasional pada Instansi

  1. Eksekusi Kode dan Potensi Pengambilalihan Server (Unauthenticated RCE): Korupsi memori pada CWE-824 [2] dan CWE-416 [3] memungkinkan penyerang menjalankan kode di bawah hak akses proses worker PHP (misalnya www-data atau apache), menanam backdoor (web shell), hingga melakukan perubahan tampilan situs (web defacement). Namun, eksploitasi ini tidak secara otomatis memberikan hak akses root atau administrator [2] [3].
  2. Kebocoran Data Sensitif (Memory Disclosure): Korupsi memori atau penggunaan referensi memori yang sudah dibebaskan dapat menyebabkan pengungkapan informasi sensitif dalam ruang memori proses PHP, termasuk informasi sesi atau data aplikasi yang sedang diproses. Apabila RCE berhasil, penyerang juga berpotensi mengakses berkas konfigurasi seperti .env sepanjang hak akses proses PHP mengizinkannya [2] [3].
  3. Gangguan Ketersediaan Layanan (Denial of Service / Crash): Percobaan eksploitasi memori dapat memicu penghentian proses pekerja (SIGSEGV / segmentation fault) atau menyebabkan layanan menampilkan Error 502 Bad Gateway maupun 500 Internal Server Error. Namun, keberhasilan eksploitasi tidak selalu menimbulkan crash atau respons HTTP error [5] [8].



Daftar Lingkungan & Versi PHP yang Terdampak


Berdasarkan Catatan Rilis Resmi PHP 8 (php.net) [4] dan GitHub Security Advisory [2] [3], kerentanan ini berdampak pada cabang PHP yang belum menerima perbaikan keamanan, termasuk versi lama yang sudah mencapai End-of-Life (EOL):

  • Cabang PHP 8.5.x: Rentan pada versi 8.5.11 ke bawah — Diperbaiki pada versi PHP 8.5.12 [4].
  • Cabang PHP 8.4.x: Rentan pada versi 8.4.26 ke bawah — Diperbaiki pada versi PHP 8.4.27 [4].
  • Cabang PHP 8.3.x: Rentan pada versi 8.3.35 ke bawah — Diperbaiki pada versi PHP 8.3.36 [4].
  • Cabang PHP 8.2.x: Rentan pada versi 8.2.34 ke bawah — Diperbaiki pada versi PHP 8.2.35 [4].
  • Cabang PHP 8.1 dan lebih lama (End-of-Life / EOL): Berisiko apabila belum menerima perbaikan keamanan. PHP Security Team menyediakan minimal source-backports untuk PHP 7.4, 8.0, dan 8.1, sementara sejumlah vendor distribusi Linux menyediakan patch melalui mekanisme security backport. Administrator disarankan melakukan upgrade ke versi yang masih didukung atau memverifikasi patch resmi dari vendor [4] [5] [7].
  • Arsitektur SAPI Terdampak: Eksploitasi penuh sebelum kode aplikasi dijalankan telah dikonfirmasi pada Apache HTTP Server dengan mod_php (risiko tertinggi). PHP-FPM juga terdampak, dengan eksploitasi CVE-2026-109619 yang telah divalidasi dalam kondisi tertentu. Lingkungan php-cgi, FrankenPHP, dan LiteSpeed juga perlu mendapatkan pembaruan, meskipun tingkat pembuktian eksploitasi berbeda antar-SAPI [2] [3] [5].

Catatan: Distribusi Linux dapat menyediakan patch melalui security backport tanpa mengubah nomor versi dasar PHP menjadi sama dengan versi upstream. Status keamanan paket harus mengacu pada advisori vendor [7].

Panduan Mitigasi dan Remediasi Terstruktur


Mengacu pada instruksi resmi di dalam dokumen GHSA-w8hw-w9fx-j79w [2] dan GHSA-6wmf-4rv5-p3rp [3], pengelola sistem perlu segera menerapkan pembaruan keamanan. Apabila pembaruan belum memungkinkan, mitigasi konfigurasi sementara dapat digunakan untuk mengurangi risiko pada jalur eksploitasi tertentu.

Tahap 1: Mitigasi Konfigurasi Darurat (Official Workarounds)

Catatan Penting: Pengaturan darurat di bawah ini harus diterapkan secara administratif melalui php.ini atau konfigurasi server/pool FPM yang berlaku sebelum pemrosesan permintaan. Pengaturan melalui .user.ini PHP-FPM atau fungsi ini_set() di dalam skrip aplikasi tidak efektif untuk melindungi jalur eksploitasi yang dipicu sebelum skrip aplikasi dijalankan. Mitigasi konfigurasi tidak menutup seluruh kemungkinan eksploitasi dan bukan pengganti patch resmi [2] [3].

  1. Mengurangi Vektor Serangan CVE-2026-109619 (Stale Global State) [3]:

    • Nonaktifkan fitur session upload progress pada konfigurasi PHP: session.upload_progress.enabled = 0. Pengaturan ini menghambat jalur eksploitasi berbasis session upload progress, tetapi tidak menutup seluruh variasi serangan [3].
    • Khusus bagi pengguna PHP 8.5, nonaktifkan fatal error backtraces: fatal_error_backtraces = 0. Pengaturan ini hanya memitigasi jalur eksploitasi terkait fatal error backtrace [3].

  2. Menghambat Vektor Serangan CVE-2026-109618 (Out-of-Memory Corruption) [2]:

    • Batasi ukuran maksimum request body dan kompleksitas input pada tingkat web server atau reverse proxy (client_max_body_size pada Nginx atau LimitRequestBody pada Apache), termasuk jumlah parameter, bagian multipart, header, dan kedalaman struktur input [2].
    • Perkecil nilai post_max_size dan upload_max_filesize pada php.ini sesuai kebutuhan minimum aplikasi. Pembatasan tersebut mengurangi paparan tetapi tidak dapat menggantikan patch [2].
    • Sebagai mitigasi sementara, gunakan memory_limit = -1 melalui konfigurasi administratif seperti php_admin_value agar aplikasi tidak dapat mengubahnya. Apabila diperlukan, gunakan pembatasan memori berbasis cgroup sebagai pengaman ketersediaan layanan. Langkah ini tetap memiliki risiko kehabisan memori sistem dan tidak sepenuhnya menutup kerentanan. Hindari penggunaan RLIMIT_AS atau RLIMIT_DATA karena dapat memicu kegagalan alokasi pada jalur yang rentan [2].

  3. Muat Ulang Layanan PHP: Lakukan restart pada layanan PHP-FPM atau Apache (apache2/httpd) agar perubahan konfigurasi diterapkan pada seluruh worker aktif [2] [3].

Tahap 2: Remediasi Permanen (Pembaruan Paket Runtime PHP)

  1. Perbarui Paket PHP ke Versi Perbaikan Resmi (8.5.12, 8.4.27, 8.3.36, atau 8.2.35) [4]:

    • Ubuntu / Debian [7]: Jalankan sudo apt update, kemudian perbarui paket PHP yang terpasang melalui sudo apt install --only-upgrade dengan nama paket PHP yang sesuai. Pastikan versi paket telah dinyatakan aman melalui advisori distribusi.
    • RHEL / AlmaLinux / Rocky Linux [7]: Jalankan sudo dnf update "php*" sesuai paket dan repository yang digunakan, lalu verifikasi bahwa pembaruan telah mencakup perbaikan kedua CVE.
    • Lingkungan Container (Docker) [4]: Gunakan base image resmi PHP yang telah memuat patch, kemudian bangun ulang (rebuild) dan jalankan ulang container. Pastikan runtime dalam container benar-benar menggunakan versi yang telah diperbaiki.

  2. Restart Layanan Pemroses PHP (Wajib) [2] [3]: Jalankan restart pada layanan PHP-FPM sesuai versi yang digunakan, misalnya sudo systemctl restart php8.3-fpm, atau restart apache2/httpd untuk konfigurasi mod_php. Setelah itu, verifikasi versi PHP pada runtime web yang aktif. Perintah php -v hanya memeriksa PHP CLI dan belum tentu mencerminkan versi PHP-FPM atau modul Apache yang melayani aplikasi [4].

Tahap 3: Investigasi Pasca-Mitigasi & Deteksi Kompromi (Threat Hunting)

Mengingat adanya laporan percobaan eksploitasi sebelum pengungkapan publik dan rilis perbaikan pada 21 Oktober 2026, administrator sistem perlu melakukan pemeriksaan indikator kompromi berdasarkan riwayat log yang tersedia [8].

  1. Audit Pemicuan OOM & Worker Crash [2] [8]: Periksa lonjakan pesan kehabisan memori (Allowed memory size ... exhausted) maupun penghentian proses worker (SIGSEGV / segmentation fault). Namun, keberhasilan eksploitasi tidak selalu disertai crash atau pesan error.
  2. Audit Penyalahgunaan Upload Progress [3]: Periksa permintaan POST mencurigakan dengan tipe multipart/form-data yang membawa parameter PHP_SESSION_UPLOAD_PROGRESS, terutama apabila berkorelasi dengan fatal error atau aktivitas worker yang tidak wajar. Keberadaan parameter tersebut saja tidak membuktikan eksploitasi.
  3. Audit Integritas Berkas (Deteksi Web Shell) [5]: Periksa penambahan atau perubahan berkas .php secara tidak sah di direktori aplikasi maupun direktori publik web. Pemeriksaan sebaiknya mencakup periode sebelum dan sesudah pengungkapan publik, sejauh riwayat log dan cadangan tersedia.
  4. Audit Eksekusi Proses Asing (RCE) [2] [3]: Periksa apakah pengguna layanan web (www-data, nginx, atau apache) menjalankan proses shell atau utilitas sistem yang tidak sesuai perilaku normal aplikasi, seperti sh, bash, curl, wget, atau nc.

Daftar Referensi Otoritatif


  1. The PHP Security Team (Jakub Zelenka) — Upcoming Critical PHP Security Release (php.announce Message #509), Pengumuman Resmi Mailing List PHP, 20 Oktober 2026 pukul 19:33:47 UTC (jadwal rilis awal: 21 Oktober 2026 pukul 14:00 UTC).
  2. PHP Official GitHub Security Advisory (GHSA-w8hw-w9fx-j79w / CVE-2026-109618) — RCE via OOM Corruption, The PHP Group (php/php-src), dipublikasikan 21 Oktober 2026.
  3. PHP Official GitHub Security Advisory (GHSA-6wmf-4rv5-p3rp / CVE-2026-109619) — RCE via Stale Global State, The PHP Group (php/php-src), dipublikasikan 21 Oktober 2026.
  4. The PHP Group (php.net) — PHP 8 Official Release ChangeLog dan PHP Security Advisory, 21 Oktober 2026 (rilis keamanan 8.5.12, 8.4.27, 8.3.36, dan 8.2.35).
  5. CERT-EU (Computer Emergency Response Team for the EU Institutions) — Security Advisory 2026-018: Critical Vulnerabilities in PHP, 21 Oktober 2026.
  6. National Vulnerability Database (NIST NVD) — Detail analisis kerentanan CVE-2026-109618 dan CVE-2026-109619, Oktober 2026.
  7. Linux Distribution Security Trackers — Pelacak pembaruan paket distribusi Linux untuk Debian (CVE-2026-109618), Debian (CVE-2026-109619), Ubuntu Security (CVE-2026-109618), dan Red Hat Security, Oktober 2026.
  8. Datadog Security Labs — PHP2Shell: Critical Vulnerabilities in PHP — Detection, Analysis, and Remediation, 21 Oktober 2026.

Back to Posts