Kerentanan PHP: patch PHP2Shell dan cara cek versi PHP (WordPress)

Pemberitahuan afiliasi Ver 3.1
Pemberitahuan afiliasi Ver 3.2 (khusus seluler)
Lingkungan uji Keluarga RHELAlmaLinux 9.8PHP 8.3 · WordPress 7.1.3Diperiksa 2026-10-22

PHP2Shell adalah nama untuk dua kerentanan PHP (CVE-2026-109618 · CVE-2026-109619) yang patch-nya dirilis pada 21 Oktober 2026. Keduanya adalah celah eksekusi kode jarak jauh yang memungkinkan kode berjalan di server bahkan lewat permintaan tanpa login, jadi langkah pertama adalah memeriksa versi PHP yang dipakai situs Anda dan memperbaruinya ke versi yang sudah di-patch. Berikut proses memeriksa versi PHP lewat Kesehatan Situs di server Nginx + Apache dengan WordPress 7.1.3, memperbarui hanya paket php ke versi yang sudah di-patch, lalu memeriksanya kembali.

1️⃣ Kerentanan PHP PHP2Shell: cara kerja celah dan cakupan dampaknya

Celah ini ada di dalam mesin PHP yang membaca permintaan sebelum kode WordPress berjalan, sehingga tetap ada meskipun plugin dan tema Anda selalu diperbarui, selama PHP tidak diperbarui. Menurut peringatan CERT-EU, keduanya memiliki skor CVSS 9.2; detail teknisnya sudah dipublikasikan dan dibahas, dan kode proof-of-concept awal juga mulai beredar.

CVE-2026-109618 adalah celah ketika permintaan melampaui batas memori (memory_limit) lalu dihentikan, proses pembersihan memperlakukan data permintaan yang baru setengah diinisialisasi sebagai data yang sah. CVE-2026-109619 adalah celah ketika status memori yang dibebaskan setelah fatal error tetap tersisa dan dipakai ulang sebelum diinisialisasi pada permintaan berikutnya yang ditangani worker yang sama.

Menurut pengumuman php.net, semua instalasi PHP yang menangani permintaan web terdampak, dan Apache mod_php dianggap sebagai konfigurasi paling berbahaya. Alasannya, pada mod_php telah didemonstrasikan bahwa satu permintaan tanpa login bisa memicu serangan sebelum kode aplikasi berjalan.

Cara PHP dijalankanDampakKeterangan
Apache mod_php🔴 Terdampak · paling berbahayaDemonstrasi satu permintaan tanpa login yang memicu serangan sebelum kode aplikasi berjalan
PHP-FPM🔴 Terdampak—
php-cgi🔴 Terdampak—
FrankenPHP🔴 Terdampak—
LiteSpeed🔴 Terdampak—

Versi yang sudah diperbaiki adalah 8.2.35, 8.3.36, 8.4.27, dan 8.5.12, dan semua versi yang lebih rendah di seri 8.2–8.5 terdampak. PHP 8.1 ke bawah adalah seri yang tidak lagi didukung proyek PHP, sehingga tidak ada versi patch resmi; seri ini ditangani dengan perbaikan yang dipindahkan oleh distribusi dan penyedia hosting (backport).

Saat CISA menerbitkan pemberitahuannya pada 21 Oktober, belum ada eksploitasi nyata yang terkonfirmasi, tetapi CISA menilai membiarkan sistem tanpa patch itu berbahaya dan menyarankan patch segera, dimulai dari sistem yang terhubung ke internet. Pada hari yang sama, CERT-EU dalam peringatannya menilai bahwa dengan mulai beredarnya kode proof-of-concept, kemungkinan penyerang sudah mengeksploitasi celah ini menjadi lebih besar.

2️⃣ Cek versi PHP: Kesehatan Situs › Info › Server

Meski sudah tahu celahnya, Anda belum bisa menentukan langkah sebelum tahu situs Anda berjalan dengan versi PHP berapa. Di layar admin, buka [Peralatan › Kesehatan Situs] lalu bentangkan bagian [Server] di tab [Info]: baris [Versi PHP] menampilkan versi PHP yang benar-benar menangani permintaan situs Anda.

