Home Cyber Security PHP2Shell Vulnerability: Ancaman RCE pada Server PHP

PHP2Shell Vulnerability: Ancaman RCE pada Server PHP

Yanuri 18 min read

PHP2Shell Vulnerability menjadi salah satu ancaman keamanan serius bagi server yang menjalankan PHP pada Oktober 2026. Kerentanan dengan identitas CVE-2026-109618 dan CVE-2026-109619 ini memungkinkan penyerang melakukan Remote Code Execution (RCE) tanpa autentikasi pada kondisi tertentu. Dengan tingkat keparahan CVSS v4.0 sebesar 9.2, kedua celah tersebut membutuhkan perhatian khusus dari administrator server, developer, dan pemilik website.

Temuan tersebut berasal dari penelitian keamanan yang dilakukan Wiz Research dan kemudian diperkuat oleh laporan aktivitas serangan di lapangan. Dampaknya tidak hanya menyasar aplikasi tertentu, tetapi juga menyentuh komponen inti PHP yang digunakan oleh berbagai platform, termasuk WordPress, Drupal, Joomla, dan aplikasi web berbasis PHP lainnya.

Situasi ini perlu mendapatkan perhatian serius, terutama bagi kamu yang mengelola VPS, shared hosting, maupun dedicated server. Sebab, penyerang berpotensi mengambil alih proses PHP, membaca informasi sensitif dari memori, hingga menjalankan perintah berbahaya pada sistem yang rentan.

Melalui artikel ini, kamu akan memahami penyebab munculnya kerentanan tersebut, mekanisme serangan, versi PHP yang terdampak, serta langkah pemeriksaan dan mitigasi yang dapat diterapkan untuk melindungi server.

Baca Juga: Cara Mengamankan Server Ubuntu dari Peretas

Apa Itu PHP2Shell? Mengenal Kerentanan Kritis pada PHP

PHP2Shell Vulnerability merupakan sebutan untuk rangkaian kelemahan keamanan pada mesin inti PHP yang dapat dimanfaatkan untuk menjalankan kode dari jarak jauh atau Remote Code Execution (RCE).

Berbeda dengan kerentanan yang hanya menyerang plugin, tema, atau aplikasi tertentu, masalah ini berada pada mekanisme internal PHP dalam mengelola memori dan memproses permintaan HTTP. Artinya, keamanan kode aplikasi yang sudah dibuat dengan baik belum tentu cukup untuk melindungi server apabila runtime PHP yang digunakan masih rentan.

PHP sendiri merupakan bahasa pemrograman server-side yang banyak digunakan untuk membangun website, sistem administrasi, API, dan berbagai aplikasi web. Popularitas tersebut membuat kerentanan pada komponen inti PHP memiliki potensi dampak yang luas.

1. Mengapa PHP2Shell Menjadi Ancaman Serius?

Ada beberapa alasan yang membuat kerentanan ini mendapatkan perhatian besar dari komunitas keamanan siber.

Tidak membutuhkan autentikasi: Penyerang dapat memanfaatkan jalur eksploitasi tertentu tanpa harus memiliki akun atau kredensial aplikasi.
Menyerang komponen inti PHP: Kerentanan berada pada runtime PHP, bukan hanya pada satu aplikasi atau framework.
Berpotensi menghasilkan RCE: Eksploitasi yang berhasil dapat memberikan kemampuan menjalankan kode dengan hak akses proses PHP.
Memungkinkan kebocoran memori: Informasi seperti token, password, API key, dan data sensitif lainnya berpotensi terbaca dari memori proses.
Memiliki cakupan penggunaan luas: Berbagai sistem yang menjalankan PHP untuk melayani permintaan web perlu mendapatkan perhatian.

Menurut publikasi Wiz Research pada 21 Oktober 2026, tim peneliti berhasil mendemonstrasikan eksploitasi terhadap beberapa platform CMS populer. Mereka juga menunjukkan bahwa kelemahan tersebut berasal dari PHP, sehingga tidak membutuhkan bug khusus pada aplikasi yang menjadi target.

