PHP2Shell: Dua Celah Kritis PHP dan Versi yang Aman

Tim keamanan PHP merilis PHP 8.5.12, 8.4.27, 8.3.36, dan 8.2.35 pada 21 Oktober 2026 untuk menutup dua celah kritis yang dijuluki PHP2Shell. Keduanya, CVE-2026-109618 dan CVE-2026-109619, berskor CVSS v4.0 9.2 dan dapat memicu eksekusi kode dari jarak jauh tanpa akun. Server web berbasis PHP perlu diperiksa sekarang.

Apa yang diumumkan tim PHP

Pada 20 Oktober 2026, tim keamanan PHP lebih dulu mengumumkan bahwa rilis keamanan dengan dua celah kritis dijadwalkan pada 21 Oktober pukul 14.00 UTC. Mereka juga menyatakan berhak merilis lebih awal bila rincian celah bocor atau muncul bukti eksploitasi. Menurut SecurityWeek, rincian awal memang sudah beredar di publik sebelum pengumuman resmi.

Dalam pengumuman resmi di php.net, tim PHP menyebut semua instalasi PHP yang melayani permintaan web berisiko, termasuk PHP-FPM, Apache dengan mod_php, php-cgi, FrankenPHP, dan LiteSpeed. Risiko dinilai paling tinggi pada mod_php, karena sudah ada eksploitasi terdemonstrasi yang dapat dipicu oleh satu permintaan tanpa autentikasi sebelum kode aplikasi dijalankan.

Artinya, kualitas kode aplikasi tidak menolong. Celahnya berada di mesin PHP itu sendiri, sehingga situs WordPress, aplikasi Laravel, dan sistem buatan sendiri sama-sama terpapar selama versi PHP di servernya belum diperbarui.

Cara kerja kedua celah

CVE-2026-109618 berkaitan dengan penanganan kehabisan memori. Menurut advisori GitHub, PHP memakai fungsi longjmp() untuk keluar dari permintaan ketika memori habis. Pada konteks tertentu, data permintaan belum selesai diinisialisasi saat itu terjadi, sehingga proses pembersihan di akhir permintaan membaca data yang tidak valid. Penyerang dapat memancing kehabisan memori lewat pemrosesan unggahan multipart, misalnya dengan bagian bersarang atau tajuk yang tidak dibatasi.

CVE-2026-109619 berkaitan dengan keadaan global yang basi. Status internal milik satu permintaan dapat bertahan setelah memorinya dibebaskan, lalu dipakai permintaan berikutnya yang ditangani oleh proses pekerja (worker) yang sama.

Tim PHP menegaskan bahwa tidak ada mitigasi yang lengkap. Pengaturan konfigurasi hanya mengurangi jalur serangan tertentu, sedangkan pembaruan adalah satu-satunya jalan yang aman.

Versi yang terdampak dan versi perbaikan

Berdasarkan buletin keamanan AWS 2026-143 dan advisori PHP, cabang yang masih didukung punya perbaikan, sedangkan cabang lama tidak.

PHP 8.1 dan yang lebih lama tidak lagi menerima pembaruan dari proyek PHP. Sebagian distribusi Linux dan penyedia dukungan jangka panjang menyediakan perbaikan versi lama, jadi periksa paket vendor Anda. Untuk yang membangun dari kode sumber, tim PHP menyediakan backport minimal untuk PHP 7.4, 8.0, dan 8.1. AWS mencatat bahwa untuk CVE-2026-109618 tidak ada perbaikan di cabang yang sudah habis masa dukungannya, sehingga migrasi ke cabang yang didukung tetap menjadi tujuan akhir. PHP 8.2 sendiri akan mencapai akhir masa dukungan pada 31 Desember 2026.

Status eksploitasi: sumber belum seragam

Pada tahap awal, laporan tentang skala serangan berbeda-beda. Firma keamanan watchTowr menyatakan jaringan umpan (honeypot) miliknya mengamati eksploitasi kedua celah pada 21 Oktober 2026. Pembaruan SecurityWeek mencatat bahwa setelah pembaruan terbit, beberapa perusahaan melaporkan percobaan eksploitasi. Sebelum rilis, Huntress menyatakan belum melihat eksploitasi di lingkungan pelanggannya.

Karena gambaran ini masih berubah, jangan menunggu kepastian skala serangan sebelum bertindak. Server yang menghadap internet sebaiknya diperlakukan seolah sudah menjadi sasaran.

AWS menyatakan layanan AWS sendiri tidak terdampak, tetapi pelanggan yang menjalankan PHP versi rentan di layanan seperti Elastic Beanstalk, Lambda (lewat runtime kustom atau kontainer), Amazon Linux, dan Lightsail tetap harus bertindak. Menurut buletin itu, pengguna AWS WAF dengan grup aturan PHP versi bawaan terlindungi otomatis selama masa pembaruan.

Apa artinya bagi tim IT dan pengelola situs

