Apa yang terjadi
Pada 21 Oktober, proyek PHP merilis perbaikan untuk dua kerentanan, CVE-2026-109618 dan CVE-2026-109619. Keduanya bernilai CVSS 9.2 dan, menurut tulisan Arctic Wolf, dapat membuat penyerang tanpa autentikasi menjalankan kode di server yang menangani request web dengan PHP.
Bug-bug ini ada di siklus penanganan request milik PHP sendiri, bukan di framework atau plugin:
- CVE-2026-109618 adalah kerusakan memori yang dipicu ketika kondisi kehabisan memori menginterupsi PHP saat data request baru sebagian disiapkan.
- CVE-2026-109619 adalah use-after-free: state milik satu request bisa bertahan dan dibaca oleh request berikutnya di worker yang sama, yang juga bisa membocorkan isi memori.
Poin kedua itu layak direnungkan. Qualys mencatat bahwa memori worker yang bocor bisa berisi password, token, dan API key. Jadi meskipun tidak ada yang mendapat shell di server-mu, rahasia tetap bisa keluar.
Semuanya bergerak cepat setelah patch, dan skalanya besar: The Hacker News mengutip estimasi Censys bahwa lebih dari 32 juta layanan PHP masih menjalankan versi yang terdampak.
- Tim threat intelligence Amazon menyatakan penargetan dimulai empat hari sebelum perbaikan dipublikasikan, seperti dilaporkan BleepingComputer.
- Pada 24 Oktober, seorang peneliti di Perplexity mengonfirmasi eksekusi kode yang berhasil terhadap honeypot (The Hacker News).
- Pada 26 Oktober, CISA menambahkan kedua CVE ke katalog Known Exploited Vulnerabilities dan memberi lembaga federal AS waktu hingga 29 Oktober untuk memperbaikinya.
Kenapa ini relevan bahkan untuk aplikasi kecil
Penyerang di sini tidak memilih target berdasarkan ukuran perusahaan. Mereka memindai internet untuk apa saja yang merespons seperti PHP lalu mencoba eksploitnya. Proyek sampingan yang terlupakan di VPS sama mudahnya dijangkau seperti situs e-commerce besar.
Beberapa detail membuat yang satu ini sangat layak segera ditindaklanjuti:
- Tidak bergantung pada kodemu. Arctic Wolf menunjukkan bahwa karena celahnya ada di pemrosesan request PHP, keterpaparan tidak bergantung pada aplikasi apa yang kamu jalankan. Aplikasi Laravel yang ditulis sempurna di build PHP lama tetap terekspos.
- Banyak konfigurasi server yang termasuk. Apache dengan mod_php dianggap berisiko paling tinggi, tetapi PHP-FPM, php-cgi, FrankenPHP, dan LiteSpeed juga disebut terdampak, begitu pula produk dan appliance yang membundel PHP.
- PHP lama itu umum. Qualys melaporkan sekitar 71% instalasi PHP yang bisa diidentifikasi versinya sudah end-of-life. Kalau kamu di 8.1 atau lebih lama, tidak ada perbaikan upstream reguler untukmu.
Cara mengecek aplikasimu
Kamu mencari satu jawaban per server: apakah ada yang melayani request web dengan PHP, dan versi persisnya apa?
1. Daftar semua yang kamu hosting. Bukan hanya aplikasi utama. Sertakan situs marketing, blog, dokumentasi, environment staging, tool admin, dan apa saja di subdomain. Yang terlupakan justru yang berbahaya.
2. Lihat response header. Banyak setup PHP mengumumkan dirinya di header X-Powered-By atau Server. Tidak adanya header bukan berarti tidak ada PHP (bisa dimatikan dengan expose_php = Off), tetapi adanya header adalah jawaban "ya" yang cepat. Halaman error verbose juga membocorkan informasi: stack trace PHP di production memberi tahu penyerang persis apa yang kamu jalankan.
curl -sI https://your-site.example | grep -i -E 'x-powered-by|server'
# X-Powered-By: PHP/8.3.20 <- PHP, and an old patch level3. Cek versi yang melayani trafik web, bukan hanya CLI. php -v di server bisa melaporkan build yang berbeda dari yang benar-benar dipakai Apache atau PHP-FPM; Qualys secara khusus menyoroti hal ini. Cek binary FPM atau modul PHP di web server-mu, atau tanyakan ke penyedia hosting.
php-fpm8.3 -v # or php-fpm -v, depending on your distro
apache2ctl -M | grep php # is mod_php loaded?4. Bandingkan dengan versi yang sudah diperbaiki. Kalau kamu memasang PHP dari distribusi Linux, perbaikannya mungkin di-backport ke paket dengan nomor versi yang terlihat lebih lama, jadi cek advisory distro-mu, bukan hanya string versinya. Selain itu, kamu butuh minimal:
- PHP 8.5: 8.5.12
- PHP 8.4: 8.4.27
- PHP 8.3: 8.3.36
- PHP 8.2: 8.2.35
5. Pakai managed hosting? Kalau kamu di host WordPress terkelola atau PaaS, cek status page atau changelog mereka untuk pemberitahuan PHP2Shell. Sebagian besar akan menambal untukmu, tapi "sebagian besar" bukan "semua", dan VPS yang kamu kelola sendiri sepenuhnya tanggung jawabmu.
Cara memperbaikinya
Tambal, lalu restart. Memperbarui PHP adalah satu-satunya perbaikan yang lengkap.
Restart itu penting: worker yang sedang berjalan menyimpan kode lama di memori sampai diganti. Untuk Docker, build ulang dengan base image yang sudah diperbarui (misalnya tag php:8.3-fpm terbaru) lalu deploy ulang. Jangan hanya me-restart container lama.
Di Debian atau Ubuntu dengan setup PHP-FPM, biasanya kira-kira seperti ini:
sudo apt update && sudo apt install --only-upgrade 'php8.3*'
sudo systemctl restart php8.3-fpm
sudo systemctl restart apache2 # if you use mod_phpKalau kamu tidak bisa menambal hari ini, Qualys merangkum mitigasi sementara dari PHP. Mitigasi ini mengurangi risiko tetapi tidak membuat server yang belum ditambal menjadi aman. Atur di php.ini atau konfigurasi pool FPM (bukan .user.ini atau ini_set), lalu restart semua worker.
Kalau sebuah layanan belum ditambal dan tidak perlu publik, taruh di balik VPN atau allowlist IP, atau matikan dulu sampai kamu bisa memperbarui.
; php.ini or FPM pool config (not .user.ini or ini_set)
session.upload_progress.enabled = 0
post_max_size = 8M ; 32M if you need uploads
upload_max_filesize = 6M ; keep below post_max_sizeKalau kamu di PHP 8.1 atau lebih lama, rencanakan upgrade sekarang. Ada backport terbatas untuk beberapa branch lama, tapi kamu mengandalkan keberuntungan setiap kali hal seperti ini muncul.
Cari tanda-tanda kompromi. Periksa proses yang tidak terduga, file baru di web root, cron job yang asing, dan koneksi keluar dari web server. Arctic Wolf juga mencatat bahwa banyak request "PHP2Shell" di log memakai ulang teknik lama, jadi baris log yang terlihat menakutkan belum tentu berarti pembobolan berhasil.
Rotasi rahasia kalau kamu sempat terekspos. Karena CVE-2026-109619 bisa membocorkan memori worker, anggap rahasia yang melewati proses PHP yang belum ditambal dan menghadap internet sebagai mungkin sudah terlihat. Itu termasuk password database, API key, kunci penandatanganan sesi, dan kunci penyedia pembayaran. Laravel dan framework serupa menyimpannya di .env, jadi pastikan juga file itu tidak pernah bisa diakses lewat web sejak awal.
Checklist singkat
Jalankan ini untuk setiap domain yang kamu miliki:
- Setiap domain dan subdomain milikmu sudah terdaftar, termasuk situs marketing dan staging lama.
- Kamu tahu mana yang menjalankan PHP, dan versi persis yang melayani web.
- Masing-masing sudah di 8.5.12, 8.4.27, 8.3.36, 8.2.35, atau build yang sudah ditambal vendor.
- Worker PHP dan web server sudah di-restart setelah pembaruan.
- Apa pun yang belum ditambal sudah dibatasi atau dimatikan, dengan mitigasi diterapkan.
- Rahasia di host yang terekspos sudah dirotasi.
- Production tidak lagi mengiklankan versi PHP-nya atau menampilkan stack trace.
Pelajaran yang lebih besar
PHP2Shell akan ditambal dan dilupakan dalam beberapa minggu. Polanya tidak. Jarak antara "perbaikan dipublikasikan" dan "sedang dieksploitasi" kini hanya hitungan hari, kadang bahkan negatif. Tim kecil tidak bisa mengejarnya dengan aksi heroik. Yang berhasil adalah tahu apa yang kamu jalankan dan cepat menyadari ketika ada yang berubah.
Itu pemikiran yang sama di balik checklist peluncuran kami untuk aplikasi buatan AI: sebagian besar insiden nyata berasal dari hal-hal yang mudah dicek, asalkan kamu benar-benar mengeceknya.
AppSafe memindai situs live-mu dari luar, seperti yang dilihat penyerang. AppSafe mencari masalah seperti security header yang hilang, header X-Powered-By yang membocorkan stack-mu, file yang terekspos, dan error verbose, lalu memberimu perbaikan dalam bahasa yang mudah dipahami. Setelah menambal, jalankan scan gratis di setiap domainmu untuk sekalian menangkap perbaikan mudah lainnya.