Dengan demikian, PHP2Shell exploit bukan sekadar masalah kompatibilitas atau kesalahan konfigurasi aplikasi. Ini merupakan ancaman pada lapisan runtime yang perlu ditangani melalui pembaruan keamanan.

2. Hubungan PHP2Shell dengan Remote Code Execution

Remote Code Execution merupakan kondisi ketika seseorang dapat menjalankan instruksi atau kode pada sistem komputer dari lokasi lain melalui jaringan.

Dalam konteks PHP, penyerang berusaha memanfaatkan kesalahan pengelolaan memori agar alur eksekusi program tidak lagi berjalan sebagaimana mestinya. Jika berhasil, penyerang dapat memperoleh kemampuan yang seharusnya hanya dimiliki oleh proses PHP yang sah.

Namun, kemampuan penyerang tetap bergantung pada lingkungan eksekusi, konfigurasi server, serta hak akses akun yang menjalankan PHP.

Mengenal CVE-2026-109618 dan CVE-2026-109619

PHP2Shell mencakup dua identitas kerentanan yang memiliki akar masalah berbeda, tetapi sama-sama berpotensi menyebabkan eksekusi kode jarak jauh.

Kedua celah tersebut mendapatkan penilaian CVSS v4.0 sebesar 9.2 atau kategori Critical. PHP merilis perbaikan untuk cabang versi yang masih didukung pada 21 Oktober 2026.

1. CVE-2026-109618: Out-of-Memory Corruption

Kerentanan pertama berkaitan dengan mekanisme penanganan kondisi Out of Memory (OOM) ketika PHP sedang memproses permintaan.

OOM terjadi ketika sebuah proses tidak berhasil mendapatkan alokasi memori yang dibutuhkan. Dalam kondisi normal, PHP seharusnya menangani kegagalan tersebut dengan aman dan membersihkan struktur data internal yang sudah digunakan.

Masalah muncul ketika proses penanganan kesalahan memutus alur inisialisasi secara tiba-tiba. Akibatnya, beberapa struktur internal dapat tertinggal dalam kondisi belum sepenuhnya terbentuk.

Ketika proses pembersihan berjalan, PHP berpotensi memperlakukan data yang belum valid seolah-olah sudah siap digunakan. Kondisi ini dapat menyebabkan kerusakan memori dan membuka peluang bagi penyerang untuk memanipulasi alur eksekusi.

Dampaknya tidak berhenti pada kegagalan proses atau crash. Dalam kondisi eksploitasi yang sesuai, kelemahan ini dapat berkembang menjadi eksekusi kode dari jarak jauh.

2. CVE-2026-109619: Stale Global State dan Use-After-Free

Kerentanan kedua berkaitan dengan pengelolaan status internal PHP yang digunakan kembali oleh worker untuk menangani permintaan berikutnya.

Pada beberapa mekanisme PHP, worker dapat mempertahankan proses yang sama untuk melayani banyak HTTP request. Agar penggunaan memori berjalan efisien, PHP perlu membersihkan seluruh data milik permintaan sebelumnya sebelum memproses permintaan baru.

Masalah terjadi ketika sebuah referensi internal masih menunjuk ke area memori yang sebenarnya sudah dibebaskan. Kondisi ini dikenal sebagai Use-After-Free.

Ketika worker menerima permintaan berikutnya, bagian kode tertentu dapat membaca atau menggunakan kembali data yang sudah tidak valid tersebut. Akibatnya, proses PHP berpotensi mengalami kerusakan memori dan perubahan alur eksekusi.

Risiko menjadi lebih besar apabila penyerang dapat memengaruhi kondisi memori dan urutan pemrosesan request sehingga referensi yang sudah tidak valid tersebut dapat dimanfaatkan.

3. Perbedaan Kedua Kerentanan

Walaupun keduanya berkaitan dengan keamanan memori, terdapat perbedaan pada mekanisme pemicunya.

Aspek	Kerentanan pertama	Kerentanan kedua
Penyebab utama	Kesalahan penanganan OOM	Referensi memori yang sudah dibebaskan
Jenis masalah	Memory corruption	Use-After-Free dan stale state
Area terdampak	Request initialization dan cleanup	State internal antarrekuest
Potensi dampak	Memory corruption dan RCE	Memory corruption dan RCE
Penanganan utama	Memperbarui runtime PHP	Memperbarui runtime PHP

