Peringatan Keamanan

Peringatan Keamanan: PHP2Shell (CVE-2026-109618 & CVE-2026-109619), Eksekusi Kode Jarak Jauh Tanpa Login pada PHP

Adam  ·  22 Okt 2026  ·  KUTIM-SA-2026-088  ·  TLP:CLEAR  ·  81 kali dilihat

Peringatan Keamanan: PHP2Shell (CVE-2026-109618 & CVE-2026-109619), Eksekusi Kode Jarak Jauh Tanpa Login pada PHP
Sumber: Artikel ini diterbitkan oleh KUTIM-CSIRT berdasarkan Security Advisory BSSN/Id-SIRTII tanggal 22 Oktober 2026 dan advisory resmi PHP Security Team tanggal 21 Oktober 2026. Nomor CVE, skor, dan versi terdampak telah kami verifikasi ulang ke NVD, advisory PHP di GitHub, serta pelacak keamanan Ubuntu dan Debian. Dokumen asli: Security Advisory: Kerentanan pada PHP2Shell (CVE-2026-109618 & CVE-2026-109619) – BSSN/Id-SIRTII.

KUTIM-CSIRT mengimbau seluruh Perangkat Daerah di lingkungan Pemerintah Kabupaten Kutai Timur yang mengelola situs web atau aplikasi berbasis PHP untuk segera memperbarui PHP. Dua kerentanan yang dikenal sebagai PHP2Shell (CVE-2026-109618 dan CVE-2026-109619) memungkinkan penyerang menjalankan perintah di server tanpa login, cukup dengan mengirim HTTP request yang dirancang khusus.

Celah ini berada di dalam PHP itu sendiri, bukan di aplikasinya. Karena itu WordPress, Laravel, CodeIgniter, Joomla, phpMyAdmin, Moodle, OJS, Nextcloud, maupun aplikasi buatan sendiri sama-sama terdampak selama berjalan di atas PHP yang belum diperbarui. Halaman login atau autentikasi aplikasi tidak menghalangi serangan, sebab PHP sudah memproses request berbahaya sebelum kode aplikasi dijalankan.

Ikhtisar

CVE & SkorJenis Kerentanan
CVE-2026-109618
Critical
CVSS 3.1: 9,8
CVSS 4.0: 9,2
Remote Code Execution melalui kerusakan memori saat penanganan out-of-memory (CWE-416, CWE-755, CWE-824, CWE-1325)
CVE-2026-109619
Critical
CVSS 3.1: 9,8
CVSS 4.0: 9,2
Remote Code Execution melalui stale global state (use-after-free, CWE-416)

Kedua skor sama-sama Critical. Perbedaannya berasal dari versi metode penilaian. NVD memakai CVSS 3.1 dengan vektor AV:N/AC:L/PR:N/UI:N: dari jaringan, tanpa hak akses, tanpa interaksi pengguna. PHP Security Team memakai CVSS 4.0 dengan vektor AV:N/AC:H/AT:P/PR:N/UI:N, yang menilai eksploitasi menuntut kondisi tertentu pada server sehingga skornya sedikit lebih rendah.

Dampak

  • Eksekusi kode jarak jauh tanpa autentikasi dengan hak akses akun web server (misalnya www-data, apache, atau nginx). Dari sini penyerang dapat memasang webshell, menyisipkan konten judi online, mencuri berkas konfigurasi berisi password database, lalu bergerak ke sistem lain.
  • Kebocoran isi memori proses (khusus CVE-2026-109619), yang dapat membuka data request pengguna lain yang dilayani oleh worker yang sama.
  • Serangan dapat tidak meninggalkan jejak yang jelas. Request eksploitasi yang berhasil bisa dijawab HTTP 200 dan worker tetap berjalan normal.

Menurut PHP Security Team, risiko tertinggi ada pada Apache dengan mod_php, yang eksploitasinya telah dibuktikan dengan konfigurasi bawaan. Pada PHP-FPM eksploitasi lebih sulit, tetapi tetap dinyatakan mungkin. FrankenPHP dan LiteSpeed juga termasuk lingkup terdampak.

Sistem yang Terdampak

Seluruh instalasi PHP yang melayani request web, termasuk PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, dan LiteSpeed. PHP CLI yang tidak melayani web tidak menjadi jalur serangan, tetapi sebaiknya ikut diperbarui.

