php2shell (CVE-2026-109618 / 109619) tidak bisa dinilai dengan php -v: tempat nomor versi berbeda antara FPM, Docker, dan distro

Jika PHP yang menangani permintaan web (PHP-FPM, mod_php Apache, php-cgi, FrankenPHP, LiteSpeed) lebih lama dari 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12, PHP tersebut terdampak CVE-2026-109618 dan CVE-2026-109619, yang dikenal sebagai php2shell. Perbaikannya adalah meningkatkan ke salah satu versi ini (atau, untuk paket distro, ke paket yang sudah diperbaiki) lalu me-restart prosesnya. Yang perlu Anda periksa bukan php -v lokal, melainkan “PHP yang benar-benar melayani web” dan “versi paket yang terpasang.”

Artikel ini berfokus pada empat tempat di mana penilaian berdasarkan nomor versi saja menghasilkan kesimpulan yang salah. Semua angka dan informasi status adalah per 2026-10-22, dan sumber tiap butir dicantumkan di bagian akhir.

Yang diketahui per 2026-10-22

Pengumuman PHP menyatakan bahwa “satu-satunya perbaikan yang lengkap adalah memperbarui.” Mitigasi untuk masa sebelum Anda bisa memperbarui dibahas di bagian akhir artikel ini.

Jebakan 1: php -v dan PHP yang melayani web bisa berbeda

php -v yang diketik lewat SSH menampilkan versi PHP CLI. Permintaan web ditangani oleh proses PHP-FPM atau mod_php yang dimuat ke Apache, yang merupakan binary dan paket terpisah. Jika Anda memasang PHP yang lebih baru hanya untuk CLI, menjalankan beberapa versi berdampingan, atau memiliki pool FPM yang menunjuk ke versi lain, sisi web bisa tetap lama meskipun php -v menampilkan versi perbaikan.

Ada beberapa cara untuk melihat versi sebenarnya di sisi web.

# FPM di Debian / Ubuntu (dinamai per versi)
php-fpm8.3 -v

# FPM pada keluarga RHEL
php-fpm -v

# Periksa apakah mod_php dimuat di Apache
apachectl -M | grep -i php

Cara paling andal adalah membuat PHP yang benar-benar berjalan lewat web melaporkan versinya sendiri. Letakkan file sementara dengan nama yang sulit ditebak, lalu hapus segera setelah selesai memeriksa.

<?php echo PHP_VERSION, ' ', PHP_SAPI;

Jika PHP_SAPI bernilai fpm-fcgi, PHP berjalan di bawah FPM; apache2handler berarti mod_php; cgi-fcgi berarti CGI. Jangan biarkan phpinfo() terbuka, karena hal itu sendiri membocorkan informasi.

Restart adalah langkah lain yang mudah terlewat. Meskipun paket sudah diganti, proses php-fpm atau Apache yang sudah berjalan mungkin tetap menjalankan kode lama. Sebagian konfigurasi melakukan restart otomatis saat paket diperbarui; sebagian lain tidak. Setelah memperbarui, restart FPM / Apache dan periksa lagi versi sisi web dengan cara di atas.

Jebakan 2: Pada Docker, nama tag tidak bisa dijadikan patokan

Image resmi php memiliki “tag bergerak” seperti 8.3 dan 8.3-fpm, yang isinya diganti, serta tag yang dipatok seperti 8.3.30, yang mengunci versi.

• Meskipun sebuah tag bergerak sudah dialihkan ke versi perbaikan di Docker Hub, salinan lokal Anda tetap berupa image lama sampai Anda melakukan pull lagi. Container yang berjalan juga tetap memakai image lama sampai dibuat ulang. Dockerfile dengan FROM php:8.3-fpm tetap akan di-build di atas base lama jika base itu masih ada di cache build.
• Tag yang dipatok akan tetap lama selamanya sampai Anda menaikkan nomornya sendiri.

Anda dapat memeriksa apakah tag versi perbaikan sudah dipublikasikan menggunakan API Docker Hub.

curl -s "https://hub.docker.com/v2/repositories/library/php/tags?name=8.3.36&page_size=100"

Berikut hasil pengecekan empat lini rilis pada 2026-10-22 (waktu dalam UTC).

Pengecekan ini menemukan tiga hal di mana penilaian berdasarkan angka bisa menyesatkan.