Kedua masalah tersebut menunjukkan bahwa pengelolaan memori merupakan bagian penting dari keamanan runtime. Kesalahan kecil pada proses inisialisasi atau pembersihan memori dapat berkembang menjadi celah keamanan yang serius.

Bagaimana Cara Kerja Serangan PHP2Shell?

Untuk memahami risiko serangan, kamu perlu mengetahui bagaimana PHP menangani permintaan HTTP sebelum aplikasi menjalankan logika bisnisnya.

Ketika pengguna membuka website, web server menerima permintaan dan meneruskannya ke PHP melalui mekanisme seperti PHP-FPM, mod_php, atau implementasi PHP lainnya. Selanjutnya, PHP memproses data permintaan, mengelola memori, dan menjalankan kode aplikasi.

PHP2Shell memanfaatkan kelemahan pada proses internal tersebut. Karena itu, serangan tertentu dapat terjadi sebelum aplikasi menyelesaikan proses inisialisasi normal.

1. Penyerang Mengirimkan HTTP Request yang Dirancang Khusus

Tahap awal serangan dimulai ketika penyerang mengirimkan permintaan HTTP yang memanfaatkan perilaku internal PHP.

Permintaan tersebut dapat memengaruhi proses parsing, alokasi memori, atau mekanisme pengelolaan data internal. Pada jalur tertentu, kondisi yang dihasilkan dapat memicu kesalahan OOM atau memanfaatkan status internal yang tertinggal dari request sebelumnya.

Hal penting yang perlu kamu pahami adalah bahwa serangan ini tidak selalu membutuhkan interaksi pengguna atau akses login.

2. PHP Mengalami Kesalahan Pengelolaan Memori

Setelah menerima permintaan yang telah dirancang, PHP dapat memasuki kondisi internal yang tidak normal.

Pada jalur OOM, proses inisialisasi atau pembersihan data dapat terganggu. Sementara itu, pada jalur Use-After-Free, worker dapat menggunakan referensi memori yang sudah tidak valid.

Kondisi tersebut menciptakan peluang bagi penyerang untuk memengaruhi data dan alur eksekusi program.

3. Penyerang Berusaha Mengendalikan Alur Eksekusi

Tahap berikutnya melibatkan manipulasi kondisi memori agar PHP tidak lagi menjalankan instruksi sesuai alur normal.

Penelitian Wiz menunjukkan bahwa eksploitasi membutuhkan rangkaian teknik yang kompleks, termasuk memahami tata letak memori dan perilaku worker pada lingkungan target.

Apabila seluruh kondisi yang dibutuhkan terpenuhi, penyerang dapat mencapai PHP remote code execution tanpa autentikasi.

4. Perintah Berbahaya Dijalankan dengan Hak Akses Proses PHP

Ketika eksploitasi berhasil, penyerang berpotensi menjalankan perintah dengan hak akses akun yang menjalankan PHP.

Sebagai contoh, jika PHP-FPM berjalan menggunakan akun khusus website, aktivitas berbahaya pada awalnya dapat berjalan dengan hak akses akun tersebut.

Namun, dampak akhirnya dapat menjadi lebih luas apabila proses PHP memiliki izin membaca file sensitif, mengakses database, menggunakan kredensial cloud, atau berkomunikasi dengan layanan internal.

Karena itu, prinsip least privilege sangat penting untuk membatasi dampak ketika sebuah proses berhasil dikompromikan.

Dampak PHP2Shell terhadap Keamanan Server

PHP RCE vulnerability memiliki tingkat risiko tinggi karena dapat membuka akses terhadap komponen penting dalam infrastruktur website.

Dampak eksploitasi tidak selalu sama pada setiap server. Beberapa faktor seperti konfigurasi PHP, hak akses worker, jumlah proses, serta aplikasi yang berjalan dapat memengaruhi hasil serangan.

Berikut beberapa risiko yang perlu diperhatikan oleh administrator server.

1. Pengambilalihan Proses PHP

