Keamanan server web bukan hanya bergantung pada kualitas kode aplikasi, konfigurasi firewall, atau penggunaan sertifikat SSL. Komponen inti yang menjalankan aplikasi juga harus selalu diperbarui. Salah satu contohnya adalah PHP, bahasa pemrograman server-side yang digunakan oleh banyak website, termasuk WordPress, Drupal, Joomla, dan berbagai aplikasi web berbasis PHP.

Pada 21 Oktober 2026, tim PHP merilis pembaruan keamanan darurat untuk mengatasi dua kerentanan kritis yang dikenal sebagai PHP2Shell, yaitu CVE-2026-109618 dan CVE-2026-109619. Kedua kerentanan tersebut memiliki skor CVSS v4.0 sebesar 9,2 dan berpotensi memungkinkan penyerang mengeksekusi kode dari jarak jauh tanpa autentikasi.

Ancaman ini perlu mendapatkan perhatian serius dari administrator sistem, pengelola VPS, tim DevOps, administrator WordPress, serta pengelola infrastruktur hosting.

Masalahnya, kerentanan tersebut berada pada runtime PHP, bukan semata-mata pada kode aplikasi. Artinya, memperbarui WordPress, mengganti plugin, atau memperkuat validasi formulir tidak otomatis menyelesaikan kerentanan pada PHP yang mendasarinya.

Artikel ini membahas cara memahami ancaman PHP2Shell, memeriksa versi PHP, melakukan pembaruan pada server Linux, memvalidasi keberhasilan patch, dan mencari indikasi kompromi setelah serangan.

Tujuannya bukan sekadar membuat server kembali menjalankan aplikasi, tetapi memastikan pembaruan benar-benar diterapkan dan risiko serangan lanjutan dapat dikendalikan.

Apa Itu PHP2Shell?

PHP2Shell adalah sebutan untuk dua kerentanan keamanan pada mesin inti PHP yang dapat dimanfaatkan untuk mencapai remote code execution atau RCE.

RCE merupakan kondisi ketika penyerang dapat membuat sistem target menjalankan kode atau perintah yang dipilihnya dari jarak jauh. Jika eksploitasi berhasil, penyerang dapat melakukan tindakan sesuai hak akses proses yang berhasil dikompromikan.

Sebagai contoh, apabila proses PHP berjalan menggunakan akun www-data, penyerang yang berhasil mengeksploitasi kerentanan mungkin memperoleh kemampuan menjalankan perintah dengan hak akses akun tersebut.

Dampaknya dapat meliputi:

• Membaca berkas konfigurasi yang dapat diakses oleh proses web.
• Mengakses kredensial database yang tersimpan dalam konfigurasi aplikasi.
• Memodifikasi berkas website apabila izin sistem memungkinkan.
• Menanam web shell atau mekanisme persistensi.
• Mengunduh dan menjalankan program tambahan.
• Menjadikan server sebagai titik awal untuk mencoba menyerang sistem lain.

Dampak aktual bergantung pada konfigurasi server, hak akses akun layanan, isolasi aplikasi, dan kemampuan eksploitasi yang digunakan.

Mengapa PHP2Shell berbahaya?

Dalam aplikasi web biasa, permintaan HTTP akan melewati web server, diteruskan ke PHP, lalu diproses oleh kode aplikasi. Namun, kerentanan pada runtime dapat terjadi sebelum kode aplikasi dijalankan.

Konsekuensinya, autentikasi aplikasi tidak selalu menjadi penghalang. Jika jalur rentan dapat dicapai sebelum pemeriksaan login, penyerang mungkin tidak perlu memiliki akun WordPress atau kredensial pengguna untuk mencoba eksploitasi.

Peneliti keamanan juga melaporkan upaya eksploitasi terhadap kerentanan ini di sekitar waktu pengungkapan publik. Karena itu, administrator sebaiknya tidak menunda pembaruan hanya karena belum melihat gejala serangan pada log server.

Analogi sederhana

Bayangkan sebuah gedung memiliki pintu utama dengan sistem kartu akses yang aman. Namun, mekanisme pengunci elektronik di dalam pintu memiliki kerusakan.

Walaupun sistem kartu akses bekerja dengan benar, kerusakan pada mekanisme pengunci tetap dapat membahayakan gedung.

