Security

PHP2Shell: 2 CVE Kritis PHP dengan CVSS 9.2, Ancaman RCE pada Server Web dan WordPress

Oktober 23, 2026 · 20 menit baca · Walid Umar

PHP2Shell menjadi peringatan serius bagi administrator server, sysadmin, pengelola WordPress, developer Laravel, dan tim keamanan infrastruktur IT. Dua kerentanan pada inti PHP, yaitu CVE-2026-109618 dan CVE-2026-109619, dilaporkan memiliki tingkat keparahan Critical dengan skor CVSS v4.0 sebesar 9,2.

PHP merilis pembaruan keamanan untuk menangani kedua kerentanan tersebut pada 21 Oktober 2026. Risiko utamanya adalah kemungkinan eksekusi kode jarak jauh atau Remote Code Execution (RCE) tanpa autentikasi pada lingkungan yang rentan. Artinya, penyerang berpotensi menjalankan kode berbahaya melalui jalur pemrosesan PHP tanpa harus terlebih dahulu mendapatkan akun administrator website.

Hal yang perlu dipahami adalah bahwa kerentanan ini berada pada PHP runtime, bukan semata-mata pada kode aplikasi yang dibangun menggunakan PHP. Karena itu, website yang tidak memiliki plugin rentan, kode khusus yang mencurigakan, atau kesalahan pemrograman tertentu tetap dapat menghadapi risiko jika menggunakan runtime PHP yang belum diperbaiki.

Bagi pengelola VPS, server hosting, WordPress, Laravel, dan aplikasi berbasis PHP lainnya, langkah paling penting adalah mengidentifikasi versi runtime yang digunakan, menerapkan pembaruan keamanan yang sesuai, memastikan seluruh proses PHP telah menggunakan versi yang diperbaiki, dan memeriksa indikasi kompromi.

Catatan: Artikel ini disusun berdasarkan informasi keamanan yang tersedia hingga 23 Oktober 2026. Detail teknis dan status versi harus selalu dicocokkan dengan advisory resmi PHP sebelum tindakan produksi dilakukan.

Apa Itu PHP2Shell?

PHP2Shell merupakan sebutan untuk dua kerentanan keamanan kritis pada PHP Core yang berkaitan dengan penanganan kondisi error dan pengelolaan memori internal. Keduanya memiliki identitas CVE yang berbeda, tetapi sama-sama berpotensi membuka jalan menuju eksekusi kode jarak jauh.

PHP sendiri merupakan bahasa pemrograman server-side yang digunakan untuk memproses permintaan HTTP, menjalankan logika aplikasi, berinteraksi dengan database, mengelola sesi, dan menghasilkan konten dinamis.

Ketika pengguna membuka website WordPress atau aplikasi Laravel, permintaan biasanya melewati web server dan diteruskan ke runtime PHP. PHP kemudian mengeksekusi kode aplikasi dan mengembalikan hasilnya kepada pengguna.

Jika terdapat kesalahan keamanan pada runtime, masalah tersebut dapat memengaruhi aplikasi yang berjalan di atasnya. Kondisi ini berbeda dari bug pada sebuah plugin atau modul aplikasi tertentu.

Mengapa kerentanan pada PHP Core berbahaya?

Bayangkan PHP sebagai mesin yang menjalankan berbagai aplikasi di sebuah server. WordPress, Laravel, dan aplikasi PHP lainnya merupakan program yang menggunakan mesin tersebut.

Jika sebuah plugin memiliki bug, dampaknya mungkin terbatas pada jalur fungsi tertentu. Namun, apabila terdapat kerentanan pada mesin runtime, sejumlah aplikasi yang menggunakan runtime tersebut dapat menghadapi risiko secara bersamaan.

Dampak aktual tetap bergantung pada versi PHP, konfigurasi, ekstensi yang aktif, model pemrosesan request, dan jalur eksekusi yang dapat dicapai penyerang.

Dengan demikian, PHP2Shell tidak boleh diperlakukan sebagai masalah yang hanya dapat diselesaikan dengan memperbarui WordPress atau menghapus plugin tertentu. Pembaruan PHP runtime merupakan bagian utama dari mitigasi.

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

Kedua CVE tersebut berkaitan dengan penanganan memori dan kondisi error yang tidak aman. Walaupun dampak akhirnya dapat serupa, mekanisme kerentanan yang mendasarinya berbeda.

CVE-2026-109618: Kerusakan kondisi internal saat kehabisan memori

CVE-2026-109618 berkaitan dengan kondisi out-of-memory atau OOM.