Penyerang yang berhasil mengeksploitasi kelemahan dapat menjalankan perintah melalui proses PHP yang terdampak.

Jika akun PHP memiliki izin akses yang terlalu luas, penyerang berpotensi membaca atau memodifikasi file di luar kebutuhan aplikasi.

Kondisi ini dapat memperbesar ruang lingkup kompromi, terutama pada server yang menjalankan banyak website menggunakan akun sistem yang sama.

2. Kebocoran Password dan API Key

Memori proses PHP dapat menyimpan berbagai informasi sensitif selama aplikasi berjalan.

Contohnya meliputi:

Password koneksi database.
API key layanan pihak ketiga.
Access token dan session token.
Kredensial SMTP.
Informasi autentikasi aplikasi.
Data pengguna yang sedang diproses.

Penelitian Wiz menunjukkan bahwa eksploitasi tertentu dapat membaca informasi sensitif dari memori proses tanpa harus terlebih dahulu memperoleh eksekusi kode.

Oleh sebab itu, administrator tidak cukup hanya memperbarui PHP. Mereka juga perlu mengevaluasi kredensial yang mungkin telah terpapar.

3. Pemasangan Web Shell dan Backdoor

Apabila penyerang memperoleh kemampuan menjalankan kode, mereka dapat mencoba mempertahankan akses melalui mekanisme lain.

Salah satu kemungkinan adalah memasang web shell atau backdoor pada direktori website yang dapat ditulis oleh proses PHP.

File berbahaya tersebut dapat memberikan jalur akses tambahan ketika celah awal sudah diperbaiki.

Namun, keberhasilan pemasangan backdoor bergantung pada izin filesystem, konfigurasi server, dan kemampuan penyerang mempertahankan akses.

4. Pencurian Data dan Manipulasi Website

Server yang berhasil dikompromikan dapat menjadi sumber kebocoran data dan manipulasi konten.

Penyerang dapat mencoba mengakses database, mengambil informasi pelanggan, mengubah halaman website, atau memodifikasi file aplikasi.

Pada lingkungan bisnis, kondisi tersebut dapat mengganggu operasional, merusak reputasi, dan menimbulkan kerugian finansial.

5. Penyalahgunaan Server untuk Aktivitas Lain

Server yang telah dikuasai juga berpotensi digunakan untuk aktivitas berbahaya lainnya.

Contohnya adalah menjalankan proses tidak sah, mengirim spam, melakukan pemindaian jaringan, atau mencoba menyerang layanan lain yang dapat dijangkau dari server.

Inilah alasan mengapa keamanan PHP harus menjadi bagian dari strategi keamanan infrastruktur secara keseluruhan.

Versi PHP yang Terdampak PHP2Shell

Menurut pengumuman resmi PHP pada 21 Oktober 2026, pembaruan keamanan tersedia untuk empat cabang versi yang masih mendapatkan rilis perbaikan reguler.

Kamu perlu memperhatikan versi PHP yang benar-benar digunakan oleh aplikasi, bukan hanya versi PHP CLI yang muncul ketika menjalankan perintah di terminal.

1. Daftar Versi PHP yang Rentan

Berikut daftar versi terdampak dan versi pertama yang telah mendapatkan perbaikan resmi.

Cabang PHP	Versi terdampak	Versi perbaikan
PHP 8.5	Di bawah 8.5.12	8.5.12
PHP 8.4	Di bawah 8.4.27	8.4.27
PHP 8.3	Di bawah 8.3.36	8.3.36
PHP 8.2	Di bawah 8.2.35	8.2.35

Untuk PHP 8.1 dan versi lebih lama, situasinya berbeda karena cabang tersebut sudah tidak mendapatkan pembaruan reguler dari proyek PHP.

Meski demikian, beberapa distribusi Linux dan penyedia dukungan jangka panjang dapat menyediakan backport keamanan. Artinya, mereka memasukkan perbaikan ke paket lama tanpa harus mengubah nomor versi utama PHP.

Karena itu, jangan langsung menyimpulkan bahwa semua paket PHP dengan nomor versi lama pasti belum mendapatkan perbaikan. Periksa advisori keamanan dari vendor sistem operasi atau penyedia paket yang kamu gunakan.