Layar tab Info Kesehatan Situs: menu kiri Peralatan › Kesehatan Situs serta baris Arsitektur server, Server web, Versi PHP, dan PHP SAPI di bagian Server — versi PHP menjadi patokan untuk memeriksa patch kerentanan PHP PHP2Shell (WordPress 7.1.3)

Baris [PHP SAPI] tepat di bawah [Versi PHP] menunjukkan cara PHP dijalankan; fpm-fcgi berarti konfigurasi PHP-FPM. Di sini cukup lihat dua baris di bagian [Server], yaitu [Versi PHP] dan [PHP SAPI].

🧩 Alur serangan PHP2Shell
Diagram penjelasan
①Permintaan tanpa loginPermintaan web yang bisa dikirim siapa saja
②Permintaan yang dibuat khususPHP membacanya sebelum kode WordPress
③Celah PHPMemori habis → data setengah jadi dipakai apa adanyaCVE-2026-109618Permintaan berikutnya memakai status permintaan yang sudah selesaiCVE-2026-109619
④Eksekusi kode di serverSitus diambil alih
✅ Versi yang sudah diperbaiki memblokir alur ini8.2.35 · 8.3.36 · 8.4.27 · 8.5.12

Serangan dimulai dengan permintaan tanpa login. Pada tahap ketika PHP membaca permintaan yang dibuat khusus itu sebelum kode WordPress, permintaan tersebut memicu salah satu dari dua celah dan berujung pada eksekusi kode di server. Versi yang sudah diperbaiki memblokir alur ini, jadi yang perlu dilakukan adalah menaikkan PHP situs ke versi yang sudah diperbaiki atau yang lebih baru.

[php -v] di terminal hanya menampilkan versi PHP bawaan baris perintah. Pada konfigurasi yang memasang beberapa versi PHP di satu server, seperti EA-PHP di cPanel atau alt-php di CloudLinux, versinya bisa berbeda dari yang dipakai situs. Karena itu, patokannya adalah nilai [Versi PHP] di Kesehatan Situs.

php -v
PHP 8.3.xx (cli) (built: Jun  3 2025 17:17:57) (NTS gcc x86_64)

3️⃣ Jika di bawah PHP 8.2: tanyakan backport ke hosting dan minta jika belum ada

Jika [Versi PHP] di Kesehatan Situs di bawah 8.2 (7.x, 8.0, atau 8.1), php.net tidak menyediakan versi patch resmi. Menurut tabel versi yang didukung di php.net (diperiksa 22 Oktober 2026), seri yang masih didukung hanya empat, yaitu 8.2, 8.3, 8.4, dan 8.5, dan versi resmi 8.1 ke bawah tidak lagi mendapat patch keamanan.

Sebagai gantinya, distribusi dan penyedia hosting kadang merilis paket yang tetap memakai nomor versi yang sama tetapi hanya memasukkan perbaikannya (backport). Paket 7.4.33, 8.0.30, dan 8.1.34 di server uji sebuah layanan managed hosting adalah salah satu contohnya. Changelog-nya memuat baris [Backported from 8.2.35 — CVE-2026-109618, CVE-2026-109619].

Walaupun nomor versinya sama, apakah perbaikannya sudah masuk bisa dicek dengan mencari nomor CVE di changelog paket. Di keluarga Debian dan Ubuntu, cari dengan perintah seperti [zcat /usr/share/doc/php8.2-cli/changelog.Debian.gz | grep 109618]. Di keluarga RPM bentuknya [rpm -q --changelog php-common | grep 109618]; sesuaikan nomor versi pada nama paket dengan versi yang dipakai situs.

Jadi, jika masih di bawah 8.2, pertama tanyakan ke penyedia hosting apakah backport sudah diterapkan, dan jika belum atau tidak bisa dipastikan, minta agar dinaikkan ke versi yang didukung (8.2 ke atas). Setelah dinaikkan, cek lagi nilai [Versi PHP] di Kesehatan Situs.

CISA menyarankan organisasi yang memakai 8.1 ke bawah dan tidak bisa langsung memperbarui agar menjaga sistem berbasis PHP mereka tetap offline sampai di-patch atau di-upgrade.