1. “Baru diperbarui” tidak berarti “sudah diperbaiki.” Tag yang dipatok 8.3.35 dibangun ulang pada 2026-10-21, tetapi PHP_VERSION di dalamnya tetap 8.3.35. Lihat versi di dalam image, bukan waktu pembaruannya.
2. Digest berbeda bisa berisi hal yang sama. 8.3 dan 8.3.36 memiliki digest tag yang berbeda (nilai indeks multi-arsitektur), tetapi image amd64-nya identik dan keduanya memiliki PHP_VERSION=8.3.36. Demikian pula untuk 8.3-fpm / 8.3.36-fpm, 8.4-apache / 8.4.27-apache, latest / 8.5.12, 8.5-fpm, dan 8.2-fpm, PHP_VERSION pada image amd64 adalah versi perbaikan.
3. Tidak ada image resmi yang sudah diperbaiki untuk 8.1 dan sebelumnya. 8.1-fpm terakhir diperbarui pada 2025-12-31.

Untuk memeriksa image lokal dan container yang berjalan:

# Versi PHP dari image yang sudah di-pull secara lokal
docker image inspect php:8.3-fpm --format '{{range .Config.Env}}{{println .}}{{end}}' | grep PHP_VERSION

# Pull ulang dan buat ulang container
docker compose pull
docker compose up -d

# Jika Anda membangun image sendiri, pull ulang base lalu build
docker compose build --pull

# Versi di dalam container yang berjalan
docker compose exec app php -r 'echo PHP_VERSION, PHP_EOL;'

Ganti app pada perintah terakhir dengan nama service Anda sendiri. Setiap image resmi dibangun dengan satu PHP_VERSION, sehingga versi CLI di dalam container sama dengan versi FPM / Apache container tersebut (Jebakan 1 berlaku jika PHP dipasang langsung di host).

FrankenPHP menyematkan PHP, sehingga versi FrankenPHP dan versi PHP yang tertanam adalah angka yang berbeda. Catatan rilis FrankenPHP 1.13.2, yang dirilis 2026-10-21, menyatakan bahwa image Docker dibangun dengan PHP 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 dan binary statis dengan PHP 8.5.12.

Jebakan 3: Paket distro “diperbaiki dengan nomor lama”

Ubuntu dan RHEL hanya memindahkan perbaikannya ke versi lama (backporting). Nomor yang ditampilkan php -v tetap lama, sehingga pemeriksaan numerik seperti “lebih rendah dari 8.3.36, berarti rentan” akan menandai sistem yang sudah diperbaiki sebagai rentan. Sebaliknya, Anda juga tidak bisa merasa aman hanya dari nomor. Tentukan berdasarkan versi paket dan security tracker masing-masing distro.

Paket perbaikan yang tercantum di tiap tracker per 2026-10-22 (sama untuk kedua CVE):

Tabel ini secara langsung menunjukkan mengapa nomor saja tidak cukup. PHP Ubuntu 24.04 yang sudah diperbaiki adalah versi yang diawali 8.3.6, jauh lebih rendah daripada 8.3.36 milik upstream. PHP default RHEL 9 sudah diperbaiki sementara tetap di 8.0.30, padahal upstream tidak lagi merilis perbaikan untuk 8.0. Debian telah pindah ke nomor yang sama dengan upstream (8.2.35 / 8.4.27).

Beberapa paket belum diperbaiki (per 2026-10-22).

• Modul php 8.4 di RHEL 9 dicantumkan sebagai “terdampak, belum ada perbaikan.”
• Debian forky (testing) memiliki php8.4 8.4.26-1, ditandai “vulnerable.” php8.4 di sid (unstable) adalah 8.4.27-1 dan sudah diperbaiki.

Contoh perintah untuk memeriksa server Anda sendiri:

# Debian / Ubuntu: versi terpasang dan versi yang tersedia
apt-cache policy php8.3-fpm libapache2-mod-php8.3

# Ubuntu: apakah CVE ini sudah diperbaiki di server ini
pro fix CVE-2026-109618
pro fix CVE-2026-109619

# Keluarga RHEL: apakah ada pembaruan yang memperbaiki CVE ini, dan versi terpasang
dnf updateinfo list --cve CVE-2026-109618
rpm -q php-fpm php-cli

Sesuaikan nama paket (php8.3-fpm, dll.) dengan lingkungan Anda. Bandingkan versi yang tampil dengan “versi perbaikan” pada tabel di atas atau di tracker; jika sama atau lebih tinggi, perbaikan sudah masuk. Lalu selesaikan restart dan pemeriksaan sisi web yang dijelaskan di Jebakan 1.

Jika Anda memasang PHP dari repositori pihak ketiga, bukan paket bawaan distro, Anda perlu mengikuti pembaruan repositori tersebut. Pengumuman PHP mencatat bahwa rpms.remirepo.net yang dikelola sukarelawan tidak akan memiliki pembaruan pada hari pengungkapan, dan menyarankan beralih ke paket distro atau build sendiri.

