Update keamanan PHP: tambal php2shell sebelum rilis bugfix berikutnya

Apakah website PHP-mu aman hari ini? Pada 21 Oktober 2026 tim PHP merilis update keamanan PHP: versi 8.5.12, 8.4.27, 8.3.36 dan 8.2.35 menutup dua celah kritis yang bisa memungkinkan eksekusi kode jarak jauh (RCE) tanpa login. Kalau website, toko online, atau sistem internalmu berjalan di PHP, segera update dan matikan satu pengaturan tambahan sampai rilis bugfix PHP berikutnya.

Artikel ini merangkum apa yang terjadi, versi mana yang aman, langkah yang perlu diambil minggu ini, dan cara memastikan servermu benar-benar sudah ditambal.

Apa yang terjadi: php2shell secara singkat

Dua celah ini dikenal dengan nama php2shell. Menurut Cloudflare, celah ini diungkap pada 21 Oktober 2026 oleh Calif.io, Wiz, OpenAI, dan Quarkslab. Di hari yang sama tim PHP menerbitkan security advisory dan sangat menganjurkan semua pengguna PHP untuk segera update.

• CVE-2026-109618 (GHSA-w8hw-w9fx-j79w), RCE lewat kerusakan saat OOM. Penanganan kehabisan memori (out of memory) bisa menghentikan PHP ketika data request internal baru terisi sebagian.
• CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp), RCE lewat state global yang basi. State internal milik sebuah request bisa tetap tersisa setelah memori yang menampungnya sudah dibebaskan.

Bahasa sederhananya: dalam kondisi tertentu, orang lain bisa menjalankan kodenya sendiri di servermu tanpa perlu login. Karena itu kedua celah ini dinilai kritis.

Versi PHP mana yang aman?

Kalau kamu memakai PHP 8.2 ke atas, cukup update biasa ke versi di tabel. Untuk cabang lama PHP 7.4, 8.0, dan 8.1, tim keamanan PHP menyediakan backport source minimal, bukan rilis baru. Ini membantu tim yang meng-compile PHP sendiri. Untuk kebanyakan bisnis, kami sarankan sekalian merencanakan pindah ke cabang yang lebih baru.

Advisory lanjutan pada 23 Oktober

Dua hari kemudian PHP menerbitkan informational advisory soal session upload progress. PHP menyarankan session.upload_progress.enabled=0 sampai rilis bugfix reguler berikutnya, supaya terlindungi penuh dari satu jalur RCE yang kecil kemungkinannya. Advisory lengkap untuk CVE-2026-115560 akan terbit bersama rilis itu.

Cloudflare mencatat celah ini juga mengenai rilis yang sudah ditambal penuh, termasuk 8.5.12. Jadi update saja belum selesai bulan ini: biarkan upload progress tetap mati sampai rilis PHP berikutnya keluar.

Langkah update keamanan PHP sebelum rilis bugfix berikutnya

1. 1Cek versi PHP yang sebenarnya di setiap server. Paket distro seperti Debian, Ubuntu, RHEL, atau Alpine sering memasukkan perbaikan (backport) tanpa mengubah nomor versi upstream, jadi php -v saja tidak cukup. Cek changelog paketnya untuk CVE-2026-109618 dan CVE-2026-109619.
2. 2Uji update di staging. Naikkan ke 8.5.12, 8.4.27, 8.3.36 atau 8.2.35, atau paket distro yang sudah ditambal, lalu coba alur checkout, login, dan formulir.
3. 3Update production, termasuk semua server, container, dan worker yang menjalankan PHP.
4. 4Set session.upload_progress.enabled=0 lalu restart semua worker, supaya tidak ada proses lama yang masih memakai pengaturan lama.
5. 5Pantau rilis reguler PHP berikutnya, yang akan memperbaiki CVE-2026-115560, lalu pasang dengan cara yang sama.

Kalau belum bisa update hari ini

PHP mencantumkan mitigasi sementara, tapi menegaskan bahwa mitigasi hanya mengurangi risiko dan tidak membuat instalasi aman. Satu-satunya perbaikan lengkap adalah update.

• Untuk CVE-2026-109618: set memory_limit=-1 dengan cara yang tidak bisa ditimpa aplikasi, misalnya php_admin_value di pool FPM atau konfigurasi Apache.
• Untuk CVE-2026-109619: set session.upload_progress.enabled=0 lalu restart semua worker.

Apakah WAF sudah cukup?

Cloudflare menyebut WAF mereka, di paket gratis maupun berbayar, sudah melindungi secara default sejak 21 Oktober pukul 03.02 UTC. Tapi Cloudflare juga menegaskan pelanggan tetap harus menambal PHP, karena WAF hanya lapisan pertahanan tambahan, bukan pengganti update.

Artinya untuk bisnismu

Banyak website perusahaan, toko online, dan dashboard internal berjalan di PHP lewat WordPress, Laravel, atau kode custom. Framework-nya tidak mengubah jawaban: perbaikannya ada di runtime PHP di server. Kalau server diurus penyedia hosting, tanyakan paket PHP mana yang terpasang dan apakah sudah memuat kedua perbaikan CVE. Kalau timmu sendiri yang mengurus server, ini pekerjaan minggu ini.

Update keamanan jarang datang di waktu yang pas. Pola yang sama kami bahas untuk situs JavaScript di cara update Next.js dengan aman: tim yang paling cepat pulih adalah yang sudah punya staging, backup, dan rutinitas update yang teruji.

Bagaimana Estontinc membantu

Estontinc adalah software house di Malang dengan 100+ proyek dan 50+ klien selama lebih dari enam tahun. Untuk website dan sistem berbasis PHP, kami bisa:

• Mengaudit versi PHP di semua server, container, dan hosting, termasuk changelog paket distro.
• Menambal dengan pengujian, di staging dulu baru production, sebagai bagian dari jasa pembuatan website kami.
• Merawat sistem setelah rilis lewat layanan maintenance: bug fix dan update, monitoring dan backup, serta perbaikan kecil tiap bulan, dengan urusan server ditangani tim cloud dan DevOps kami.

Kami bekerja dengan NDA, source code tetap milikmu, dan komunikasi bisa dalam bahasa Indonesia, Inggris, atau Jepang. Mau setup PHP-mu dicek? Kirim detailnya lewat halaman kontak, kami balas dalam 24 jam.