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

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.

Pengumuman php.net menyebutkan bahwa 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.

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.

Baris [PHP SAPI] tepat di bawah [Versi PHP] menunjukkan cara PHP dijalankan; fpm-fcgi berarti konfigurasi PHP-FPM. Karena celahnya ada di dalam mesin PHP yang membaca permintaan, konfigurasi ini juga terdampak, dan pengumuman php.net menyebut Apache mod_php sebagai konfigurasi paling berbahaya. Di sini cukup lihat dua baris di bagian [Server], yaitu [Versi PHP] dan [PHP SAPI].

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)

Di server yang tidak bisa dimasuki lewat layar admin, cari versi yang dipakai situs dari proses PHP-FPM yang berjalan untuk menangani permintaan web. Pada paket Debian dan Ubuntu, nomor versi ada di jalur file konfigurasi yang dibaca oleh master FPM, dan di bawah ini hasil pemeriksaan di server uji Debian 12 milik sebuah layanan managed hosting.

ps -eo user,args | grep '[p]hp-fpm'

root     php-fpm: master process (/etc/php/8.2/fpm/php-fpm.conf)
abcdefg+ php-fpm: pool abcdefghij-82
klmnopq+ php-fpm: pool klmnopqrst-82

Angka 8.2 di jalur konfigurasi adalah versi PHP yang dipakai situs di server ini, dan hosting ini juga menambahkan nomor versi di akhir nama pool (-82). File yang dijalankan layanan FPM yang aktif juga bisa dilihat di baris [Main PID] pada [systemctl status], dan tetap ditampilkan meskipun bukan akun root.

systemctl status php8.2-fpm --no-pager | head -6

● php8.2-fpm.service - The PHP 8.2 FastCGI Process Manager
     Loaded: loaded (/lib/systemd/system/php8.2-fpm.service; enabled; preset: enabled)
     Active: active (running) since Thu 2026-10-22 07:14:57 UTC; 7h ago
       Docs: man:php-fpm8.2(8)
    Process: <PID> ExecStartPost=/usr/lib/php/php-fpm-socket-helper install /run/php/php-fpm.sock /etc/php/8.2/fpm/pool.d/www.conf 82 (code=exited, status=0/SUCCESS)
   Main PID: <PID> (php-fpm8.2)

Pada paket bawaan distribusi keluarga RHEL seperti AlmaLinux, jalur konfigurasi master adalah /etc/php-fpm.conf sehingga nomor versi tidak muncul; dalam hal ini, cek versi paket FPM dengan [rpm -qf /usr/sbin/php-fpm].

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.

Dukungan keamanan seri 8.2 berakhir pada 31 Desember 2026, jadi jika memperbarui sekarang, pilih 8.3 ke atas.

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; jika barisnya muncul, berarti paket itu sudah berisi perbaikan. Di keluarga Debian dan Ubuntu, cari seperti di bawah ini, dan sesuaikan nomor versi di jalurnya dengan versi yang dipakai situs.

zcat /usr/share/doc/php8.2-cli/changelog.Debian.gz | grep 109618

   + (CVE-2026-109618, CVE-2026-109619): Avoid state corruption via

Di keluarga RPM, cari dengan perintah di bawah ini.

rpm -q --changelog php-common | grep 109618

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. 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. Cloudways memberi tahu lewat pengumuman di halaman statusnya bahwa pada 21 Oktober pukul 22:19 UTC patch untuk PHP 5.6, 7.4, dan 8.0–8.4 sedang diterapkan, lalu pada 22 Oktober pukul 10:11 UTC menyatakan bahwa penerapannya sudah 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.

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.

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.

Pengaturan session.upload_progress.enabled di tabel kembali direkomendasikan dalam informasi php.net tanggal 23 Oktober. Untuk ikut menutup jalur eksekusi kode jarak jauh yang kemungkinannya kecil (CVE-2026-115560), php.net menyarankan agar nilai ini dibiarkan 0 sampai versi perbaikan bug reguler berikutnya. Pengaturan ini sudah tercantum sebagai mitigasi dalam advisori GHSA-6wmf-4rv5-p3rp tanggal 21 Oktober, jadi jika sudah diterapkan saat itu, biarkan saja.

Jalur ini hanya muncul jika aplikasi yang di konfigurasinya menyetel session.serialize_handler ke php_binary atau php_serialize mengubahnya menjadi php dengan ini_set() sebelum session_start(), dan fitur progres unggahan sesi juga aktif. Jika hanya melihat jalur CVE-2026-115560, php.net menyatakan bahwa aplikasi yang tidak mengubah metode serialisasi saat berjalan bisa tetap memakai fitur ini dalam keadaan aktif.

🔢 FAQ & Konten yang Direkomendasikan

🔗 Konten yang Direkomendasikan

Keamanan Keamanan WP: keamanan wp-admin Pengaturan yang melindungi layar admin dengan mengubah alamat login, membatasi percobaan login, dan memblokir XML-RPC. Lihat artikel →

Keamanan Celah keamanan wp-config.php Cara mencegah file wp-config.php terekspos dan memperkuat pengaturan keamanannya. Keamanan WordPress XML-RPC Cara mengenali serangan xmlrpc.php lewat log dan tiga cara menonaktifkannya. Server peringatan php-fpm max_children Pengujian nyata yang menemukan penyebab peringatan lewat log sebelum menambah worker.

ℹ️ 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.