2. Versi PHP yang Sudah Mendapatkan Patch Keamanan

Versi berikut merupakan rilis pertama yang memperbaiki kedua kerentanan tersebut:

PHP 8.5.12.
PHP 8.4.27.
PHP 8.3.36.
PHP 8.2.35.

Jika kamu menggunakan PHP 8.2, perlu diperhatikan bahwa cabang ini dijadwalkan mencapai akhir masa dukungan pada 31 Desember 2026. Karena itu, sebaiknya mulai rencanakan migrasi menuju cabang PHP yang masih mendapatkan dukungan.

3. Apakah PHP 8.1 dan Versi Lebih Lama Aman?

Tidak. PHP 8.1 dan versi sebelumnya tidak otomatis aman hanya karena sudah tidak mendapatkan pembaruan reguler.

Wiz Research menyebutkan bahwa temuan dalam rangkaian penelitian PHP2Shell mencakup versi PHP yang dirilis selama lebih dari satu dekade, termasuk versi lama hingga PHP 5.4.

PHP menyediakan backport sumber minimal untuk PHP 7.4, 8.0, dan 8.1 bagi pengguna yang membangun PHP sendiri atau tidak memiliki akses ke paket vendor LTS.

Jika kamu menjalankan versi lama, periksa apakah vendor menyediakan paket yang secara eksplisit mencakup perbaikan kedua kerentanan. Jika tidak tersedia, prioritaskan migrasi ke versi yang masih didukung.

Cara Memeriksa Apakah Server PHP Rentan

Sebelum melakukan pembaruan, kamu perlu mengidentifikasi seluruh instalasi PHP yang digunakan server.

Satu server Linux dapat menjalankan beberapa versi PHP sekaligus. Contohnya, website pertama menggunakan PHP 8.2, sedangkan website kedua menggunakan PHP 8.3 melalui pool PHP-FPM yang berbeda.

Berikut beberapa langkah pemeriksaan yang dapat kamu lakukan.

1. Memeriksa Versi PHP melalui Terminal

Jalankan perintah berikut melalui SSH:

php -v

Perintah tersebut menampilkan versi PHP CLI yang aktif pada terminal.

Contoh hasil:

PHP 8.3.35 (cli)

Jika server menggunakan versi tersebut, kamu perlu memeriksa paket dan runtime karena versi tersebut berada di bawah rilis perbaikan resmi untuk cabang PHP 8.3.

Namun, hasil php -v tidak selalu sama dengan versi PHP yang digunakan website. CLI dan PHP-FPM dapat menggunakan instalasi yang berbeda.

2. Memeriksa Instalasi PHP-FPM

Pada Ubuntu atau Debian, kamu dapat melihat paket PHP yang terpasang menggunakan:

dpkg -l | grep php

Untuk melihat proses PHP-FPM yang sedang berjalan:

ps aux | grep '[p]hp-fpm'

Jika menggunakan systemd, periksa layanan PHP-FPM:

systemctl list-units --type=service | grep php

Contohnya, server dapat menjalankan beberapa layanan berikut:

php8.2-fpm.service
php8.3-fpm.service
php8.4-fpm.service

Periksa setiap layanan karena pembaruan satu versi PHP tidak otomatis memperbaiki instalasi versi lainnya.

3. Memeriksa PHP yang Digunakan Website

Kamu dapat membuat file sementara untuk melihat informasi runtime PHP yang digunakan website.

Buat file bernama php-check.php di document root:

<?php
echo PHP_VERSION;

Buka file tersebut melalui browser untuk melihat versi PHP yang digunakan oleh website.

Metode ini membantu membedakan PHP CLI dan PHP yang benar-benar melayani permintaan web.

Setelah selesai, segera hapus file tersebut. Jangan meninggalkan file diagnostik di direktori publik karena informasi runtime dapat membantu pihak lain melakukan fingerprinting server.

4. Memeriksa Konfigurasi PHP dan Web Server

Selain versi, identifikasi bagaimana PHP terhubung dengan web server.