Cabang PHPVersi TerdampakVersi Perbaikan
PHP 8.5Semua versi 8.5 sebelum 8.5.128.5.12
PHP 8.4Semua versi 8.4 sebelum 8.4.278.4.27
PHP 8.3Semua versi 8.3 sebelum 8.3.368.3.36
PHP 8.2Semua versi 8.2 sebelum 8.2.358.2.35 (cabang 8.2 berakhir masa dukungannya 31 Desember 2026)
PHP 8.1, 8.0, 7.4Semua versi (cabang sudah EOL)Tidak ada rilis resmi. Gunakan paket perbaikan dari distribusi Linux bila tersedia, atau migrasi ke cabang yang masih didukung
PHP 7.3 dan lebih lama, termasuk 5.xSemua versi (cabang sudah EOL)Tidak ada perbaikan dari PHP. Wajib migrasi, kecuali menggunakan layanan dukungan berbayar distribusi

Versi paket perbaikan dari distribusi Linux. Distribusi menambal paketnya tanpa mengganti nomor versi utama, sehingga angkanya tidak sama dengan versi upstream di atas.

Distribusi & PaketVersi Perbaikan
Ubuntu 26.04 LTS
php8.5
8.5.4-0ubuntu1.5
(USN-8948-1)
Ubuntu 24.04 LTS
php8.3
8.3.6-0ubuntu0.24.04.13
Ubuntu 22.04 LTS
php8.1
8.1.2-1ubuntu2.28
Ubuntu 20.04 / 18.04 LTS
php7.4 / php7.2
Hanya melalui Ubuntu Pro (ESM)
Debian 13 (trixie)
php8.4
8.4.27-1~deb13u1
(DSA-6574-1)
Debian 12 (bookworm)
php8.2
8.2.35-1~deb12u1
(DLA-4848-1)
RHEL, AlmaLinux, Rocky Linux
php (AppStream)
Ikuti errata vendor masing-masing (rujukan Red Hat: RHSB-2026-013)
Repositori Remi / Ondřej Surý
php*
Mengikuti versi upstream: 8.5.12, 8.4.27, 8.3.36, 8.2.35
Image Docker resmi
php:8.x-*
Bangun ulang image dari tag 8.5.12, 8.4.27, 8.3.36, atau 8.2.35
Penegasan atas edaran: edaran BSSN menyebut PHP 8.1 dan versi lebih lama "berpotensi terdampak". Advisory resmi PHP menyatakan lebih tegas bahwa seluruh instalasi PHP yang melayani request web terdampak, termasuk cabang lama. Pelacak keamanan Ubuntu juga menerbitkan perbaikan hingga paket PHP 5.5. Karena itu, server dengan PHP 8.1 ke bawah sebaiknya dianggap rentan, bukan sekadar berpotensi rentan. PHP Security Team juga menyediakan source backport untuk cabang 7.4, 8.0, dan 8.1 bagi pengelola yang membangun PHP dari kode sumber.

Detail Teknis

CVE-2026-109618 (RCE via OOM corruption). Ketika memori habis (out-of-memory), PHP menghentikan pemrosesan request dengan longjmp(). Bila hal itu terjadi saat data internal request baru sebagian terinisialisasi, prosedur pembersihan request akan membaca data yang belum valid seolah-olah valid. Penyerang dapat sengaja memicu kondisi kehabisan memori dari luar, antara lain dengan request multipart tanpa panjang konten yang jelas, header per bagian yang sangat banyak, atau nama field bersarang. Perbaikannya menghapus penggunaan longjmp() untuk kondisi kehabisan memori.

CVE-2026-109619 (RCE via stale global state). PHP menyimpan beberapa global state (error, session, object, dan state ekstensi) yang sementara menunjuk ke memori milik request. Dalam kondisi tertentu, misalnya setelah fatal error, kehabisan memori, atau execution timeout, state ini tidak di-reset dengan benar. Request berikutnya yang dilayani worker yang sama kemudian memakai state yang memorinya sudah dibebaskan (use-after-free). Jalur yang sudah dikonfirmasi adalah fitur session.upload_progress, diagnostik INI sebelum request diinisialisasi, dan backtrace fatal error pada PHP 8.5.

Rekomendasi

