Pada 21 Oktober 2026 proyek PHP merilis perbaikan darurat untuk dua kerentanan kritis yang dikenal sebagai PHP2Shell: CVE-2026-109618 dan CVE-2026-109619. Keduanya dinilai 9.2 menurut CVSS v4.0. Bagian penting bagi operator bukan hanya angka severity — melainkan di mana bug-nya berada.
Celah ini ada di inti PHP, bukan di plugin WordPress, middleware Laravel, atau kode aplikasi custom. Artinya aplikasi yang bersih tetap bisa terpapar jika runtime di server belum di-patch. Di beberapa setup, terutama Apache dengan mod_php, request yang dirancang khusus bisa memicu masalah sebelum kode aplikasi sempat jalan.
Apa yang sebenarnya dilakukan kerentanan ini
CVE-2026-109618 digambarkan sebagai remote code execution lewat korupsi memori saat kehabisan memori (out-of-memory) selama penanganan dan pembersihan request. Ketika PHP mencapai batas memori di momen yang salah, state internal bisa tertinggal dalam bentuk yang hanya terinisialisasi sebagian. Rutin cleanup kemudian memperlakukan state itu sebagai valid, membuka jalur yang sudah dibuktikan peneliti bisa menjadi eksekusi kode.
CVE-2026-109619 melibatkan state global usang antar request di worker yang sama. Setelah jalur error tertentu, data milik request bisa tetap terjangkau setelah memorinya dibebaskan. Request berikutnya yang ditangani worker yang sama bisa memakai state usang itu sebelum inisialisasi normal meresetnya. Use-after-free ini juga sudah ditunjukkan mendukung remote code execution.
Detail isu bocor pada 20 Oktober, sebelum jendela rilis terkoordinasi. Exploit dan tooling cepat beredar. Beberapa firma keamanan dan jaringan honeypot melaporkan probing serta upaya eksploitasi setelah kebocoran itu. Risikonya bukan teoritis.
Siapa yang terdampak
Setiap instalasi PHP yang melayani request web masuk cakupan: PHP-FPM, Apache dengan mod_php, php-cgi, FrankenPHP, dan LiteSpeed. PHP sendiri menyatakan risiko paling tinggi pada mod_php, di mana request tanpa autentikasi bisa memicu serangan sebelum kode aplikasi jalan.
Karena engine-nya dipakai bersama, stack populer ikut terpapar. WordPress, Drupal, Magento, Joomla, Laravel, Symfony, dan banyak API custom semuanya terdampak selama versi PHP di bawahnya belum di-patch. Autentikasi dan validasi input di tingkat aplikasi tidak sepenuhnya melindungi ketika celah bisa dipicu lebih awal di siklus request.
Versi aman dan yang perlu dilakukan
Rilis resmi yang sudah diperbaiki:
- PHP 8.5.12
- PHP 8.4.27
- PHP 8.3.36
- PHP 8.2.35
PHP 8.1 ke bawah sudah end-of-life. Proyek PHP menerbitkan source backport terbatas untuk 7.4, 8.0, dan 8.1, dan beberapa distribusi Linux serta vendor LTS sudah merilis paket. Jalur yang lebih berkelanjutan tetap pindah ke branch yang didukung dan menjaganya tetap mutakhir.
Perbaikan lengkap adalah meng-update runtime lalu me-restart service terkait (php-fpm, apache, dan seterusnya). Perubahan konfigurasi sementara — misalnya menonaktifkan session.upload_progress — bisa mengurangi sebagian jalur serangan, tapi tidak menggantikan patch. Jangan andalkan terlalu lama.
Kenapa ini penting di dalam data center
Banyak tim menaruh puluhan atau ratusan aplikasi berbasis PHP di infrastruktur bersama. Ketika celah kritis di tingkat engine muncul, kecepatan respons bergantung pada seberapa jelas daya, konektivitas, dan proses operasional sudah dikelola. Fasilitas yang sudah tersertifikasi Tier IV dan berada di lokasi yang dekat dengan pusat internet exchange di Jakarta biasanya lebih mudah menjaga koneksi stabil dan jendela maintenance yang terkoordinasi. Ketika update runtime mendesak dibutuhkan di banyak pelanggan atau sistem internal, data center yang dibangun untuk keandalan dan handoff operasional yang jelas justru mengurangi gesekan.
Operator juga diuntungkan jika jelas siapa yang bertanggung jawab atas lapisan OS dan runtime versus lapisan aplikasi. Lingkungan colocation dan managed dengan proses perubahan yang terdokumentasi biasanya meroll patch platform kritis lebih cepat dibanding ruang server ad-hoc. Opsi disaster recovery di kota berbeda tetap berguna jika insiden regional bertepatan dengan jendela eksploitasi massal — tapi prioritas pertama tetap mem-patch runtime yang sedang live hari ini.
Checklist praktis untuk tim
Daftar operasional singkat membantu menjaga respons tetap fokus:
- Inventarisasi setiap host yang menjalankan PHP untuk traffic web (termasuk container dan node shared hosting).
- Pastikan versi pastinya dengan
php -vatau setara di lingkunganmu. - Update ke 8.5.12, 8.4.27, 8.3.36, atau 8.2.35 (atau paket vendor yang memuat perbaikan yang sama).
- Restart worker dan verifikasi bahwa versi baru benar-benar melayani request.
- Tinjau endpoint yang menghadap internet dan log untuk traffic multipart atau session yang tidak biasa di sekitar jendela disclosure.
- Jika kamu tidak mengontrol runtime sendiri, minta konfirmasi ke host atau penyedia colocation bahwa PHP di platform sudah di-update.
PHP2Shell adalah isu di tingkat fondasi. Penguatan aplikasi membantu, tapi tidak bisa sepenuhnya menutup lubang yang bisa dijangkau sebelum kode aplikasi jalan. Respons praktisnya sama untuk tim kecil maupun fasilitas besar: update runtime, restart, dan verifikasi. Semakin cepat itu dilakukan, semakin kecil jendela untuk serangan oportunistik.