OOM terjadi ketika sebuah proses tidak dapat memperoleh memori yang dibutuhkan untuk melanjutkan operasi. Kondisi ini dapat dipicu oleh berbagai keadaan, termasuk permintaan yang membutuhkan alokasi memori besar atau proses yang mengalami tekanan memori.

PHP menggunakan mekanisme internal untuk keluar dari konteks eksekusi ketika terjadi kondisi tertentu, termasuk kesalahan kehabisan memori. Jika sebagian jalur pemrosesan tidak menangani perpindahan tersebut secara benar, struktur internal dapat tertinggal dalam kondisi yang tidak valid atau belum terinisialisasi.

Masalah kemudian dapat muncul ketika proses pembersihan request menggunakan data yang seharusnya tidak lagi dianggap valid.

Dalam kondisi yang memenuhi persyaratan eksploitasi, perilaku tersebut dapat membuka peluang eksekusi kode berbahaya.

Hal yang perlu ditekankan adalah bahwa tidak setiap kejadian OOM berarti server berhasil dieksploitasi. OOM sendiri merupakan kondisi operasional yang bisa terjadi karena beban tinggi, konfigurasi memori, atau bug aplikasi. Risiko keamanan muncul ketika kondisi tersebut berinteraksi dengan jalur pemrosesan yang rentan.

CVE-2026-109619: Kondisi global state yang sudah tidak valid

CVE-2026-109619 berkaitan dengan global state internal PHP yang dapat tetap merujuk ke memori request setelah memori tersebut dibebaskan.

Dalam pengelolaan memori, sebuah referensi harus menunjuk ke objek atau wilayah memori yang masih valid. Jika memori telah dibebaskan tetapi referensi lama masih digunakan, kondisi tersebut dikenal sebagai stale reference atau dangling pointer. Pada kasus tertentu, masalah ini berkaitan dengan kelas kerentanan use-after-free.

Analogi sederhananya adalah sebuah sistem administrasi yang masih menyimpan alamat ruangan lama setelah ruangan tersebut dibongkar dan dialokasikan ulang. Ketika sistem menggunakan alamat lama itu, informasi yang ditemukan mungkin tidak lagi sesuai dengan objek semula.

Pada PHP, kondisi internal yang tidak dibersihkan dengan benar dapat membuat request berikutnya berinteraksi dengan state yang sudah tidak valid. Bergantung pada jalur pemrosesan dan kondisi runtime, akibatnya dapat mencakup kerusakan memori, pengungkapan informasi, atau eksekusi kode jarak jauh.

Kedua kerentanan tersebut menunjukkan bahwa pengelolaan memori dan penanganan error pada runtime merupakan bagian penting dari keamanan aplikasi web.

Mengapa CVSS 9,2 Termasuk Kategori Critical?

CVSS adalah singkatan dari Common Vulnerability Scoring System, yaitu sistem untuk mengukur karakteristik dan tingkat keparahan kerentanan keamanan.

Kedua kerentanan PHP2Shell dilaporkan memiliki skor CVSS v4.0 sebesar 9,2 dari 10, yang masuk kategori Critical.

Skor tersebut menunjukkan bahwa kerentanan berpotensi menimbulkan dampak besar dan perlu mendapat prioritas penanganan tinggi.

Dalam penilaian ini, faktor yang relevan meliputi kemungkinan serangan melalui jaringan, tidak diperlukannya autentikasi pada jalur serangan yang terdampak, serta potensi dampak terhadap kerahasiaan, integritas, dan ketersediaan sistem.

Tiga aspek keamanan tersebut dikenal sebagai CIA Triad:

Confidentiality: penyerang berpotensi mengakses informasi yang seharusnya tidak tersedia untuknya.
Integrity: penyerang berpotensi mengubah file, konfigurasi, atau data.
Availability: penyerang berpotensi mengganggu layanan sehingga website tidak dapat beroperasi normal.

Skor CVSS bukanlah persentase kemungkinan server diserang. Skor 9,2 tidak berarti terdapat kemungkinan 92% bahwa sebuah server akan diretas. Skor ini digunakan untuk menggambarkan tingkat keparahan berdasarkan karakteristik kerentanan.

Tingkat risiko aktual pada suatu server juga dipengaruhi oleh keterjangkauan layanan dari jaringan, versi runtime, konfigurasi, pembatasan jaringan, serta keberadaan kontrol keamanan tambahan.

Bagaimana RCE Dapat Mengancam Server Web?