Jika Anda mengelola server sendiri dan memakai 8.1 ke bawah, Anda bisa memasang paket backport dari distribusi atau menerapkan patch kode sumber untuk 7.4, 8.0, dan 8.1 yang dirilis tim keamanan PHP. Meski begitu, seri ini sudah tidak didukung, jadi solusi sebenarnya adalah pindah ke versi yang didukung.

4️⃣ Jika PHP 8.2 ke atas: perbarui ke versi yang sudah di-patch lalu cek lagi

Jika sudah di 8.2 ke atas tetapi masih di bawah versi patch, perbarui PHP itu sendiri. Di managed hosting dan shared hosting, penyedia menerapkan patch ke seluruh server, jadi pastikan lewat pengumuman atau tim dukungan apakah patch sudah diterapkan dan build mana yang dipakai, lalu lihat apakah [Versi PHP] di Kesehatan Situs sudah berubah. Menurut pengumuman di halaman statusnya, Cloudways mulai menerapkan patch ke semua versi PHP yang didukungnya (5.6–8.4) pada 21 Oktober pukul 22:19 UTC. Pada 22 Oktober pukul 10:11 UTC, Cloudways mengumumkan bahwa pekerjaan itu selesai.

Di server yang Anda kelola sendiri, perbarui dengan paket dari repositori distribusi atau vendor LTS, sesuai pengumuman php.net. Sebelum memperbarui, periksa daftar paket yang akan berubah lewat pratinjau untuk memastikan hanya paket yang diawali php yang naik versi dan tidak ada paket lain yang ikut, dan jangan campur dengan pembaruan sistem operasi lainnya.

dnf upgrade --assumeno 'php*'
Dependencies resolved.
================================================================================
 Package       Architecture  Version         Repository  Size
================================================================================
Upgrading:
 php           x86_64  8.3.xx-1.…        …       1.9 M
 php-cli       x86_64  8.3.xx-1.…        …       5.6 M
 php-common    x86_64  8.3.xx-1.…        …       1.3 M
 php-fpm       x86_64  8.3.xx-1.…        …       1.9 M
 (baris paket ekstensi seperti php-gd · php-intl dihilangkan)

Transaction Summary
================================================================================
Upgrade  xx Packages
dnf upgrade 'php*'
Upgraded:
  php-8.3.xx-1.….x86_64
  php-cli-8.3.xx-1.….x86_64
  php-common-8.3.xx-1.….x86_64
  php-fpm-8.3.xx-1.….x86_64
  (baris paket ekstensi dihilangkan)

Complete!

Dalam pengujian ini, hanya paket yang diawali php yang naik ke versi patch, dan php-fpm memulai ulang sendiri saat instalasi paket selesai. Versi yang sudah diperbaiki baru berlaku setelah worker php-fpm dimulai ulang, jadi di lingkungan tanpa restart otomatis, jalankan sendiri [systemctl restart php-fpm].

Setelah diperbarui, pastikan [php -v] dan baris [Versi PHP] di tab [Info] Kesehatan Situs sama-sama menunjukkan versi patch atau yang lebih baru, lalu periksa juga status layanan php-fpm dan respons situs. Jika hanya nilai baris perintah yang berubah sementara [Versi PHP] tetap sama, mulai ulang php-fpm lalu periksa lagi.

Layar tab Info Kesehatan Situs: setelah pembaruan, memeriksa lagi bahwa baris Versi PHP di bagian Server sudah di versi patch atau lebih baru — menu kiri Peralatan › Kesehatan Situs serta baris Versi PHP dan PHP SAPI di bagian Server (WordPress 7.1.3)

Setelah pembaruan pun, bentangkan bagian [Server] di tab [Info] pada layar [Peralatan › Kesehatan Situs] yang sama dan lihat baris [Versi PHP]. Jika nilainya sudah berubah ke versi yang Anda pasang, berarti worker php-fpm juga sudah berjalan dengan versi baru.

php -v
PHP 8.3.xx (cli) (built: Oct 19 2026 14:00:34) (NTS gcc x86_64)
systemctl is-active php-fpm
active
curl -s -o /dev/null -w '%{http_code}\n' 'https://example.com/?r=1'
200

Untuk paket yang nomor versinya sendiri naik, patch dipastikan lewat nomor versi baru; untuk paket backport yang nomor versinya tetap, lewat nomor CVE di changelog. Server ini termasuk jenis pertama, jadi [rpm -q --changelog php-common] tidak memuat baris nomor CVE, dan patch dipastikan lewat nomor versi baru di baris pertama changelog.

