Pada 21 Oktober 2026 tim PHP merilis PHP 8.5.12, 8.4.27, 8.3.36, dan 8.2.35 untuk menambal dua celah yang memungkinkan eksekusi kode jarak jauh (remote code execution/RCE) tanpa autentikasi. Celah ini dijuluki PHP2Shell dan tercatat sebagai CVE-2026-109618 serta CVE-2026-109619. Bedanya dengan celah plugin CMS yang biasa kita tangani: kali ini lubangnya ada di inti PHP, jadi semua aplikasi PHP ikut terdampak, sebersih apa pun kode aplikasinya.

Dua celah, satu akar masalah: memori request

Keduanya berakar pada cara PHP mengelola memori saat menangani satu request.

• CVE-2026-109618 (RCE lewat korupsi OOM). PHP memakai longjmp() untuk keluar dari kondisi kehabisan memori. Pada beberapa jalur kode, memori request ditinggalkan dalam keadaan belum terinisialisasi, lalu prosedur pembersihan request membaca memori itu. Beberapa strategi OOM terbukti bisa memicu kondisi ini secara konsisten dan berujung pada RCE.
• CVE-2026-109619 (RCE lewat global state basi). Sebagian state global PHP menunjuk sementara ke memori request. State itu bisa tidak ter-reset dengan benar atau terisi ulang setelah di-reset, sehingga masih menunjuk ke memori yang sudah dibebaskan. Request berikutnya yang dilayani worker yang sama bisa memakai state basi tersebut sebelum inisialisasi normal meresetnya.

NVD memberi CVE-2026-109618 skor CVSS 3.1 sebesar 9,8 (kritis) dan CVE-2026-109619 sebesar 8,1; pada CVSS 4.0 keduanya 9,2 dengan tingkat kritis.

Siapa yang terdampak

Semua instalasi PHP yang melayani request web: PHP-FPM, Apache dengan mod_php, php-cgi, FrankenPHP, dan LiteSpeed. Tim PHP menyebut risiko tertinggi ada pada mod_php karena ada demonstrasi exploit di mana request tanpa autentikasi sudah memicu serangan sebelum satu baris pun kode aplikasi berjalan.

Rentang versi yang terdampak sangat lebar, yaitu PHP 5.4 ke atas: versi yang masih didukung (8.2 sampai 8.5) maupun versi yang sudah habis masa dukungannya (5.x, 7.x, 8.0, 8.1). Artinya situs lama yang masih menempel di PHP 7.4 tidak otomatis aman justru karena sudah tidak dirawat.

Cek versi PHP di server Anda

Mulai dari yang paling mudah. Jalankan di server, bukan di komputer lokal:

# versi CLI
php -v

# versi FPM yang benar-benar melayani web
php-fpm8.3 -v    # sesuaikan nomor versi
systemctl list-units --type=service --state=running | grep php

# di dalam container (tag image sering menipu)
docker ps --format '{{.Names}}\t{{.Image}}'
docker exec -it NAMA_CONTAINER php -v

Kalau yang muncul 8.3.35, 8.4.26, atau 8.2.34, server Anda belum dipatch. Target minimal: 8.3.36, 8.4.27, 8.5.12, atau 8.2.35.

Langkah update

1. Backup dulu. Dump database dan salin konfigurasi pool FPM serta php.ini. Update minor biasanya aman, tetapi rollback harus tetap tersedia.
2. Debian/Ubuntu: apt update && apt install --only-upgrade php8.3-fpm php8.3-cli (sesuaikan versi). Distribusi dan vendor LTS sudah menerima patch lebih dulu, jadi paket dari repo resmi biasanya sudah berisi perbaikan. Jika memakai PPA pihak ketiga, pastikan paketnya sudah ikut naik.
3. RHEL/Alma/Rocky: dnf update 'php*'. Alpine: apk upgrade lalu rebuild image.
4. Docker: perbarui base image, jangan hanya menambah label. docker pull php:8.3-fpm kemudian docker build --no-cache -t aplikasi-anda . Image resmi PHP di Docker Hub dan Docker Hardened Images sudah diperbarui; Docker menyebut image perbaikannya terbit dalam 24 jam setelah patch hulu.
5. Segarkan worker. systemctl restart php8.3-fpm atau docker restart NAMA_CONTAINER. Tanpa langkah ini, worker lama tetap memegang proses PHP yang rentan.
6. Verifikasi. Cek ulang dengan php -v dan pastikan situs utama masih merespons normal.

Kalau belum bisa update hari ini

Tim PHP menegaskan hanya update yang menyelesaikan masalah. Mitigasi berikut hanya menutup jalur serangan tertentu dan tidak membuat instalasi aman:

• Set memory_limit=-1 lewat php_admin_value di pool FPM atau konfigurasi Apache agar tidak bisa ditimpa aplikasi, untuk menutup jalur OOM pada CVE-2026-109618.
• Turunkan post_max_size ke 8M (atau 32M bila memang perlu upload) dan jaga upload_max_filesize di bawahnya.
• Set session.upload_progress.enabled=0 lewat php.ini atau pool, lalu segarkan semua worker, untuk menutup jalur session pada CVE-2026-109619. Pada PHP 8.5 tambahkan fatal_error_backtraces=0.
• Jangan mengandalkan ini_set(), .user.ini, atau menyembunyikan error dengan display_errors; pengaturan harus berlaku sebelum request diparsing.

Untuk pengelola situs instansi dan sekolah

Banyak situs pemerintah daerah, desa, dan sekolah masih berjalan di PHP 7.4 atau 8.1 yang sudah EOL. Untuk versi itu PHP hanya menyediakan backport sumber minimal bagi yang membangun dari source, bukan paket resmi. Praktisnya: jadwalkan upgrade ke 8.3 atau 8.4, uji di staging lebih dulu, lalu pindahkan produksi pada jendela maintenance. Celah seperti PHP2Shell adalah pengingat bahwa versi PHP yang tidak lagi dirawat bukan sekadar urusan performa, melainkan pintu masuk yang terbuka lebar.

Jangan lupa container dan trust store

Pada pekan yang sama, delapan sertifikat intermediate dari otoritas sertifikat eMudhra diketahui memiliki private key yang bisa dihitung dari sertifikat publiknya. Browser mencabut sertifikat seperti ini sendiri, tetapi image container membawa trust store-nya masing-masing dan tetap mempercayainya sampai image dibangun ulang. Docker menyebut sistem build-nya menjalankan 16.567 build paket dan image dalam 48 jam setelah rilis PHP. Pelajarannya sederhana: setelah base image dipatch, rebuild juga semua image turunan Anda.

Sumber: PHP.net - News Archive 2026 (security advisory 21 Oktober 2026), NVD CVE-2026-109618, NVD CVE-2026-109619, Docker - Security Update on PHP2Shell, Docker - PHP2Shell and eMudhra Patched.