Remote Code Execution adalah kondisi ketika penyerang dapat membuat sistem target menjalankan kode yang dipilihnya dari jarak jauh.

Pada aplikasi web, dampak RCE sangat bergantung pada hak akses proses yang menjalankan aplikasi tersebut. Jika PHP berjalan menggunakan akun layanan web dengan hak akses terbatas, penyerang mungkin memperoleh kemampuan sesuai hak akses akun itu. Jika proses memiliki izin terlalu luas, dampaknya dapat menjadi lebih serius.

Berikut beberapa kemungkinan dampak yang perlu dipertimbangkan.

1. Pengambilalihan proses aplikasi

Penyerang dapat berpotensi menjalankan perintah atau kode dalam konteks proses PHP yang terdampak. Hal ini dapat menjadi titik awal untuk melakukan aktivitas lain di dalam lingkungan server.

2. Pencurian informasi sensitif

File konfigurasi aplikasi sering menyimpan informasi penting, seperti kredensial database, secret key, token integrasi, dan konfigurasi layanan eksternal.

Jika proses PHP memiliki akses ke file tersebut, kompromi runtime dapat meningkatkan risiko kebocoran informasi.

3. Perubahan konten website

Penyerang berpotensi mengubah file website, menyisipkan skrip berbahaya, atau memodifikasi halaman yang ditampilkan kepada pengunjung, bergantung pada izin file dan tingkat keberhasilan eksploitasi.

4. Penyalahgunaan server

Server yang telah dikompromikan dapat disalahgunakan untuk menjalankan proses tidak sah, melakukan komunikasi ke sistem lain, atau menjadi titik awal serangan lanjutan.

5. Gangguan layanan

Aktivitas eksploitasi dapat menyebabkan proses PHP gagal, penggunaan sumber daya meningkat, atau layanan mengalami penurunan kinerja.

Namun, dampak tersebut merupakan kemungkinan yang bergantung pada kondisi kompromi. Tidak setiap server yang menggunakan versi rentan pasti telah diserang atau mengalami seluruh dampak di atas.

Dampak PHP2Shell terhadap WordPress

WordPress menggunakan PHP untuk menjalankan core, tema, plugin, dan berbagai fungsi website. Karena itu, keamanan runtime PHP merupakan bagian penting dari keamanan keseluruhan instalasi WordPress.

Website WordPress tanpa plugin rentan tetap berisiko

Menghapus plugin yang tidak digunakan, memperbarui tema, dan menerapkan praktik coding yang aman merupakan langkah yang penting. Akan tetapi, langkah tersebut tidak menggantikan pembaruan PHP Core.

Apabila server menjalankan runtime PHP yang rentan, jalur serangan pada level runtime dapat berada di luar logika bisnis plugin maupun tema.

Dengan kata lain, website yang telah menggunakan plugin resmi dan kode aplikasi yang terawat tetap perlu memeriksa versi PHP yang mendasarinya.

Bagaimana jika WordPress menggunakan shared hosting?

Pada shared hosting, administrator website biasanya tidak memiliki akses untuk memperbarui runtime PHP secara langsung.

Pengguna perlu memeriksa versi PHP yang aktif untuk domainnya melalui panel hosting atau fasilitas diagnostik yang disediakan penyedia layanan. Selanjutnya, hubungi penyedia hosting jika versi yang tersedia belum mencakup perbaikan keamanan.

Jangan hanya mengandalkan versi PHP yang ditampilkan pada halaman utama panel hosting. Satu akun hosting dapat memiliki beberapa domain, konfigurasi PHP, atau versi runtime yang berbeda.

Bagaimana jika WordPress berjalan pada VPS?

Pada VPS, sysadmin perlu memeriksa seluruh jalur eksekusi PHP yang aktif, bukan hanya perintah php -v.

Contohnya, CLI dapat menggunakan PHP 8.3, sedangkan Apache atau PHP-FPM masih menjalankan versi lain. Dalam kondisi tersebut, hasil pemeriksaan CLI saja tidak cukup untuk memastikan website sudah terlindungi.

Administrator juga perlu memeriksa konfigurasi virtual host, pool PHP-FPM, container, serta proses aplikasi yang masih berjalan menggunakan runtime lama.

Dampak PHP2Shell terhadap Laravel dan Aplikasi PHP Lainnya

Laravel menggunakan PHP runtime untuk menjalankan routing, middleware, controller, queue worker, scheduler, dan berbagai komponen aplikasi lainnya.