Langkah utama: perbarui PHP. PHP Security Team menegaskan bahwa pembaruan adalah satu-satunya perbaikan yang lengkap.

  1. Inventarisasi semua runtime PHP yang melayani web, bukan hanya perintah php -v di terminal. Periksa juga PHP di dalam kontainer Docker/Podman, panel hosting (cPanel, aaPanel, Plesk), paket snap, dan aplikasi yang membawa interpreter sendiri. Satu server bisa menjalankan beberapa versi PHP sekaligus.
  2. Perbarui ke versi perbaikan sesuai tabel di atas. Pada distribusi Linux, pastikan paket yang terpasang memuat perbaikan dengan memeriksa changelog-nya:
    • Debian/Ubuntu: apt changelog php8.3 | grep -E "CVE-2026-10961[89]" (sesuaikan nama paket)
    • RHEL/AlmaLinux: rpm -q --changelog php-fpm | grep -E "CVE-2026-10961[89]"
  3. Restart seluruh layanan PHP setelah pembaruan (php-fpm, apache2/httpd, lsws, atau kontainer). Proses lama yang masih berjalan tetap rentan walaupun paket di disk sudah baru.
  4. Untuk kontainer, bangun ulang image dari base image yang sudah diperbaiki lalu buat ulang kontainernya. Pembaruan paket di dalam kontainer yang sedang berjalan akan hilang saat kontainer dibuat ulang.
  5. Untuk PHP 7.x dan 5.x yang tidak lagi didukung, rencanakan migrasi ke cabang yang masih didukung. Selama migrasi belum selesai, batasi akses aplikasi tersebut hanya dari jaringan internal atau VPN.

Langkah sementara bila pembaruan belum dapat dilakukan. Langkah ini mengurangi risiko tetapi tidak membuat server aman. Terapkan di php.ini atau konfigurasi pool FPM (php_admin_value) agar tidak dapat diubah aplikasi, lalu restart seluruh worker:

memory_limit = -1
post_max_size = 8M          ; 32M bila aplikasi butuh unggah berkas
upload_max_filesize = 8M    ; harus di bawah post_max_size
session.upload_progress.enabled = 0
fatal_error_backtraces = 0  ; khusus PHP 8.5
  • Jangan memakai ini_set() atau berkas .user.ini untuk pengaturan di atas, karena keduanya baru berlaku setelah request diproses.
  • Jangan mengganti pembatasan memori dengan RLIMIT_AS/RLIMIT_DATA. Cara ini justru memicu jalur yang rentan.
  • Bila aplikasi tidak menerima unggahan berkas, tolak request multipart/form-data di web server atau WAF sebelum sampai ke PHP, dan batasi ukuran request body.
  • Menyembunyikan pesan error (display_errors, error_reporting, atau operator @) tidak membantu.
  • Bila langkah di atas juga belum dapat diterapkan, batasi akses jaringan ke aplikasi yang terdampak atau isolasi layanan yang terhubung ke internet sampai pembaruan diterapkan.

Periksa tanda-tanda serangan. Aktifkan log_errors dan error_reporting = E_ALL di konfigurasi awal, lalu perhatikan:

  • Pesan PHP Fatal error: Allowed memory size of ... bytes exhausted dengan lokasi Unknown on line 0, yang berarti memori habis sebelum skrip apa pun dijalankan.
  • Pesan Apache AH00052: child pid ... exit signal Segmentation fault (11) yang muncul tidak seperti biasanya.
  • Request POST dengan nama field yang sangat panjang (ukuran megabyte) atau berisi karakter kontrol/null byte.
  • Proses web server (www-data, apache, nginx) yang menjalankan sh, bash, curl, atau wget. Ini tanda terkuat bahwa eksploitasi berhasil.
  • Berkas PHP baru atau berubah di direktori web dan direktori unggahan sejak pertengahan Oktober 2026.

Tidak ditemukannya catatan di log bukan bukti server aman. Bila menemukan indikasi di atas, jangan menghapus berkas atau me-restart server sebelum berkoordinasi. Laporkan melalui formulir laporan insiden agar bukti tetap utuh untuk investigasi.

Catatan Status Eksploitasi

Hingga 22 Oktober 2026, kedua CVE ini belum tercantum dalam katalog KEV CISA. Namun beberapa sumber publik melaporkan aktivitas serangan. Datadog Security Labs pada 21 Oktober 2026 menyebut telah menerima beberapa laporan eksploitasi di dunia nyata serta mengamati pemindaian massal yang tidak terarah. Menurut laporan yang sama, AWS mencatat upaya eksploitasi sejak 17 Oktober 2026, empat hari sebelum perbaikan dirilis. Rincian kerentanan juga sempat bocor ke publik sebelum rilis resmi. Dengan kondisi ini, Perangkat Daerah sebaiknya memperlakukan PHP2Shell sebagai prioritas darurat tanpa menunggu status KEV.

Red Hat menilai tingkat keparahannya Important untuk produknya, dengan catatan bahwa instalasi bawaan RHEL memakai PHP-FPM yang lebih sulit dieksploitasi dibanding mod_php. Penilaian tersebut tidak mengurangi urgensi pembaruan, karena eksploitasi terhadap PHP-FPM tetap dinyatakan mungkin.

Referensi