Sekolah, dinas, toko daring, dan perusahaan di Indonesia banyak menjalankan situs PHP di hosting atau server sendiri. Pekerjaan pertama adalah mengetahui versi PHP yang benar-benar melayani situs, karena banyak server menyimpan beberapa versi sekaligus. Pengelola situs di hosting bersama tidak memegang server, tetapi tetap dapat bertanya kepada penyedia: apakah PHP sudah diperbarui ke versi aman, kapan jadwalnya, dan apakah ada versi PHP lain yang masih aktif untuk akun mereka. Simpan jawabannya sebagai catatan, karena akan berguna bila ada pemeriksaan keamanan setelah ini.

Beberapa catatan untuk langkah-langkah itu:

1. Jangan hanya memercayai php -v. Perintah itu menunjukkan versi program baris perintah, yang dapat berbeda dari versi PHP-FPM atau Apache yang melayani web. Periksa dengan php-fpm8.4 -v (sesuaikan nomor versinya) atau lewat halaman phpinfo(). Di Debian atau Ubuntu, Aikido menyarankan apt changelog php8.3-cli | grep -E "CVE-2026-109618|CVE-2026-109619" untuk memastikan paket sudah memuat perbaikan.
2. Perbarui lewat paket distribusi atau penyedia Anda. Paket baru dapat tiba beberapa jam setelah rilis resmi, jadi ulangi bila belum tersedia.
3. Mulai ulang proses yang berjalan lama. Pekerja antrean, Laravel Horizon, Octane, dan proses latar lain masih memakai PHP lama sampai dimulai ulang.
4. Awasi tanda kompromi. watchTowr menyebut indikator berupa permintaan multipart yang sangat besar atau bersarang dalam, proses PHP yang macet karena memori, berkas baru di direktori web, dan koneksi keluar yang tidak dikenal.

Pengguna Laravel Forge perlu memperhatikan satu hal: menurut dokumentasi Forge, pembaruan keamanan otomatis tidak menambal PHP karena PHP dipasang dari repositori paket terpisah. Pembaruan harus dilakukan sendiri di setiap server, termasuk untuk versi PHP yang tidak sedang dipakai situs.

Bila pembaruan belum dapat dipasang hari ini, tim PHP mencantumkan langkah pengurang risiko, misalnya memory_limit=-1 yang dikunci lewat php_admin_value, post_max_size yang rendah, dan session.upload_progress.enabled=0. Semuanya hanya penahan sementara. Pada 23 Oktober, PHP menambahkan saran informasi agar session.upload_progress.enabled=0 dipertahankan sampai rilis perbaikan berikutnya, terkait jalur serangan yang dinilai kecil kemungkinannya dan akan memiliki advisori sendiri (CVE-2026-115560). Pembatasan akses internet untuk server yang belum dapat diperbarui juga masuk akal.

Mengelola banyak server PHP memang menuntut disiplin. Tim yang belum punya prosedur pembaruan rutin dapat memulai dari inventaris sistem yang menghadap internet, dibantu layanan keamanan siber atau penataan ulang aplikasi lewat pengembangan aplikasi web. Kasus serupa pernah kami bahas pada celah kritis GitLab berskor 10.

Pertanyaan yang sering muncul

Apakah situs WordPress atau Laravel saya terdampak?

Ya, bila PHP di server Anda berada di bawah 8.5.12, 8.4.27, 8.3.36, atau 8.2.35. Celahnya ada di mesin PHP, bukan di WordPress atau Laravel, jadi pembaruan aplikasi tidak menggantikan pembaruan PHP.

Server saya memakai PHP 7 atau 8.1. Apa yang harus dilakukan?

Proyek PHP tidak merilis perbaikan untuk versi tersebut. Hubungi penyedia hosting atau distribusi Linux Anda untuk paket hasil backport, atau pindah ke cabang yang didukung. Selama menunggu, batasi akses server dari internet bila memungkinkan.

Apakah pengaturan konfigurasi cukup sebagai pengganti pembaruan?

Tidak. Tim PHP menyatakan pengaturan hanya mengurangi jalur serangan tertentu dan tidak membuat instalasi aman. Pembaruan tetap satu-satunya solusi lengkap.

Penutup

PHP2Shell menyentuh bagian paling dasar dari banyak situs di Indonesia. Waktu terbaik untuk memeriksa versi PHP adalah hari ini, selagi daftar server masih mudah dikumpulkan. Bila tim Anda membutuhkan teman berdiskusi soal inventaris dan prosedur pembaruan, Merakit siap membantu.

Sumber

• PHP.net, pengumuman keamanan dan rilis 21 Oktober 2026, serta saran informasi 23 Oktober 2026
• GitHub php-src, advisori GHSA-w8hw-w9fx-j79w (CVE-2026-109618), 21 Oktober 2026
• AWS, buletin keamanan 2026-143-AWS, 21 Oktober 2026 (diperbarui 22 Oktober)
• Laravel Forge, advisori keamanan PHP, Oktober 2026
• SecurityWeek, PHP2Shell: Mass Exploitation Looms for Leaked Critical PHP Flaws, 21 Oktober 2026 (diperbarui 22 Oktober)
• watchTowr, PHP2Shell RCE Exploited, Oktober 2026
• Aikido Security, PHP2Shell: affected versions and fixes, 21 Oktober 2026 (diperbarui 23 Oktober)