5️⃣ Jika belum bisa langsung diperbarui: langkah sementara dari php.net

Untuk server yang tidak bisa langsung diperbarui, php.net menyebut pengaturan di bawah sebagai langkah sementara, sambil menegaskan bahwa langkah ini hanya mempersempit jalur serangan tertentu dan tidak membuat instalasi menjadi aman. php.net juga menulis agar tidak memasang batas memori lewat RLIMIT_AS atau RLIMIT_DATA sebagai gantinya, karena justru bisa memicu kegagalan alokasi yang rentan.

PengaturanNilaiDi manaYang dicegah
memory_limit-1php_admin_value di pool FPM atau konfigurasi Apache (agar tidak bisa dibatalkan aplikasi)CVE-2026-109618 · jalur kegagalan batas memori (tidak lengkap)
post_max_size8M (32M jika perlu unggahan) · upload_max_filesize lebih kecil dari ituphp.ini · konfigurasi poolCVE-2026-109618
session.upload_progress.enabled0 + mulai ulang semua workerphp.ini · pool FPM · konfigurasi server (tidak lewat ini_set() atau .user.ini)CVE-2026-109619 · hanya jalur sesi yang terkonfirmasi
fatal_error_backtraces0 + mulai ulang semua worker (hanya PHP 8.5)Sama seperti di atasCVE-2026-109619 · hanya jalur backtrace yang terkonfirmasi

php_admin_value adalah pengaturan sisi server yang tidak bisa dibatalkan aplikasi, sehingga pengguna shared hosting sering tidak bisa mengubahnya sendiri dan pada akhirnya tetap harus meminta ke penyedia hosting. php.net juga menyarankan pemberian batas atas, termasuk di tingkat server web atau proxy, untuk ukuran badan permintaan, jumlah kolom input, jumlah bagian multipart, jumlah header, dan kedalaman nesting.

🔢 FAQ & Konten yang Direkomendasikan

Pembaruan otomatis WordPress hanya mencakup inti, plugin, tema, dan terjemahan; PHP adalah program yang terpasang di server, sehingga yang memperbaruinya adalah admin server atau penyedia hosting. Pembaruan otomatis untuk inti, plugin, dan tema diaktifkan masing-masing di layar Pembaruan WordPress serta di layar Plugin dan Tema, dan versi PHP tidak muncul di layar-layar tersebut.

Detail teknis lengkapnya ada di dua imbauan keamanan GitHub yang ditautkan pengumuman php.net di samping nomor CVE. CVE-2026-109618 adalah GHSA-w8hw-w9fx-j79w, dan CVE-2026-109619 adalah GHSA-6wmf-4rv5-p3rp. Peringatan CERT-EU juga mencantumkan kedua imbauan yang sama sebagai referensi, dan detail untuk mereproduksi serangan tidak dimasukkan ke artikel ini.

CISA menyarankan untuk memantau proses worker PHP yang membuka shell atau mengunduh tool. CISA juga menulis bahwa sebelum patch diterapkan, web application firewall bisa memberi sedikit perlindungan. Karena PHP sering tertanam sebagai komponen perangkat lunak lain dan luput dari perhatian, CISA menyarankan untuk mulai dengan mendaftar sistem yang menjalankan PHP.

ℹ️ Pemberitahuan Afiliasi
Konten di situs ini berisi tautan afiliasi. Jika pengunjung membeli produk atau layanan melalui tautan tersebut, situs ini menerima komisi dari penjual. Harga yang dibayar pembeli(turun saat ada diskon promo ↓), tidak naik karena hal ini. Harga, diskon, dan informasi stok yang ditampilkan berlaku pada saat penulisan dan bisa berbeda dengan kondisi sebenarnya, jadi pastikan kembali di situs penjual sebelum membeli. Pemilihan dan penilaian produk dibuat berdasarkan standar kami sendiri, dan ada tidaknya komisi tidak memengaruhi urutan maupun isi penilaian.

Tinggalkan Balasan

Alamat email Anda tidak akan dipublikasikan. Ruas yang wajib ditandai *

Buktikan bahwa Anda manusia: 4   +   6   =