Dalam analogi ini, aplikasi web adalah sistem akses, sedangkan runtime PHP merupakan salah satu komponen yang menjalankan proses di baliknya. Memperbaiki aplikasi saja tidak cukup apabila komponen inti masih rentan.

Mengenal Dua Kerentanan PHP2Shell

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

Kerentanan pertama berkaitan dengan penanganan kondisi out-of-memory atau OOM.

OOM terjadi ketika proses tidak dapat memperoleh alokasi memori yang dibutuhkan. Dalam kondisi tertentu, PHP dapat mengalami ketidakkonsistenan pada data internal ketika penanganan permintaan dihentikan secara abnormal.

Jika proses pembersihan permintaan berikutnya menggunakan data yang belum diinisialisasi secara benar, kondisi tersebut berpotensi dimanfaatkan untuk menjalankan kode.

Risiko utamanya adalah penyerang dapat memicu jalur kesalahan memori melalui permintaan jaringan yang dibuat secara khusus.

Administrator perlu memahami bahwa menaikkan batas memori saja bukan solusi keamanan yang memadai. Perubahan konfigurasi sementara pun tidak menggantikan perbaikan pada kode PHP.

2. CVE-2026-109619: Stale Global State

Kerentanan kedua berkaitan dengan state internal PHP yang masih merujuk ke memori permintaan sebelumnya, meskipun memori tersebut sudah dibebaskan.

Kondisi seperti ini berhubungan dengan masalah use-after-free. Ketika memori yang sudah tidak valid tetap digunakan, perilaku program dapat menjadi tidak terduga dan membuka peluang eksploitasi.

Dalam kondisi yang sesuai, kerentanan ini berpotensi mengakibatkan kebocoran memori atau eksekusi kode dari jarak jauh.

Salah satu jalur yang dibahas dalam analisis keamanan berkaitan dengan mekanisme session upload progress PHP. Namun, menonaktifkan fitur tersebut bukan perlindungan menyeluruh terhadap seluruh variasi serangan.

Ringkasan perbandingan

Aspek	CVE-2026-109618	CVE-2026-109619
Jenis masalah	Korupsi memori saat OOM	Penggunaan state atau memori yang sudah tidak valid
Dampak potensial	Remote code execution	Kebocoran memori dan remote code execution
Autentikasi	Tidak diperlukan pada jalur rentan yang dilaporkan	Tidak diperlukan pada jalur rentan yang dilaporkan
Skor CVSS v4.0	9,2	9,2
Tindakan utama	Perbarui PHP ke versi yang diperbaiki	Perbarui PHP ke versi yang diperbaiki

Kedua kerentanan ini memiliki akar masalah berbeda, tetapi kesimpulan mitigasinya sama: prioritaskan pembaruan PHP ke versi yang telah diperbaiki oleh vendor.

Versi PHP yang Rentan dan Versi Perbaikan

PHP merilis pembaruan untuk cabang yang masih didukung. Berdasarkan advisori keamanan yang diterbitkan pada 21 Oktober 2026, versi perbaikan yang diumumkan adalah sebagai berikut.

Cabang PHP	Versi sebelum perbaikan	Versi perbaikan
PHP 8.5	8.5.11 dan sebelumnya	8.5.12
PHP 8.4	8.4.26 dan sebelumnya	8.4.27
PHP 8.3	8.3.35 dan sebelumnya	8.3.36
PHP 8.2	8.2.34 dan sebelumnya	8.2.35

PHP 8.1 dan versi yang lebih lama juga perlu mendapat perhatian. Cabang yang sudah mencapai akhir masa dukungan tidak otomatis memperoleh pembaruan resmi melalui rilis standar. Untuk versi lama, administrator harus memeriksa ketersediaan patch dari distribusi Linux, vendor hosting, atau backport resmi yang sesuai.

Penting: nomor versi di atas merupakan acuan rilis upstream PHP. Paket dari Debian, Ubuntu, dan vendor enterprise dapat menerapkan perbaikan melalui backport tanpa mengubah nomor versi upstream yang ditampilkan. Oleh sebab itu, jangan menyimpulkan bahwa suatu paket pasti rentan hanya berdasarkan nomor versi CLI. Periksa status keamanan paket dan changelog vendor.

Dampak PHP2Shell terhadap WordPress dan Website PHP