Framework modern membantu developer menerapkan pola pemrograman yang lebih terstruktur. Namun, framework tidak menghilangkan risiko yang berasal dari kerentanan pada runtime.

Hal serupa berlaku untuk Drupal, Joomla, aplikasi CMS lain, dan aplikasi PHP buatan sendiri.

Beberapa hal yang perlu diperhatikan:

Laravel: periksa versi PHP yang digunakan oleh web server, PHP-FPM, worker queue, dan proses scheduler.
Drupal dan Joomla: periksa runtime PHP serta ekstensi yang digunakan oleh aplikasi.
Aplikasi PHP khusus: identifikasi seluruh server, container, dan lingkungan eksekusi yang menjalankan kode PHP.
Aplikasi berbasis container: periksa image PHP yang digunakan dan buat ulang container setelah image yang telah diperbaiki tersedia.
Worker jangka panjang: pastikan proses lama dimulai ulang setelah runtime diperbarui.

Pembaruan framework saja tidak otomatis memperbaiki PHP runtime. Sebaliknya, pembaruan PHP juga perlu diuji agar kompatibel dengan aplikasi dan ekstensi yang digunakan.

Apakah Semua Server PHP Pasti Rentan?

Tidak tepat menyimpulkan bahwa seluruh server PHP pasti dapat dieksploitasi hanya karena menggunakan PHP.

Penilaian harus dilakukan berdasarkan versi PHP yang terpasang, cabang rilis, paket keamanan yang diterapkan oleh distribusi Linux, konfigurasi runtime, dan model pemrosesan request.

Namun, karena PHP2Shell menyangkut PHP Core dan memiliki jalur serangan yang tidak memerlukan autentikasi pada kondisi tertentu, server yang terekspos ke internet harus diprioritaskan untuk pemeriksaan.

Beberapa faktor yang perlu diperiksa adalah:

Apakah versi PHP termasuk dalam cakupan advisory resmi?
Apakah perbaikan keamanan sudah diterapkan oleh vendor atau distribusi?
Apakah website benar-benar menggunakan runtime yang telah diperbaiki?
Apakah proses PHP yang lama masih berjalan?
Apakah server memiliki indikasi aktivitas mencurigakan?
Apakah kredensial atau data sensitif mungkin telah terpapar?

Status versi harus dikonfirmasi melalui advisory resmi PHP dan dokumentasi keamanan distribusi yang digunakan. Jangan menganggap versi mayor yang lebih baru otomatis aman apabila paketnya belum memperoleh pembaruan yang sesuai.

Versi PHP yang Memperoleh Perbaikan Keamanan

Berdasarkan pengumuman resmi PHP pada 21 Oktober 2026, rilis berikut mencakup perbaikan untuk kedua kerentanan PHP2Shell:

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

Sumber: pengumuman rilis keamanan PHP dan advisory PHP2Shell.

Daftar tersebut mengacu pada rilis resmi yang diumumkan pada tanggal tersebut. Untuk distribusi Linux, paket yang aman dapat menggunakan penomoran versi berbeda karena vendor dapat menerapkan perbaikan keamanan melalui backport. Oleh karena itu, jangan membandingkan nomor versi saja tanpa memeriksa changelog atau advisory distribusi.

Cabang PHP 8.2 dijadwalkan mencapai akhir masa dukungan pada 31 Desember 2026. Administrator yang masih menggunakannya perlu merencanakan migrasi ke cabang yang tetap memperoleh pembaruan keamanan.

Referensi resmi:

Advisory keamanan PHP: https://www.php.net/archive/2026.php
Pengumuman rilis PHP 8.5.12: https://news-web.php.net/php.announce/513
Panduan unduhan PHP: https://www.php.net/downloads

Tutorial: Cara Memeriksa dan Mengamankan Server PHP

Berikut panduan awal bagi administrator Linux dan sysadmin. Contoh menggunakan Debian atau Ubuntu, tetapi nama paket dan prosedur pembaruan dapat berbeda sesuai distribusi.

Langkah 1: Identifikasi versi PHP CLI

Jalankan:

php -v

Perintah ini menampilkan versi PHP yang digunakan oleh command-line interface.

Kemudian periksa lokasi binari:

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

Tujuannya adalah mengetahui binari yang dipanggil ketika perintah PHP dijalankan dari terminal.

Ingat bahwa PHP CLI belum tentu menggunakan runtime yang sama dengan website.

Langkah 2: Identifikasi layanan PHP dan web server

Jalankan:

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

Untuk melihat proses yang berkaitan dengan PHP-FPM:

ps -eo pid,user,comm,args \
  | grep -E '[p]hp-fpm|[a]pache2|[h]ttpd'

Periksa pula container yang menjalankan PHP:

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

Jika menggunakan Kubernetes, periksa image dan konfigurasi workload melalui prosedur operasional cluster yang berlaku.

Jangan menganggap semua server memakai PHP-FPM. Apache dapat menjalankan PHP melalui modul berbeda, sementara beberapa aplikasi menggunakan container atau layanan runtime tersendiri.

Langkah 3: Periksa paket PHP yang terpasang

Pada Debian atau Ubuntu:

dpkg -l 'php*' 2>/dev/null
apt-cache policy php php-cli php-fpm

Periksa juga daftar paket terkait seperti php8.3-fpm, php8.3-cli, dan ekstensi PHP yang terpasang.

Nama paket harus disesuaikan dengan cabang PHP yang benar-benar digunakan. Jika instalasi berasal dari repository pihak ketiga atau image container, ikuti prosedur keamanan dari sumber paket tersebut.

Langkah 4: Periksa advisory resmi

Buka https://www.php.net/archive/2026.php dan cari entri untuk CVE-2026-109618 serta CVE-2026-109619.

Cocokkan informasi berikut:

Cabang PHP yang terdampak.
Versi perbaikan yang sesuai.
Persyaratan pembaruan.
Status dukungan cabang PHP.
Instruksi khusus dari vendor atau distribusi.

Jangan mengandalkan satu hasil pemindaian atau satu nomor versi sebagai satu-satunya bukti bahwa sistem aman.

Langkah 5: Buat backup dan siapkan rencana pemulihan

Sebelum melakukan perubahan pada server produksi, pastikan tersedia backup yang dapat dipulihkan.

Contoh pemeriksaan untuk database MariaDB atau MySQL:

mariadb-dump --all-databases \
  > /root/pre-php-security-update.sql

Perintah tersebut memerlukan akses database yang sesuai. Untuk database besar, gunakan mekanisme backup yang sesuai dengan ukuran, konsistensi, dan kebutuhan pemulihan sistem.

Backup database tidak mencakup seluruh file aplikasi, konfigurasi web server, sertifikat, file upload, atau konfigurasi sistem operasi. Komponen tersebut perlu dicadangkan melalui prosedur terpisah.

Jika menggunakan VPS atau virtualisasi, pertimbangkan snapshot yang konsisten sesuai karakteristik sistem. Snapshot bukan pengganti backup terpisah.

Langkah 6: Terapkan pembaruan keamanan

Pada server yang dikelola melalui repository resmi Debian atau Ubuntu, perbarui metadata paket:

apt update

Lihat paket yang dapat diperbarui:

apt list --upgradable

Lakukan pembaruan paket PHP sesuai kebijakan perubahan sistem dan repository yang digunakan. Jangan langsung menjalankan pembaruan massal pada server produksi tanpa meninjau perubahan, dependensi, dan kebutuhan restart.

Jika memakai image container, gunakan image PHP yang telah memperoleh perbaikan, lalu bangun ulang dan deploy image tersebut melalui pipeline yang berlaku. Memperbarui paket pada host tidak otomatis memperbaiki PHP yang berjalan di dalam container.

Langkah 7: Restart atau reload layanan yang relevan

Setelah pembaruan selesai, restart layanan yang menggunakan runtime baru sesuai hasil pemeriksaan sebelumnya.

Contoh jika layanan yang benar memang menggunakan PHP-FPM 8.3:

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

Nama layanan di atas hanya contoh. Gunakan nama layanan yang benar pada server Anda.

Jika menggunakan Apache dengan modul PHP, container, atau worker aplikasi yang berjalan lama, ikuti prosedur restart yang sesuai. Pastikan tidak ada worker lama yang tetap menjalankan kode runtime sebelum perbaikan.

Langkah 8: Verifikasi runtime yang aktif

Periksa kembali:

php -v

Kemudian verifikasi versi runtime melalui mekanisme diagnostik internal yang aman, konfigurasi PHP-FPM, log layanan, atau fasilitas pengelolaan hosting.

Hindari membuat halaman phpinfo() yang dapat diakses publik. Jika halaman tersebut diperlukan untuk diagnostik, batasi aksesnya dan hapus setelah pemeriksaan selesai.

Uji fungsi aplikasi, koneksi database, upload file, autentikasi, antrean pekerjaan, dan endpoint penting lainnya.

Langkah 9: Periksa indikasi kompromi

Pembaruan memperbaiki kerentanan, tetapi tidak otomatis menghapus kode berbahaya yang mungkin sudah ditanam sebelumnya.

Lakukan pemeriksaan terhadap:

Log akses web server dan error log PHP.
Proses yang tidak dikenal atau tidak sesuai pola operasional.
Perubahan file aplikasi di luar jadwal deployment.
File PHP baru pada direktori upload yang seharusnya tidak mengeksekusi skrip.
Cron job atau service yang tidak dikenal.
Koneksi keluar yang tidak sesuai kebutuhan aplikasi.
Perubahan akun, kredensial, atau konfigurasi keamanan.

Contoh pemeriksaan awal:

ps auxf
systemctl list-timers --all
systemctl list-unit-files --type=service

Tidak ada satu perintah yang dapat memastikan server bersih dari kompromi. Indikasi yang ditemukan perlu dibandingkan dengan baseline normal dan ditindaklanjuti melalui proses incident response.

Jika terdapat bukti kuat kompromi, isolasi sistem sesuai prosedur organisasi, pertahankan bukti, dan pertimbangkan pembangunan ulang dari sumber tepercaya. Jangan langsung menghapus semua file mencurigakan sebelum bukti yang dibutuhkan untuk investigasi diamankan.

Strategi Mitigasi untuk Server Produksi

Tidak semua organisasi dapat memperbarui runtime seketika. Meski demikian, mitigasi sementara tidak boleh dianggap setara dengan perbaikan vendor.

Prioritaskan tindakan berikut:

Inventarisasi semua aset yang menjalankan PHP.
Dahulukan server yang dapat diakses langsung dari internet.
Terapkan pembaruan keamanan sesuai cabang PHP dan vendor.
Batasi akses jaringan yang tidak diperlukan.
Pantau log, proses, dan koneksi yang menyimpang dari baseline.
Siapkan rencana rollback yang aman tanpa kembali menggunakan runtime rentan secara permanen.
Lakukan investigasi jika ada indikasi serangan sebelum mengembalikan server ke layanan normal.

WAF, reverse proxy, pembatasan ukuran request, dan aturan jaringan dapat mengurangi sebagian paparan pada kondisi tertentu. Namun, efektivitasnya bergantung pada jalur serangan dan konfigurasi. Kontrol tersebut tidak boleh diperlakukan sebagai pengganti patch PHP.

Kesalahan yang Sering Terjadi

Menganggap WordPress yang terbaru pasti aman

WordPress dan plugin dapat diperbarui, tetapi PHP runtime pada server mungkin masih rentan.

Solusinya adalah memeriksa keduanya secara terpisah: aplikasi dan lingkungan runtime.

Hanya memeriksa PHP CLI

Hasil php -v tidak selalu menggambarkan versi PHP yang digunakan oleh website.

Solusinya adalah menginventarisasi PHP-FPM, Apache, container, worker, dan runtime aplikasi lainnya.

Menganggap restart otomatis selalu terjadi

Sebagian layanan dapat tetap menggunakan proses lama sampai dilakukan restart atau deployment ulang.

Solusinya adalah memverifikasi proses aktif setelah pembaruan.

Mengandalkan WAF sebagai solusi final

WAF dapat membantu menyaring permintaan tertentu, tetapi tidak menjamin seluruh jalur eksploitasi tertutup.

Solusinya adalah menerapkan patch resmi dan menggunakan WAF sebagai lapisan pertahanan tambahan.

Menganggap tidak ada serangan karena log terlihat normal

Tidak semua serangan menghasilkan indikator yang jelas dalam log standar. Sebagian aktivitas juga dapat terlihat seperti trafik aplikasi biasa.

Solusinya adalah menggabungkan analisis log, integritas file, monitoring proses, telemetri jaringan, dan pemeriksaan konfigurasi.

Mengabaikan container dan worker

Runtime pada container atau worker yang berjalan lama dapat berbeda dari runtime pada host.

Solusinya adalah memetakan setiap lingkungan eksekusi, memperbarui image, melakukan deployment ulang, dan memverifikasi seluruh workload.

Best Practice Keamanan PHP untuk Sysadmin dan Developer

PHP2Shell menjadi pengingat bahwa keamanan aplikasi web tidak hanya ditentukan oleh kualitas kode. Keamanan juga bergantung pada runtime, sistem operasi, dependensi, konfigurasi layanan, dan proses operasional.

Beberapa praktik yang perlu diterapkan secara berkelanjutan:

Gunakan cabang PHP yang masih didukung.
Terapkan pembaruan keamanan melalui proses change management.
Inventarisasi versi PHP pada host, container, dan layanan terkelola.
Pisahkan hak akses akun layanan web dari akun administrator.
Terapkan prinsip least privilege pada file, proses, dan database.
Hindari menyimpan secret dengan izin baca yang terlalu luas.
Pantau perubahan file aplikasi dan konfigurasi sistem.
Sentralisasikan log untuk memudahkan korelasi kejadian.
Gunakan vulnerability scanner yang memahami versi paket dan backport vendor.
Uji pemulihan backup secara berkala.
Siapkan prosedur penanganan insiden sebelum terjadi kompromi.
Jadwalkan pengujian aplikasi setelah pembaruan runtime.

Untuk tim DevOps, pemeriksaan versi dan status dukungan PHP dapat dimasukkan ke pipeline CI/CD. Untuk sysadmin, inventarisasi paket dan monitoring layanan dapat diintegrasikan ke sistem observabilitas. Untuk pengelola hosting, informasi pembaruan runtime harus disampaikan kepada pelanggan secara jelas dan dapat ditindaklanjuti.

Checklist Respons Keamanan PHP2Shell

Gunakan checklist berikut sebagai pemeriksaan awal:

Inventarisasi semua website dan aplikasi PHP.
Identifikasi versi PHP pada host dan container.
Cocokkan versi dengan advisory resmi.
Prioritaskan server yang terekspos ke internet.
Buat backup dan rencana pemulihan.
Terapkan pembaruan keamanan.
Restart atau deploy ulang proses yang terdampak.
Verifikasi versi runtime yang benar-benar aktif.
Uji fungsi aplikasi dan pantau error setelah perubahan.
Periksa indikasi kompromi sebelum menyatakan insiden selesai.
Dokumentasikan perubahan dan hasil verifikasi.

Kesimpulan

PHP2Shell, yang mencakup CVE-2026-109618 dan CVE-2026-109619, menunjukkan bahwa kerentanan pada runtime dapat berdampak luas terhadap aplikasi web yang bergantung padanya.

Dengan skor CVSS v4.0 sebesar 9,2, kedua kerentanan harus mendapat prioritas tinggi dalam pengelolaan keamanan server. WordPress, Laravel, dan aplikasi PHP lainnya tidak otomatis terlindungi hanya karena kode aplikasi atau plugin telah diperbarui.

Langkah yang perlu dilakukan adalah memeriksa runtime yang benar-benar aktif, menerapkan pembaruan keamanan dari sumber tepercaya, memulai ulang proses yang relevan, dan memeriksa indikasi kompromi.

Prinsip utamanya: patch terlebih dahulu, verifikasi setelahnya, dan jangan menyamakan sistem yang sudah diperbarui dengan sistem yang pasti tidak pernah dikompromikan. Keamanan server memerlukan pembaruan, monitoring, kontrol akses, backup, serta respons insiden yang berjalan sebagai satu kesatuan.

Referensi

PHP Security Advisories: https://www.php.net/archive/2026.php
Pengumuman resmi PHP 8.5.12: https://news-web.php.net/php.announce/513
The Hacker News — PHP Issues Emergency Patches for Two Critical PHP2Shell RCE Flaws: https://thehackernews.com/2026/10/php-issues-emergency-patches-for-two.html
Canadian Centre for Cyber Security — PHP2Shell Advisory: https://www.cyber.gc.ca/en/alerts-advisories/al26-026-critical-vulnerabilities-impacting-php-cve-2026-109618-cve-2026-109619

Gunakan advisory resmi PHP sebagai rujukan utama untuk cakupan versi, patch, dan instruksi teknis. Informasi dari sumber sekunder berguna untuk memahami konteks ancaman, tetapi tidak menggantikan dokumentasi vendor.

Frequently Asked Questions (FAQ)

1. Apa itu PHP2Shell?

PHP2Shell adalah sebutan untuk dua kerentanan kritis pada PHP Core, yaitu CVE-2026-109618 dan CVE-2026-109619, yang berpotensi memungkinkan Remote Code Execution pada lingkungan yang rentan.

2. Berapa skor CVSS PHP2Shell?

Kedua kerentanan dilaporkan memiliki skor CVSS v4.0 sebesar 9,2 dari 10 dan masuk kategori Critical.

3. Apakah WordPress terdampak PHP2Shell?

WordPress dapat berisiko jika menggunakan runtime PHP yang rentan. Memperbarui WordPress dan plugin saja tidak menggantikan kebutuhan memperbarui PHP.

4. Apakah Laravel juga berisiko?

Ya, aplikasi Laravel dapat berisiko jika dijalankan menggunakan runtime PHP yang terdampak. Periksa PHP pada web server, PHP-FPM, container, dan worker aplikasi.

5. Apa perbedaan CVE-2026-109618 dan CVE-2026-109619?

CVE-2026-109618 berkaitan dengan kerusakan kondisi internal saat terjadi out-of-memory. CVE-2026-109619 berkaitan dengan global state yang dapat merujuk ke memori request yang sudah dibebaskan.

6. Versi PHP berapa yang sudah mendapatkan perbaikan?

Rilis perbaikan yang diumumkan mencakup PHP 8.2.35, 8.3.36, 8.4.27, dan 8.5.12. Periksa advisory resmi dan pembaruan distribusi Linux untuk memastikan paket yang sesuai.

7. Apakah WAF dapat mencegah PHP2Shell?

WAF dapat mengurangi sebagian paparan jika aturan yang digunakan efektif terhadap jalur serangan terkait. Namun, WAF bukan pengganti patch keamanan PHP.

8. Bagaimana cara mengetahui server sudah diperbarui?

Periksa versi PHP CLI, runtime web server, PHP-FPM, container, dan worker yang aktif. Cocokkan hasilnya dengan advisory resmi atau status paket keamanan dari vendor.

9. Apakah restart server wajib setelah patch PHP?

Proses yang menggunakan runtime lama perlu dihentikan atau dimulai ulang sesuai prosedur layanan. Restart seluruh server tidak selalu diperlukan, tetapi restart layanan yang tepat dan verifikasi runtime aktif sangat penting.

10. Apa yang harus dilakukan jika server diduga sudah dieksploitasi?

Isolasi sistem sesuai prosedur insiden, amankan log dan bukti, perbarui PHP, periksa persistensi serta perubahan tidak sah, dan rotasi kredensial yang berpotensi terpapar. Pertimbangkan pembangunan ulang dari sumber tepercaya jika kompromi terkonfirmasi.

11. Apakah server yang sudah di-patch pasti aman?

Tidak. Patch menutup kerentanan yang diperbaiki, tetapi tidak otomatis menghapus malware, akun tidak sah, atau persistensi yang mungkin telah dibuat sebelum pembaruan.

12. Di mana mendapatkan informasi resmi PHP2Shell?

Kunjungi https://www.php.net/archive/2026.php dan cari advisory tanggal 21 Oktober 2026 untuk kedua CVE tersebut.

CTA Penutup

🔐 PHP2Shell menjadi pengingat bahwa keamanan website tidak berhenti pada update WordPress atau framework.

Dua kerentanan kritis pada PHP Core, CVE-2026-109618 dan CVE-2026-109619, menunjukkan pentingnya menjaga runtime, dependensi, dan infrastruktur server tetap terlindungi.

Bagi sysadmin dan developer, sekarang saatnya memeriksa versi PHP yang aktif, memastikan patch keamanan telah diterapkan, dan mengevaluasi log untuk mencari indikasi aktivitas mencurigakan.

💬 Diskusi di kolom komentar:

Apakah server Anda sudah menggunakan versi PHP yang telah diperbaiki?
Bagaimana strategi Anda mengelola patch keamanan pada VPS, shared hosting, atau container?
Monitoring apa yang Anda gunakan untuk mendeteksi indikasi kompromi pada server Linux?

📢 Bagikan artikel ini kepada rekan sysadmin, developer, administrator WordPress, dan tim keamanan IT agar semakin banyak pengelola server memahami risiko PHP2Shell.

📚 Kunjungi artikel teknologi lainnya untuk mempelajari Linux Server, DevOps, Cloud Computing, Networking, dan Cybersecurity.

Ikuti perkembangan konten terbaru untuk mendapatkan panduan teknis, tutorial server, dan informasi keamanan infrastruktur IT.

#PHP2Shell #Cybersecurity #PHP #LinuxServer #Sysadmin #WordPressSecurity #Laravel #DevOps #ServerSecurity #RemoteCodeExecution

Catatan editorial sebelum publikasi: Pastikan tautan advisory PHP, versi perbaikan, dan cakupan CVE diperiksa kembali pada hari artikel diterbitkan. Informasi keamanan yang berubah cepat perlu memiliki tanggal pembaruan agar pembaca dapat membedakan informasi awal dari status mitigasi terbaru.