Halo friends, kali ini kita akan bahas dua vulnerability PHP yang sedang menjadi perhatian, yaitu CVE-2026-109618 dan CVE-2026-109619. Keduanya dikaitkan dengan remote code execution atau RCE, sehingga perlu diperhatikan oleh developer, administrator server, dan pemilik website yang menggunakan PHP.
Yang membuat isu ini ramai adalah beredarnya demonstrasi tool bernama php2shell dengan klaim pengujian pada beberapa aplikasi dan framework PHP.
Kalau website kita menggunakan WordPress atau Laravel, apakah otomatis bisa diambil alih? Apa yang bisa dilakukan sebelum patch resmi tersedia? Ayo kita bahas dengan membedakan informasi yang sudah dikonfirmasi dan mitigasi yang masih bersifat sementara.
Catatan status: artikel ini disusun pada 21 Oktober 2026 berdasarkan pengumuman sebelum rilis keamanan PHP. Detail versi terdampak dan perbaikannya perlu dicocokkan kembali dengan advisory terbaru saat menerapkan penanganan.
Apa yang Sudah Dikonfirmasi?
PHP Security Team telah mengumumkan rilis keamanan untuk dua kerentanan kritis dengan skor CVSS v4.0 sebesar 9.2. Rilis dijadwalkan pada 21 Oktober 2026 pukul 14.00 UTC atau 21.00 WIB, dengan kemungkinan dipercepat bila detail teknis menjadi publik atau ditemukan eksploitasi aktif. Pengumuman tersebut menyatakan detail dan versi perbaikan akan diterbitkan bersama rilis.
CERT-EU mengaitkan isu ini dengan CVE-2026-109618 dan CVE-2026-109619 serta potensi RCE tanpa autentikasi. Namun, pada advisory awal, detail teknis belum tersedia.
Artinya, kita punya alasan kuat untuk mempersiapkan pembaruan. Tetapi kita belum punya dasar untuk menyatakan setiap website PHP dengan konfigurasi apa pun pasti dapat dieksploitasi.
Kenapa WordPress dan Laravel Ikut Dibicarakan?
WordPress, Laravel, dan berbagai aplikasi lain menggunakan PHP untuk menjalankan kode di server. Karena itu, ketika ada isu keamanan pada runtime PHP, pemeriksaan tidak cukup berhenti pada versi CMS atau framework.
Misalnya kita sudah memperbarui WordPress dan seluruh pluginnya. Itu langkah yang baik, tetapi versi PHP yang menjalankan website tetap perlu diperiksa.
Dari sisi pengelolaan server, ada beberapa lapisan yang berbeda: aplikasi, dependency, runtime PHP, dan sistem operasi. Pembaruan pada salah satu lapisan belum tentu memperbarui lapisan lainnya.
Jadi, jangan menyimpulkan website sudah aman hanya karena dashboard WordPress tidak lagi menampilkan notifikasi update.
Cara Menerapkannya
Sebelum mengubah konfigurasi, simpan salinan konfigurasi sebelumnya dan identifikasi bagaimana website menjalankan PHP. Lokasi file dan nama service dapat berbeda antarserver.
Melalui php.ini atau File Konfigurasi Tambahan
Pada konfigurasi PHP yang melayani website, tambahkan atau ubah:
session.upload_progress.enabled = Off
Pastikan file yang diedit memang dimuat oleh PHP web/FPM yang digunakan. Pemeriksaan php –ini melalui terminal membantu inventaris PHP CLI, tetapi hasilnya belum tentu sama dengan konfigurasi web.
Setelah perubahan, jalankan pemeriksaan konfigurasi yang sesuai dengan instalasi, lalu reload PHP-FPM atau restart layanan yang memuat PHP agar konfigurasi dibaca kembali. Contoh pada server systemd dengan PHP-FPM 8.3:sudo systemctl reload php8.3-fpm
Sesuaikan nama service dengan server. Jika memakai container, masukkan perubahan dalam konfigurasi deployment/image lalu redeploy; jangan hanya mengedit container sementara.
Melalui .user.ini pada CGI/FastCGI
Jika hosting mengaktifkan dukungan .user.ini, gunakan sintaks INI:
session.upload_progress.enabled = Off
PHP memproses .user.ini pada CGI/FastCGI, dan pembacaan ulang dapat tertunda oleh cache konfigurasi; nilai default intervalnya 300 detik. Lokasi file juga mengikuti direktori script dan document root.
Jangan mengasumsikan pengaturan per-direktori sudah melindungi semua entry point atau jalur pemrosesan awal request. Untuk mitigasi ini, prioritaskan konfigurasi tingkat runtime/server dan minta konfirmasi provider apabila hanya memiliki akses shared hosting.
Melalui .htaccess pada Apache mod_php
Untuk Apache yang benar-benar menjalankan PHP sebagai module dan mengizinkan override, sintaks boolean yang digunakan adalah:
php_flag session.upload_progress.enabled Off
Ini berbeda dari format php.ini. Dukungan konfigurasi melalui .htaccess bergantung pada mode PHP dan kebijakan Apache.
Jangan memasangnya sembarangan pada Apache yang menggunakan PHP-FPM. Directive yang tidak didukung dapat menyebabkan error konfigurasi. Jika mode PHP belum diketahui, periksa terlebih dahulu atau gunakan bantuan provider.
Setelah Diubah, Bagaimana Memeriksanya?
Periksa nilai efektif melalui request web pada setiap backend yang melayani website, bukan hanya melalui CLI. Bila perlu, gunakan endpoint diagnostik sementara yang hanya dapat diakses administrator:<?phpheader('Content-Type: application/json; charset=utf-8');header('Cache-Control: no-store');
$value = ini_get('session.upload_progress.enabled');
echo json_encode(['sapi' => PHP_SAPI,'upload_progress_available' => $value !== false,'upload_progress_enabled' => $value === false? null: filter_var($value, FILTER_VALIDATE_BOOLEAN),]);
Hasil yang diharapkan untuk instalasi dengan directive tersedia adalah:
upload_progress_enabled: false.
Jika directive tidak tersedia, hasil null perlu diperiksa lebih lanjut, bukan dianggap bukti mitigasi berhasil.
Batasi akses endpoint melalui autentikasi atau IP allowlist, hindari cache, lalu hapus setelah pemeriksaan. Pada sistem dengan beberapa node/pool/container, periksa masing-masing secara langsung melalui jalur administrasi yang diizinkan.
Nilai Off membuktikan konfigurasi efektif pada request yang diperiksa. Itu belum membuktikan kedua CVE tidak dapat dieksploitasi, dan belum membuktikan cakupan seluruh tahap pemrosesan request.
Lakukan juga smoke test login, upload, dan fitur terkait. Menonaktifkan pengaturan ini tidak sama dengan menonaktifkan seluruh upload file. Namun, aplikasi yang bergantung pada pelacakan progres melalui session bisa kehilangan fungsi tersebut.
Apa Lagi yang Perlu Dilakukan?
Menurut kami, pekerjaan terpenting adalah memastikan tim mengetahui seluruh runtime PHP yang digunakan dan siap memperbaruinya.
- Inventaris versi PHP pada website, API, aplikasi internal, image container, dan layanan hosting.
- Siapkan backup serta rollback sebelum pembaruan.
- Pantau advisory resmi dan cocokkan versi paket yang sudah diperbaiki, termasuk informasi backport vendor bila digunakan.
- Prioritaskan aset yang dapat diakses dari internet.
- Bila exposure tinggi dan patch belum dapat diterapkan, pertimbangkan pembatasan akses atau isolasi sesuai kebutuhan bisnis. Langkah ini juga disarankan dalam advisory CERT-EU.
- Jangan menganggap WAF otomatis memiliki proteksi khusus sebelum ada aturan yang tervalidasi. WAF dan kontrol akses dapat menjadi lapisan tambahan, sedangkan pembaruan runtime tetap harus dipersiapkan.
Jika ditemukan indikasi kompromi, perlakukan sebagai kebutuhan investigasi tersendiri. Mengganti konfigurasi atau memperbarui PHP tidak otomatis membersihkan file yang sudah ditanam ataupun membatalkan credential yang sudah dicuri.
Untuk organisasi yang memerlukan bantuan memetakan exposure dan memvalidasi penanganan pada aplikasi, tim Ethic Ninja dapat membantu melalui pengujian keamanan dengan scope yang disepakati.