Beberapa konfigurasi yang perlu diperiksa meliputi:

Apache dengan mod_php.
Apache atau Nginx dengan PHP-FPM.
php-cgi.
FrankenPHP.
LiteSpeed dengan LSAPI.

Tim PHP menyatakan bahwa seluruh instalasi PHP yang melayani permintaan web perlu mendapatkan perhatian. Risiko eksploitasi yang telah didemonstrasikan paling tinggi pada konfigurasi Apache mod_php.

Namun, PHP-FPM dan implementasi lainnya juga tidak boleh dianggap aman tanpa pembaruan.

Cara Mengatasi dan Mencegah Serangan PHP2Shell

Langkah paling penting untuk menangani PHP2Shell adalah memperbarui runtime PHP ke versi yang sudah diperbaiki.

PHP security update harus menjadi prioritas administrator, terutama jika server menjalankan aplikasi yang dapat diakses secara langsung dari internet.

Selain itu, kamu perlu menerapkan beberapa langkah pengamanan tambahan agar dampak serangan dapat dibatasi.

1. Memperbarui PHP ke Versi yang Aman

Pada Ubuntu atau Debian yang menggunakan repositori resmi distribusi, kamu dapat memperbarui daftar paket terlebih dahulu:

sudo apt update

Selanjutnya, perbarui paket PHP yang digunakan.

Contoh untuk PHP 8.3:

sudo apt install --only-upgrade \
php8.3-cli \
php8.3-common \
php8.3-fpm

Jika kamu menggunakan ekstensi PHP tambahan, pastikan seluruh paket yang berkaitan juga mendapatkan pembaruan.

Perlu diingat, contoh tersebut hanya berlaku jika paket PHP yang digunakan tersedia melalui repositori sistem dan sudah memuat perbaikan keamanan.

Untuk server dengan beberapa versi PHP, lakukan pemeriksaan dan pembaruan pada setiap cabang yang digunakan.

Setelah pembaruan, periksa kembali versinya:

php8.3 -v

Kemudian restart PHP-FPM:

sudo systemctl restart php8.3-fpm

Sesuaikan nama layanan dengan versi PHP yang digunakan.

2. Memastikan PHP-FPM Menggunakan Runtime Terbaru

Memperbarui paket tidak selalu berarti seluruh worker langsung menggunakan kode terbaru.

Proses PHP-FPM yang sudah berjalan dapat tetap menggunakan kode dari runtime sebelum pembaruan sampai proses tersebut dimulai kembali.

Karena itu, setelah memperbarui PHP, restart seluruh layanan PHP-FPM yang relevan:

sudo systemctl restart php8.2-fpm
sudo systemctl restart php8.3-fpm
sudo systemctl restart php8.4-fpm

Jalankan hanya perintah untuk layanan yang benar-benar terpasang.

Jika menggunakan Apache mod_php, restart Apache:

sudo systemctl restart apache2

Jika menggunakan Nginx, pastikan PHP-FPM sudah berjalan menggunakan runtime terbaru sebelum memeriksa kembali website.

3. Membatasi Ukuran HTTP Request

Pembatasan ukuran request membantu mengurangi risiko penyalahgunaan jalur yang berkaitan dengan alokasi memori.

PHP menyediakan beberapa konfigurasi yang dapat digunakan:

post_max_size = 32M
upload_max_filesize = 30M

Nilai tersebut hanya contoh. Sesuaikan dengan kebutuhan aplikasi, terutama jika website menerima file berukuran besar.

Kamu juga dapat menerapkan batas ukuran request pada Nginx:

client_max_body_size 32M;

Setelah mengubah konfigurasi, periksa sintaks Nginx:

sudo nginx -t

Jika tidak ada kesalahan, muat ulang konfigurasi:

sudo systemctl reload nginx

Pembatasan tersebut membantu mengendalikan ukuran permintaan, tetapi tidak memperbaiki kerusakan memori pada PHP. Jadi, jangan menjadikannya pengganti pembaruan runtime.

4. Menonaktifkan Session Upload Progress sebagai Mitigasi Tambahan

