Kalau server Anda menjalankan PHP, minggu ini adalah minggu yang tidak boleh dilewatkan. Pada 21 Oktober 2026, tim PHP merilis PHP 8.5.12, 8.4.27, 8.3.36, dan 8.2.35 untuk menambal dua kerentanan kritis yang memungkinkan penyerang menjalankan kode dari jarak jauh tanpa autentikasi (unauthenticated remote code execution). Keduanya kini dikenal sebagai PHP2Shell dan tercatat sebagai CVE-2026-109618 serta CVE-2026-109619.

Yang membuat kasus ini serius bukan hanya skornya, tetapi lokasinya: kedua celah berada di inti mesin PHP, yaitu manajemen memori dan penanganan error, bagian yang disentuh hampir setiap request. Aplikasi Anda bisa ditulis sebersih apa pun dan tetap terdampak selama versi PHP-nya belum ditambal. Docker mencatat PHP dipakai sekitar 69% situs web yang bahasa sisi servernya diketahui, dan angka itu menjelaskan mengapa peringatan ini bergema cepat di seluruh industri.

Apa sebenarnya yang bocor?

Kedua kerentanan punya akar masalah berbeda, tetapi sama-sama berujung pada eksekusi kode:

• CVE-2026-109618, RCE lewat korupsi saat kehabisan memori (OOM). Jika sebuah request menyentuh memory_limit tepat di momen yang salah, PHP bisa meninggalkan data internal yang baru terinisialisasi sebagian, lalu proses pembersihan request memperlakukan data tidak valid itu sebagai valid dan memori pun rusak. Pada Apache dengan mod_php, request tanpa autentikasi dapat memicu ini sebelum kode aplikasi berjalan; eksekusi kode jarak jauh sudah didemonstrasikan dengan konfigurasi default. Pada PHP-FPM, RCE juga terkonfirmasi lewat jalur kode di level aplikasi.
• CVE-2026-109619, RCE lewat state global yang basi. Fatal error pada titik yang salah bisa membuat state internal PHP masih menunjuk ke memori milik request sebelumnya. Request berikutnya yang ditangani worker yang sama lalu memakai memori yang sudah dibebaskan (use-after-free). Peneliti mengonfirmasi crash worker, dan mendemonstrasikan eksekusi kode pada aplikasi nyata yang berjalan di Apache dengan mod_php.

Menurut advisory resmi php.net, risiko tertinggi ada pada mod_php, tetapi semua instalasi yang melayani request web terdampak: PHP-FPM, php-cgi, FrankenPHP, hingga LiteSpeed. Versi rentan mencakup 8.2 sampai 8.5, juga versi end-of-life seperti 5.x, 7.x, 8.0, dan 8.1, sementara Docker menyebut paket PHP terdampak sejak versi 5.4.

Cek dan tambal sekarang, bukan besok

Langkah pertama selalu inventaris. Jalankan perintah berikut di tiap server, lalu cocokkan hasilnya dengan daftar versi aman:

php -v
# target aman: 8.5.12, 8.4.27, 8.3.36, atau 8.2.35

# Debian/Ubuntu: cek paket yang tersedia
apt list --upgradable 2>/dev/null | grep -i php

# Container: image resmi sudah diperbarui, rebuild — jangan hanya restart
docker pull php:8.3-fpm
docker compose up -d --build

Ada beberapa catatan praktis yang sering terlewat saat penambalan darurat seperti ini:

1. Update runtime, bukan hanya aplikasi. composer update tidak akan menolong karena yang perlu diganti adalah paket PHP di sistem operasi atau base image container.
2. PHP 8.1 ke bawah tidak lagi mendapat rilis dari proyek PHP. Distribusi dan vendor LTS menerima patch lebih awal, jadi periksa repositori vendor Anda; untuk yang membangun dari source, tim keamanan PHP menyediakan backport minimal untuk 7.4, 8.0, dan 8.1.
3. Container yang sedang berjalan tidak ikut berubah hanya karena image di Docker Hub sudah diperbarui, sehingga rebuild dan redeploy tetap wajib dilakukan.
4. Restart semua worker. PHP-FPM lama yang masih hidup tetap menyimpan state rentan, jadi pastikan proses benar-benar diganti dan bukan sekadar reload konfigurasi.

Kalau belum bisa update hari ini

Perlu ditegaskan bahwa hanya update yang menutup celah sepenuhnya. Langkah berikut mengurangi paparan pada jalur serangan tertentu dan harus dipasang lewat konfigurasi yang tidak bisa ditimpa aplikasi.

Untuk CVE-2026-109618, set memory_limit=-1 melalui php_admin_value di pool FPM atau konfigurasi Apache, lalu pastikan tidak ada pool, direktori, atau aplikasi yang memasang batas kembali. Turunkan juga post_max_size (8M bila tanpa upload, 32M bila perlu upload) dan batasi ukuran request di level web server atau proxy. Untuk CVE-2026-109619, set session.upload_progress.enabled=0 dan, khusus PHP 8.5, fatal_error_backtraces=0; keduanya lewat php.ini atau konfigurasi pool, bukan ini_set().

Contoh penerapan di pool FPM terlihat seperti ini:

; /etc/php/8.3/fpm/pool.d/www.conf
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M
php_admin_value[session.upload_progress.enabled] = 0

Hindari pula memakai RLIMIT_AS atau RLIMIT_DATA sebagai pengganti karena menurut advisory keduanya justru bisa memicu kegagalan alokasi yang menjadi pintu masuk kerentanan OOM.

Pelajaran yang lebih besar

Kronologi di balik PHP2Shell layak dibaca tim engineering. Kerentanan OOM ini sebenarnya sudah muncul sebagai kecurigaan sejak audit eksternal PHP pada 2024, yang dijalankan Quarkslab lewat OSTIF dengan dana Sovereign Tech Agency, tetapi perbaikannya tertahan lama karena trade-off kompatibilitas dan keterbatasan sumber daya. Baru setelah 11 Agustus 2026 peneliti Ryan A dari Calif melaporkan RCE dengan akar masalah yang sama, disusul laporan independen dari OpenAI dan Wiz, prioritasnya berubah total.

Ada dua hal yang bisa kita ambil dari kasus ini. Pertama, runtime adalah dependency paling dalam: ia tidak terlihat di composer.json, tidak muncul di review kode, tetapi berada di bawah semua yang kita bangun. Inventaris versi PHP di seluruh server dan aturan patch maksimal 24 sampai 48 jam untuk celah kritis jauh lebih murah daripada menanggung insiden. Kedua, WAF bukan tambalan: ketika celahnya berada di mesin bahasa sebelum kode aplikasi dieksekusi, tidak ada aturan aplikasi yang bisa menyelamatkannya.

Cek versi PHP Anda hari ini. Kalau masih di bawah angka di atas, jadwalkan update sekarang, dan bila layanan yang berjalan bersifat publik, anggap ini sebagai prioritas tertinggi.

Sumber: php.net, Security advisory: Critical remote code execution vulnerabilities, The PHP Foundation, Today's PHP Security Release, Docker, Security Update on PHP2Shell.