WordPress menggunakan PHP untuk menjalankan logika aplikasi, memproses permintaan pengguna, mengakses database, serta menjalankan plugin dan tema.

Apabila runtime PHP yang digunakan masih rentan, website WordPress berpotensi terdampak meskipun WordPress core, plugin, dan tema telah diperbarui.

Risiko serupa juga berlaku untuk Drupal, Joomla, dan aplikasi PHP lainnya. Layanan yang menggunakan PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, atau LiteSpeed perlu diinventarisasi dan diperiksa sesuai konfigurasi masing-masing.

Beberapa kemungkinan dampak pada server produksi antara lain:

• Kerahasiaan: berkas konfigurasi, kredensial, atau data yang dapat dibaca akun layanan berpotensi terekspos.
• Integritas: penyerang mungkin mengubah berkas aplikasi atau konten website jika izin akses memungkinkan.
• Ketersediaan: proses PHP dapat terganggu, mengalami crash, atau digunakan untuk aktivitas yang menghabiskan sumber daya.
• Persistensi: penyerang yang berhasil masuk dapat mencoba mempertahankan akses melalui berkas, akun, atau tugas terjadwal.
• Pergerakan lateral: apabila akun layanan memiliki akses yang terlalu luas ke jaringan internal, insiden dapat meluas ke sistem lain.

Tidak semua dampak tersebut pasti terjadi pada setiap server. Dampak aktual bergantung pada keberhasilan eksploitasi, hak akses, kontrol keamanan, dan kondisi lingkungan.

Materi Praktis: Strategi Mengamankan Server dari PHP2Shell

Pendekatan yang disarankan adalah melakukan inventarisasi, pembaruan, validasi, dan pemeriksaan kemungkinan kompromi secara berurutan.

1. Inventarisasi seluruh instalasi PHP

Periksa versi PHP CLI, PHP-FPM, Apache mod_php, container Docker, serta runtime yang digunakan setiap website. Jangan hanya memeriksa satu versi PHP pada server yang menjalankan beberapa aplikasi.

2. Identifikasi paket dan sumber instalasi

Tentukan apakah PHP berasal dari repositori resmi distribusi, PPA, repositori pihak ketiga, kompilasi manual, image container, atau paket dari penyedia hosting.

3. Terapkan pembaruan keamanan

Gunakan versi yang telah diperbaiki atau paket vendor yang secara resmi menyertakan perbaikan untuk kedua CVE. Siapkan backup dan rencana rollback sebelum perubahan pada server produksi.

4. Muat ulang runtime yang benar

Restart atau reload layanan yang relevan agar proses PHP menggunakan kode yang telah diperbarui. Pastikan container dan worker lama tidak terus berjalan dengan runtime rentan.

5. Validasi dan lakukan threat hunting

Periksa status patch, fungsi website, log web server, log PHP, proses anak yang mencurigakan, perubahan berkas, dan kemungkinan persistensi.

Tutorial Step-by-Step: Patch PHP2Shell pada Ubuntu Server dan Debian

Panduan berikut ditujukan untuk administrator Linux yang menjalankan website produksi menggunakan PHP dari paket APT. Sesuaikan langkah dengan sumber paket dan arsitektur layanan di server.

Langkah 1. Identifikasi versi PHP CLI

Jalankan:

php -v

Untuk melihat lokasi binary yang digunakan:

command -v php
readlink -f "$(command -v php)"

Perintah ini membantu mengidentifikasi versi PHP CLI. Namun, versi CLI belum tentu sama dengan versi PHP yang melayani website.

Langkah 2. Identifikasi layanan web dan PHP-FPM

Periksa layanan terkait:

systemctl --type=service --state=running |
  grep -Ei 'php|apache2|nginx|httpd|lsws'

Periksa paket PHP yang terpasang:

dpkg-query -W -f='${binary:Package}\t${Version}\n' \
  'php*' 2>/dev/null

Jika server menggunakan PHP-FPM, periksa proses dan socket-nya:

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

Perhatikan bahwa layanan PHP-FPM dapat memiliki beberapa versi sekaligus, misalnya php8.2-fpm dan php8.3-fpm. Website tertentu mungkin masih diarahkan ke versi lama meskipun versi CLI telah diperbarui.

Langkah 3. Periksa sumber paket

Jalankan:

apt-cache policy php-cli php-fpm

Untuk memeriksa paket tertentu:

apt-cache policy php8.3-fpm php8.3-cli

Sesuaikan nama paket dengan versi yang digunakan.

Jika paket berasal dari repositori resmi distribusi, cari informasi pembaruan keamanan dan changelog paket tersebut. Jika menggunakan PPA atau repositori pihak ketiga, verifikasi bahwa repositori itu telah menyediakan build yang diperbaiki.

Jangan mencampur paket dari sumber yang tidak kompatibel hanya untuk mendapatkan nomor versi tertentu.

Langkah 4. Lakukan backup dan persiapan maintenance

Sebelum mengubah PHP pada server produksi:

1. Backup database dan berkas aplikasi.
2. Simpan konfigurasi PHP, web server, dan PHP-FPM.
3. Pastikan backup dapat dipulihkan.
4. Periksa kompatibilitas aplikasi dengan versi PHP target.
5. Tentukan waktu maintenance jika restart berpotensi mengganggu layanan.

Contoh membuat salinan konfigurasi PHP:

sudo tar -czf \
  "/root/php-config-backup-$(date +%F-%H%M%S).tar.gz" \
  /etc/php

Perintah tersebut hanya mencadangkan konfigurasi di /etc/php. Ini bukan backup database atau keseluruhan website. Simpan arsip di lokasi yang terlindungi dan pastikan kapasitas disk mencukupi.

Langkah 5. Perbarui paket PHP

Perbarui metadata repositori:

sudo apt update

Lihat paket yang dapat diperbarui:

apt list --upgradable 2>/dev/null |
  grep -Ei 'php|libapache2-mod-php'

Setelah memastikan repositori menyediakan pembaruan yang sesuai, perbarui paket PHP yang digunakan.

Contoh untuk instalasi berbasis PHP 8.3:

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

Tambahkan paket ekstensi yang memang terpasang dan diperlukan aplikasi, misalnya php8.3-mysql, php8.3-curl, atau php8.3-xml.

Catatan: nama paket di atas adalah contoh. Jangan menyalinnya secara membabi buta ke server yang menggunakan PHP 8.2, PHP 8.4, paket vendor khusus, atau instalasi kompilasi manual. Pastikan pembaruan yang ditawarkan benar-benar memuat perbaikan PHP2Shell.

Jika repositori distribusi belum menyediakan paket perbaikan, gunakan kanal pembaruan keamanan resmi yang kompatibel atau ikuti petunjuk vendor. Jangan memaksakan upgrade lintas cabang PHP tanpa menguji kompatibilitas aplikasi.

Langkah 6. Restart layanan yang relevan

Untuk PHP-FPM 8.3, misalnya:

sudo systemctl restart php8.3-fpm
sudo systemctl status php8.3-fpm --no-pager

Jika menggunakan Apache:

sudo apache2ctl configtest
sudo systemctl reload apache2

Jika menggunakan Nginx:

sudo nginx -t
sudo systemctl reload nginx

Sesuaikan dengan arsitektur aktual. Jika menggunakan Apache mod_php, layanan PHP-FPM mungkin tidak digunakan. Jika menggunakan container, pembaruan harus diterapkan pada image dan container yang relevan.

Restart bukan pengganti patch. Tujuannya adalah memastikan proses yang sedang berjalan menggunakan kode yang telah diperbaiki.

Langkah 7. Verifikasi versi dan status paket

Periksa kembali:

php -v
dpkg-query -W -f='${binary:Package}\t${Version}\n' \
  'php*' 2>/dev/null

Lalu periksa layanan:

systemctl --no-pager --failed

Periksa log PHP-FPM sesuai versi:

sudo journalctl -u php8.3-fpm \
  --since "30 minutes ago" --no-pager

Ganti nama layanan dan rentang waktu sesuai kebutuhan.

Jangan berhenti pada hasil php -v. Pastikan paket yang digunakan oleh web server telah diperbaiki, worker sudah menggunakan runtime baru, dan aplikasi berfungsi normal.

Langkah 8. Uji website dan aplikasi

Periksa:

• Halaman utama dan halaman login.
• Koneksi database.
• Fitur unggah dan unduh berkas.
• Plugin atau modul penting.
• Proses background dan cron job.
• Log error PHP, Apache, atau Nginx.

Jika aplikasi mengalami error setelah pembaruan, cari penyebab kompatibilitasnya. Hindari menurunkan versi PHP kembali ke versi rentan sebagai solusi permanen.

Langkah 9. Jika PHP berjalan di Docker

Periksa container dan image:

docker ps --format \
  'table {{.Names}}\t{{.Image}}\t{{.Status}}'

Perbarui Dockerfile atau image dasar ke image PHP yang telah diperbaiki, kemudian build ulang dan deploy sesuai prosedur.

Contoh:

FROM php:8.3.36-fpm

Baris tersebut hanya contoh image upstream. Pastikan image benar-benar tersedia pada registry yang digunakan dan telah diperiksa. Image distribusi yang menggunakan backport mungkin memiliki penomoran berbeda.

Setelah deployment, periksa image aktual yang digunakan container dan pastikan container lama tidak tertinggal. Jangan menganggap memperbarui PHP di host otomatis memperbarui PHP di dalam container.

Mitigasi Sementara Jika Patch Belum Tersedia

Pembaruan PHP merupakan tindakan utama. Jika patch belum dapat diterapkan karena kendala kompatibilitas atau ketersediaan paket, administrator perlu mengurangi paparan sementara sambil mempercepat proses remediasi.

Tim PHP dan peneliti keamanan membahas sejumlah mitigasi untuk jalur serangan tertentu. Namun, mitigasi tersebut tidak menghilangkan seluruh risiko PHP2Shell.

Langkah sementara yang dapat dipertimbangkan meliputi:

• Membatasi akses jaringan ke aplikasi yang terdampak, terutama endpoint publik yang tidak perlu tersedia untuk umum.
• Menerapkan pembatasan ukuran permintaan HTTP pada reverse proxy atau web server sesuai kebutuhan aplikasi.
• Mengurangi post_max_size apabila ukuran unggahan yang lebih besar tidak diperlukan.
• Mempertimbangkan pengaturan memory_limit sesuai rekomendasi advisori PHP dan karakteristik aplikasi.
• Menonaktifkan session.upload_progress.enabled jika sesuai kebutuhan, setelah mengevaluasi dampak pada aplikasi.
• Mempertimbangkan pengaturan fatal_error_backtraces pada PHP 8.5 sesuai petunjuk advisori.
• Merencanakan pembaruan dan restart runtime sesegera mungkin.

Jangan menerapkan konfigurasi tersebut tanpa memahami dampaknya. Misalnya, mengubah batas memori dapat memengaruhi aplikasi yang memerlukan proses intensif. Konfigurasi yang mengurangi satu jalur eksploitasi juga belum tentu mencegah jalur lainnya.

Jangan menggunakan memory_limit=-1 secara sembarangan. Walaupun pengaturan tersebut dibahas sebagai mitigasi untuk jalur CVE tertentu dalam advisori PHP, meniadakan batas memori dapat meningkatkan risiko konsumsi sumber daya berlebihan. Ikuti petunjuk vendor, evaluasi konfigurasi, dan utamakan patch.

Threat Hunting: Mendeteksi Indikasi Eksploitasi PHP2Shell

Memperbarui PHP hanya menyelesaikan kerentanan yang diperbaiki. Tindakan itu tidak otomatis menghapus web shell, malware, atau perubahan berbahaya yang mungkin sudah masuk sebelum patch diterapkan.

Karena itu, server yang sebelumnya terpapar perlu diperiksa, khususnya apabila PHP dapat diakses langsung dari internet.

1. Periksa log web server

Untuk Apache pada Debian atau Ubuntu:

sudo tail -n 200 /var/log/apache2/access.log
sudo tail -n 200 /var/log/apache2/error.log

Untuk Nginx:

sudo tail -n 200 /var/log/nginx/access.log
sudo tail -n 200 /var/log/nginx/error.log

Cari pola yang tidak biasa, seperti lonjakan permintaan POST, banyaknya permintaan multipart, respons HTTP 500 berulang, atau permintaan besar yang tidak sesuai pola penggunaan normal.

Contoh pencarian awal:

sudo grep -Ei \
  'multipart/form-data| 500 | 502 | 503 ' \
  /var/log/nginx/access.log | tail -n 100

Pola tersebut hanya petunjuk awal, bukan bukti eksploitasi. Permintaan multipart dan error HTTP juga dapat muncul akibat aktivitas pengguna yang sah.

Periksa pula log PHP-FPM jika tersedia. Lonjakan error memori atau worker yang berhenti secara abnormal dapat membantu menyusun kronologi insiden.

2. Periksa proses anak yang mencurigakan

Proses PHP atau web server yang tiba-tiba menjalankan shell atau utilitas sistem perlu diselidiki.

Jalankan:

ps -eo pid,ppid,user,lstart,args --forest |
  grep -Ei 'php-fpm|php-cgi|apache2|httpd|sh -c|bash -c'

Periksa pula koneksi jaringan yang sedang aktif:

sudo ss -tpn

Cari proses yang tidak sesuai fungsi layanan, koneksi keluar yang tidak dikenal, dan aktivitas yang tidak dapat dijelaskan oleh operasi aplikasi normal.

Perlu diingat bahwa proses berumur pendek mungkin tidak terlihat ketika perintah dijalankan. Jika tersedia, gunakan audit proses atau endpoint detection and response (EDR) untuk meningkatkan visibilitas.

3. Periksa berkas website yang berubah

Pada WordPress, periksa berkas PHP yang baru dibuat atau berubah tanpa perubahan deployment yang sah.

Contoh pemeriksaan berkas PHP yang baru dimodifikasi dalam tujuh hari terakhir:

sudo find /var/www -type f \
  -name '*.php' -mtime -7 -ls

Sesuaikan direktori dengan document root yang sebenarnya.

Hasil perintah ini perlu dibandingkan dengan riwayat deployment, pembaruan plugin, dan aktivitas administrator. Berkas yang baru dimodifikasi tidak otomatis berbahaya.

Periksa khususnya:

• Berkas PHP yang tidak dikenal di direktori unggahan.
• Perubahan tidak sah pada wp-config.php.
• Plugin atau tema yang tidak pernah dipasang oleh administrator.
• Berkas inti WordPress yang berbeda dari distribusi resmi.
• Skrip dengan nama menyerupai berkas sistem yang sah, tetapi berada di lokasi tidak lazim.

Hindari menghapus berkas secara massal sebelum bukti dikumpulkan. Jika ada indikasi kompromi, simpan salinan log dan berkas terkait untuk analisis lebih lanjut.

4. Periksa persistensi dan akun baru

Penyerang yang memperoleh akses dapat mencoba mempertahankan akses melalui mekanisme persistensi.

Periksa cron job:

sudo crontab -l
sudo ls -la /etc/cron.d/
sudo ls -la /etc/cron.daily/

Periksa akun dan aktivitas autentikasi:

getent passwd
sudo journalctl --since "7 days ago" |
  grep -Ei 'sudo|session opened|authentication failure'

Tidak semua sistem mencatat kejadian dalam format yang sama. Pada sistem produksi, periksa juga log autentikasi distribusi, histori perubahan akun, unit systemd baru, serta mekanisme persistensi lain yang relevan.

Jika menemukan akun, tugas terjadwal, atau layanan yang tidak dapat dijelaskan, dokumentasikan waktu pembuatan dan pemiliknya sebelum mengambil tindakan.

5. Tentukan apakah insiden membutuhkan isolasi

Jika terdapat bukti kuat bahwa server telah dikompromikan, jangan hanya mengandalkan patch PHP.

Lakukan tindakan berikut sesuai prosedur respons insiden:

1. Batasi konektivitas server dari jaringan publik atau isolasikan dari jaringan internal bila diperlukan.
2. Simpan log, metadata, dan bukti yang relevan.
3. Identifikasi akun, proses, berkas, serta kredensial yang mungkin terdampak.
4. Rotasi kredensial dari perangkat yang bersih, termasuk kredensial database dan rahasia aplikasi yang terpapar.
5. Tentukan apakah pemulihan dari backup bersih atau pembangunan ulang diperlukan.
6. Verifikasi sistem sebelum mengembalikan layanan ke produksi.

Pembangunan ulang dari sumber yang tepercaya sering kali lebih dapat diandalkan daripada sekadar menghapus satu berkas mencurigakan. Pilihan akhirnya bergantung pada cakupan kompromi dan kualitas bukti yang tersedia.

Kesalahan yang Sering Terjadi Saat Mengamankan PHP2Shell

Hanya memperbarui WordPress

Pembaruan WordPress tidak otomatis memperbarui PHP pada server. Administrator harus memeriksa runtime dan paket yang benar-benar melayani website.

Hanya menjalankan php -v

Perintah tersebut memeriksa PHP CLI, bukan memastikan semua worker web telah menggunakan versi yang diperbaiki. Periksa PHP-FPM, Apache mod_php, container, dan semua runtime yang digunakan.

Menganggap firewall sudah cukup

Firewall dapat mengurangi paparan, tetapi tidak menggantikan patch pada runtime yang rentan. Permintaan berbahaya bisa datang melalui port HTTPS yang memang harus dibuka untuk pengunjung.

Mengandalkan konfigurasi sementara

Menonaktifkan fitur tertentu atau membatasi ukuran permintaan dapat mengurangi risiko pada jalur serangan tertentu, tetapi tidak menjamin seluruh kerentanan tertutup.

Mengabaikan versi PHP yang sudah EOL

PHP yang telah berakhir masa dukungannya membutuhkan perhatian khusus. Jangan berasumsi bahwa semua versi lama akan memperoleh pembaruan keamanan resmi.

Menganggap patch berarti server bersih

Pembaruan memperbaiki kode yang rentan, tetapi tidak menghapus kemungkinan malware atau mekanisme persistensi yang sudah dipasang sebelumnya.

Mengunduh exploit dari sumber tidak tepercaya

Kode PoC yang beredar dapat tidak berfungsi, dimodifikasi, atau mengandung malware. Gunakan advisori resmi, alat pemindaian tepercaya, dan lingkungan pengujian yang terisolasi.

Tips Profesional untuk Administrator Server

Untuk pengelolaan jangka panjang, bangun prosedur patch management yang dapat diulang, bukan sekadar melakukan pembaruan ketika sebuah kerentanan menjadi viral.

Inventarisasi runtime. Catat versi PHP, sumber paket, lokasi konfigurasi, layanan terkait, pemilik aplikasi, dan jadwal pembaruan.

Prioritaskan aset berdasarkan paparan. Server PHP yang dapat diakses dari internet dan memproses data sensitif harus mendapatkan prioritas tinggi.

Gunakan prinsip least privilege. Jalankan setiap aplikasi dengan hak akses minimum. Pisahkan akun layanan, izin berkas, kredensial, dan akses jaringan sesuai kebutuhan.

Pisahkan lingkungan aplikasi. Gunakan container atau isolasi layanan jika sesuai arsitektur. Isolasi bukan pengganti patch, tetapi dapat membatasi dampak insiden.

Otomatiskan pemantauan. Integrasikan log web server, PHP-FPM, audit proses, dan peringatan perubahan berkas ke sistem monitoring yang tersedia.

Uji backup dan pemulihan. Backup harus dapat dipulihkan dan tidak mudah diakses oleh akun aplikasi yang berpotensi dikompromikan.

Buat checklist patch darurat. Tetapkan pihak yang bertanggung jawab, tenggat pembaruan, proses pengujian, prosedur rollback, dan kriteria verifikasi keamanan.

Dokumentasikan bukti penyelesaian. Simpan versi paket, sumber advisori, waktu restart, hasil pemeriksaan layanan, serta temuan threat hunting. Dokumentasi membantu audit dan mencegah pekerjaan berulang.

Kesimpulan

PHP2Shell menunjukkan bahwa keamanan aplikasi web tidak dapat dipisahkan dari keamanan runtime dan infrastruktur yang menjalankannya.

Dua kerentanan, CVE-2026-109618 dan CVE-2026-109619, memiliki tingkat keparahan kritis dengan skor CVSS v4.0 sebesar 9,2. PHP telah menyediakan versi perbaikan untuk cabang yang didukung, termasuk 8.2.35, 8.3.36, 8.4.27, dan 8.5.12.

Langkah utama yang perlu dilakukan administrator adalah:

1. Menginventarisasi seluruh instalasi PHP.
2. Memverifikasi ketersediaan patch dari sumber paket yang tepercaya.
3. Memperbarui PHP dan memuat ulang runtime yang relevan.
4. Memvalidasi versi, status layanan, dan fungsi aplikasi.
5. Memeriksa log, proses, berkas, dan kemungkinan persistensi.
6. Mengisolasi dan menangani server yang menunjukkan bukti kompromi.

Jangan menunggu website menunjukkan gejala kerusakan untuk mulai melakukan mitigasi. Dalam keamanan server, tidak adanya error bukan bukti bahwa sistem aman.

Frequently Asked Questions (FAQ)

Pertanyaan: Apa itu PHP2Shell?

Jawaban: PHP2Shell adalah sebutan untuk dua kerentanan kritis pada runtime PHP yang berpotensi memungkinkan remote code execution tanpa autentikasi.

Pertanyaan: Apa saja CVE yang terkait dengan PHP2Shell?

Jawaban: Dua kerentanan tersebut adalah CVE-2026-109618 dan CVE-2026-109619, masing-masing memiliki skor CVSS v4.0 sebesar 9,2.

Pertanyaan: Versi PHP berapa yang sudah diperbaiki?

Jawaban: Versi upstream yang telah diperbaiki adalah PHP 8.2.35, 8.3.36, 8.4.27, dan 8.5.12. Untuk paket distribusi Linux, periksa advisori dan changelog vendor.

Pertanyaan: Apakah WordPress juga berisiko terkena PHP2Shell?

Jawaban: Ya. WordPress dapat terdampak apabila runtime PHP yang menjalankannya rentan, terlepas dari apakah WordPress core dan pluginnya sudah diperbarui.

Pertanyaan: Apakah memperbarui plugin WordPress dapat mengatasi PHP2Shell?

Jawaban: Tidak. Pembaruan plugin tidak memperbaiki runtime PHP. Administrator harus memperbarui PHP melalui mekanisme yang sesuai dengan sistemnya.

Pertanyaan: Apakah menonaktifkan session.upload_progress.enabled sudah cukup?

Jawaban: Tidak. Pengaturan tersebut hanya dapat mengurangi paparan pada jalur serangan tertentu dan bukan pengganti pembaruan PHP.

Pertanyaan: Bagaimana cara memeriksa versi PHP pada Ubuntu Server?

Jawaban: Jalankan php -v untuk memeriksa PHP CLI, kemudian periksa paket terpasang, layanan PHP-FPM, dan runtime yang digunakan web server.

Pertanyaan: Apakah restart server diperlukan setelah patch?

Jawaban: Tidak selalu seluruh server harus direstart. Namun, layanan atau worker PHP yang relevan harus dimuat ulang atau direstart sesuai petunjuk vendor agar menggunakan kode yang telah diperbaiki.

Pertanyaan: Bagaimana cara mengetahui apakah server sudah dieksploitasi?

Jawaban: Periksa log HTTP dan PHP, proses anak yang mencurigakan, perubahan berkas, akun baru, cron job, dan koneksi jaringan. Tidak ada satu indikator yang dapat memastikan atau menyingkirkan kompromi secara mutlak.

Pertanyaan: Apa yang harus dilakukan jika server diduga telah dikompromikan?

Jawaban: Isolasi server sesuai kebutuhan, amankan bukti, lakukan investigasi, rotasi kredensial yang terpapar, dan pulihkan sistem dari sumber tepercaya jika diperlukan.

Server PHP Anda sudah menggunakan versi yang aman dari PHP2Shell?

Dua kerentanan kritis CVE-2026-109618 dan CVE-2026-109619 menjadi pengingat bahwa keamanan website tidak cukup hanya dengan memperbarui CMS dan plugin. Runtime PHP, layanan web, container, dan konfigurasi server juga harus diperiksa.

Bagikan pengalaman Anda di kolom komentar:

• Apakah Anda sudah melakukan patch PHP pada server produksi?
• Apakah Anda menggunakan Ubuntu Server, Debian, Docker, atau VPS hosting?
• Bagaimana strategi Anda memverifikasi keamanan setelah pembaruan?

Silakan bagikan artikel ini kepada administrator server, developer web, sysadmin, dan pengelola website yang perlu mengetahui ancaman PHP2Shell.

Jangan lupa membaca artikel teknologi lainnya untuk mendapatkan panduan Linux, networking, DevOps, server hardening, dan cybersecurity terbaru.

Keamanan server bukan pekerjaan sekali selesai. Lakukan pembaruan, verifikasi, dan monitoring secara berkelanjutan.