Tim PHP merekomendasikan penonaktifan fitur session upload progress sebagai salah satu langkah mitigasi untuk jalur serangan tertentu.

Tambahkan konfigurasi berikut pada php.ini atau konfigurasi PHP-FPM yang berlaku sebelum pemrosesan request:

session.upload_progress.enabled = 0

Setelah itu, restart seluruh worker PHP-FPM.

Perlu diperhatikan bahwa langkah ini hanya mengurangi paparan terhadap jalur eksploitasi tertentu. Konfigurasi tersebut tidak menghilangkan seluruh risiko dan tidak menggantikan PHP security patch.

5. Menggunakan Web Application Firewall

Web Application Firewall (WAF) dapat membantu menyaring permintaan HTTP yang mencurigakan sebelum mencapai aplikasi.

Beberapa pilihan yang dapat digunakan antara lain:

Cloudflare WAF.
ModSecurity.
Nginx dengan aturan filtering.
Layanan proteksi dari penyedia hosting.

WAF dapat memberikan lapisan perlindungan tambahan, terutama ketika administrator belum dapat melakukan pembaruan secara langsung.

Namun, WAF bukan solusi permanen. Pola eksploitasi dapat berubah, sementara beberapa serangan memanfaatkan perilaku internal runtime yang sulit dideteksi hanya melalui pemeriksaan HTTP biasa.

6. Menerapkan Least Privilege pada PHP-FPM

Setiap website sebaiknya menjalankan PHP menggunakan akun sistem dengan hak akses sesuai kebutuhannya.

Contohnya, kamu dapat memisahkan pool PHP-FPM untuk setiap website:

[website_a]

user = website_a
group = website_a

listen = /run/php/website_a.sock

Dengan pemisahan tersebut, kompromi pada satu website tidak otomatis memberikan akses penuh terhadap file website lain.

Pastikan pula direktori konfigurasi, file environment, backup, dan kredensial database tidak memiliki izin baca yang terlalu luas.

7. Melakukan Audit Keamanan Setelah Pembaruan

Setelah menerapkan pembaruan, jangan langsung menganggap server sepenuhnya aman.

Periksa log akses web server, log PHP-FPM, serta aktivitas proses yang tidak biasa.

Beberapa lokasi log yang umum digunakan pada Ubuntu atau Debian antara lain:

/var/log/nginx/access.log
/var/log/nginx/error.log
/var/log/apache2/access.log
/var/log/apache2/error.log
/var/log/php8.3-fpm.log

Periksa juga beberapa indikator berikut:

File PHP baru yang tidak dikenal.
Perubahan pada file konfigurasi website.
Proses sistem yang menggunakan CPU secara tidak wajar.
Koneksi jaringan keluar yang tidak dikenal.
Akun pengguna atau SSH key yang tidak sah.
Perubahan pada scheduled task atau cron.

Jika menemukan indikasi kompromi, isolasi server dari jaringan publik sesuai kebutuhan, simpan bukti log, dan lakukan investigasi sebelum menghapus file yang mencurigakan.

Jika kredensial diduga telah terbaca dari memori, rotasi password database, API key, token, dan kredensial lain yang dapat diakses oleh proses PHP.

Apakah WordPress dan Aplikasi PHP Lainnya Terdampak?

Ya. WordPress dan aplikasi PHP lainnya dapat terdampak karena kerentanan berada pada mesin inti PHP, bukan hanya pada kode aplikasi.

Artinya, memperbarui WordPress, mengganti tema, atau menghapus plugin tertentu tidak otomatis memperbaiki masalah pada runtime PHP.

Wiz Research telah mendemonstrasikan dampak eksploitasi pada WordPress, Drupal, dan Joomla. Penelitian tersebut juga menunjukkan bahwa aplikasi PHP sederhana dapat terdampak selama menggunakan runtime yang rentan dan memenuhi kondisi eksploitasi.

1. WordPress

WordPress menggunakan PHP untuk menjalankan proses inti, plugin, tema, dan berbagai fungsi website.

Jika server menjalankan PHP yang belum mendapatkan perbaikan, website WordPress tetap berpotensi terdampak meskipun seluruh plugin dan tema sudah diperbarui.