Jebakan 4: Pada shared hosting dan lingkungan terkelola, Anda tidak bisa meningkatkan PHP sendiri

Pada shared hosting dan lingkungan PHP terkelola, penyedia yang mengganti runtime PHP. Di sini pun nomor saja tidak cukup: jika penyedia membangun PHP sendiri atau melakukan backport perbaikan, nomor versi bisa tetap lama.

Ada tiga hal yang bisa Anda lakukan sendiri.

1. Periksa versi sisi web. Gunakan file sementara dari Jebakan 1 untuk mencetak PHP_VERSION dan PHP_SAPI, lalu segera hapus. Jika panel kontrol memiliki pemilih versi PHP, catat juga versi yang Anda pilih.
2. Baca pemberitahuan penyedia, dan tanyakan jika tidak ada. Tanyakan: “Untuk versi PHP mana pada paket saya perbaikan CVE-2026-109618 dan CVE-2026-109619 akan diterapkan, dan kapan (atau apakah sudah diterapkan)?” Bertanya dengan nomor CVE, bukan nomor versi, membuat jawaban mencakup backport juga.
3. Jika Anda memilih versi yang tidak lagi didukung, tingkatkan. Proyek PHP tidak merilis perbaikan untuk 8.1 dan sebelumnya, dan dukungan 8.2 berakhir pada 2026-12-31. Kecuali penyedia telah melakukan backport perbaikan, berpindah versi adalah jalan yang pasti.

Status per penyedia hosting (per 2026-10-22)

Pada shared hosting, penyedia biasanya memperbarui runtime PHP, dan pemberitahuan banyak penyedia menyatakan bahwa “tidak ada tindakan yang diperlukan dari pengguna.” Ada dua hal yang perlu dilakukan pengguna: memeriksa pemberitahuan resmi penyedianya, dan, jika memilih versi PHP lama di panel kontrol, memutuskan apakah akan beralih ke versi yang direkomendasikan pemberitahuan (versi yang memiliki rilis perbaikan).

Tabel di bawah hanya merangkum apa yang tertulis di halaman resmi tiap penyedia (pengumuman dan informasi pemeliharaan), dengan memparafrasekan redaksi pemberitahuan mereka. Pemberitahuan diperbarui seiring perkembangan, jadi selalu pastikan status sebenarnya di halaman resmi yang dikutip.

Jika saya tidak dapat menemukan atau membuka pemberitahuan resmi, tabel menuliskan “tidak dapat dikonfirmasi” atau “tidak ditemukan.” Tidak adanya informasi di sana tidak berarti penyedia belum menanggapi. Periksa langsung ke pengumuman dan dukungan penyedia Anda.

Mitigasi selama Anda belum bisa langsung memperbarui

Pengumuman PHP mencantumkan pengaturan yang mengurangi permukaan serangan sampai Anda bisa memperbarui. Namun, pengumuman itu sendiri secara tegas menyatakan bahwa pengaturan tersebut “tidak membuat Anda aman.” Yang utama adalah:

• Untuk CVE-2026-109619: setel session.upload_progress.enabled=0 di php.ini, pool FPM, atau konfigurasi server, lalu restart semua worker (ini_set() dan .user.ini FPM tidak berfungsi untuk ini). Pada PHP 8.5, setel juga fatal_error_backtraces=0.
• Untuk CVE-2026-109618: setel memory_limit=-1 dengan cara yang tidak dapat ditimpa oleh aplikasi, dan kecilkan post_max_size (8M jika tidak ada unggahan, 32M jika ada). Jangan menggunakan RLIMIT_AS / RLIMIT_DATA sebagai pengganti.

NCSC Inggris merekomendasikan untuk mempertimbangkan menurunkan sistem apa pun yang tidak dapat segera diperbarui atau dimitigasi, dan memeriksa tanda-tanda kompromi sebelum memperbarui atau menerapkan mitigasi.

Sumber (diperiksa pada 2026-10-22)

• php.net: Security advisory: Critical remote code execution vulnerabilities, update now (2026-10-21)
• php.net: Upcoming Critical PHP Security Release (2026-10-20)
• php.net: Pengumuman rilis PHP 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35
• GitHub: GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
• GitHub: GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
• Docker Hub: image resmi php
• Catatan rilis FrankenPHP 1.13.2
• Debian Security Tracker: CVE-2026-109618 / CVE-2026-109619
• Ubuntu: CVE-2026-109618 / CVE-2026-109619 / USN-8948-1 / USN-8948-2
• Red Hat: CVE-2026-109618 / CVE-2026-109619 (versi paket yang sudah diperbaiki berasal dari data VEX Red Hat)
• NCSC: Critical security issue affecting PHP