Untuk pengguna WordPress, beberapa langkah yang perlu dilakukan meliputi:

Periksa versi PHP yang digunakan website.
Perbarui runtime PHP pada server hosting.
Perbarui WordPress dan seluruh plugin.
Periksa file yang berubah secara tidak wajar.
Audit akun administrator.
Periksa konfigurasi database dan kredensial aplikasi.

2. Laravel dan Framework PHP Lainnya

Laravel, Symfony, CodeIgniter, dan framework PHP lainnya juga menggunakan runtime PHP untuk menjalankan aplikasi.

Framework yang sudah menggunakan versi terbaru belum tentu aman apabila PHP yang menjalankannya masih rentan.

Sebagai contoh, aplikasi Laravel yang berjalan menggunakan PHP-FPM tetap membutuhkan pembaruan runtime pada server.

Selain itu, administrator perlu memeriksa worker queue, scheduler, dan proses PHP jangka panjang lainnya agar tidak ada proses lama yang masih menggunakan runtime sebelum pembaruan.

3. Drupal dan Joomla

Drupal dan Joomla merupakan platform CMS yang menggunakan PHP sebagai komponen utama.

Keduanya dapat terdampak ketika runtime PHP yang digunakan belum mendapatkan perbaikan.

Karena itu, pembaruan CMS perlu berjalan bersamaan dengan pembaruan PHP. Jangan hanya berfokus pada aplikasi, sementara komponen runtime yang menjalankannya masih rentan.

4. Aplikasi PHP dalam Docker

Pengguna Docker juga perlu memperhatikan kerentanan ini.

Jika aplikasi menggunakan image PHP versi lama, memperbarui PHP yang terpasang pada host tidak otomatis memperbarui runtime di dalam container.

Sebagai contoh, konfigurasi berikut masih menggunakan image dengan tag versi tertentu:

services:
  app:
    image: php:8.3.35-fpm
    restart: unless-stopped

Kamu perlu mengganti image tersebut ke versi yang sudah mendapatkan perbaikan:

services:
  app:
    image: php:8.3.36-fpm
    restart: unless-stopped

Kemudian tarik image terbaru dan buat ulang container:

docker compose pull
docker compose up -d --force-recreate

Pastikan aplikasi tetap berjalan normal setelah perubahan.

Jangan lupa memeriksa image turunan, container worker, serta service lain yang mungkin masih membawa runtime PHP versi lama.

Kesimpulan: Pentingnya Memperbarui PHP untuk Keamanan Server

PHP2Shell menjadi pengingat bahwa keamanan sebuah website tidak hanya bergantung pada kualitas kode aplikasi, tetapi juga pada keamanan runtime dan infrastruktur yang menjalankannya.

Kedua kerentanan tersebut menunjukkan bagaimana kesalahan pengelolaan memori pada komponen inti PHP dapat berkembang menjadi ancaman serius. Bahkan, aplikasi yang tidak memiliki bug khusus tetap dapat terdampak ketika menggunakan runtime yang rentan.

Laporan eksploitasi nyata pada 26 Oktober 2026 semakin memperkuat alasan bagi administrator untuk segera melakukan pemeriksaan dan pembaruan.

Bagi kamu yang mengelola VPS, website WordPress, aplikasi Laravel, atau layanan berbasis PHP lainnya, prioritaskan tiga tindakan berikut:

Identifikasi seluruh instalasi PHP yang melayani permintaan web.
Perbarui runtime ke versi yang sudah mendapatkan perbaikan atau gunakan paket backport resmi dari vendor.
Audit log, file, proses, dan kredensial untuk menemukan kemungkinan kompromi.

PHP security update bukan sekadar pekerjaan pemeliharaan rutin. Pembaruan tersebut merupakan bagian penting dari perlindungan server terhadap ancaman yang terus berkembang.

Pastikan pula seluruh container, worker, dan aplikasi yang menggunakan PHP telah menjalankan runtime yang aman. Dengan pendekatan tersebut, kamu dapat mengurangi risiko serangan dan menjaga infrastruktur website tetap terlindungi.

Referensi resmi dan sumber penelitian: