PHP merilis pembaruan keamanan darurat pada 21 Oktober 2026 untuk dua kerentanan yang dikenal sebagai PHP2Shell: CVE-2026-109618 dan CVE-2026-109619. Keduanya dapat memungkinkan penyerang menjalankan kode di server tanpa login, atau unauthenticated remote code execution (RCE).
Menurut pengumuman resmi PHP, seluruh instalasi PHP yang melayani request web perlu ditangani. PHP menilai risiko paling tinggi ada pada Apache dengan mod_php, karena eksploitasi telah dibuktikan dapat terjadi sebelum kode aplikasi berjalan.
Catatan ini mengacu pada advisory yang diperiksa pada 23 Oktober 2026. Detail cakupan dan mitigasi dapat berubah; gunakan tautan sumber untuk memeriksa pembaruan berikutnya.
Apa yang dimaksud dengan PHP2Shell?
PHP2Shell adalah sebutan untuk dua kerentanan pada runtime PHP. Karena masalahnya berada di PHP itu sendiri, memperbarui Laravel, WordPress, plugin, atau dependency melalui Composer saja tidak menggantikan pembaruan runtime.
Kedua advisory resmi memberi skor CVSS v4.0 9,2, kategori kritis. Skor tersebut tidak berarti setiap server memiliki jalur eksploitasi yang identik. Keberhasilan serangan tetap dipengaruhi konfigurasi, aplikasi, ekstensi, build PHP, dan cara server menjalankan worker.
| CVE | Masalah utama | Dampak yang dikonfirmasi |
|---|---|---|
| CVE-2026-109618 | Penanganan kehabisan memori meninggalkan data internal request dalam keadaan tidak valid | RCE tanpa autentikasi telah dibuktikan pada Apache mod_php |
| CVE-2026-109619 | State global worker masih menunjuk ke memori request yang sudah dibebaskan | Kebocoran memori dan RCE; jalur session telah divalidasi pada mod_php dan PHP-FPM dengan prasyarat tertentu |
Kode hasil eksploitasi berjalan dengan hak akses akun web worker. Itu tidak otomatis berarti akses root, tetapi dapat membuka akses ke file, kredensial, dan layanan lain yang memang dapat dijangkau akun tersebut.
CVE-2026-109618: kegagalan saat kehabisan memori
PHP membatasi konsumsi memori request melalui memory_limit. Masalah muncul ketika kegagalan alokasi memori memutus proses saat data internal request belum selesai diinisialisasi. Pada tahap pembersihan, PHP dapat menggunakan data tidak valid itu seolah-olah sudah siap dipakai.
Advisory OOM corruption menjelaskan bahwa pemrosesan input multipart dapat memicu kondisi tersebut. Ukuran data di jaringan juga tidak selalu mencerminkan kebutuhan memori setelah PHP membentuk struktur internalnya. Karena itu, hanya membatasi ukuran upload tidak menutup seluruh risiko.
Pada mod_php, tahap pembersihan tetap berjalan meskipun inisialisasi request gagal. Inilah salah satu alasan serangan dapat bekerja sebelum aplikasi melakukan autentikasi atau validasi input.
PHP-FPM menghentikan child ketika startup request gagal, sehingga jalur tersebut berbeda. Namun, advisory tetap menilai FPM berpotensi terdampak melalui kegagalan setelah startup normal; eksploitasi lengkap untuk CVE ini pada FPM belum didemonstrasikan dalam advisory yang diperiksa.
CVE-2026-109619: state request tertinggal di worker
Worker PHP dapat melayani beberapa request secara berurutan. Sebagian state internal bertahan di worker, tetapi memori yang dirujuknya hanya dimiliki oleh satu request dan harus dibersihkan sebelum memori itu dibebaskan.
Pada kerentanan ini, reset tersebut dapat terlewat atau state terisi kembali pada tahap shutdown. Request berikutnya yang masuk ke worker yang sama kemudian dapat mengakses referensi lama. Kondisi ini disebut use-after-free.
Advisory stale global state mencatat beberapa jalur, termasuk diagnostik konfigurasi sebelum inisialisasi normal dan fitur Session Upload Progress. Fitur upload progress aktif secara default dan tidak memerlukan pemanggilan session_start() oleh aplikasi, tetapi eksploitasi tetap membutuhkan rangkaian kondisi yang sesuai.
Untuk jalur session pada FPM yang telah divalidasi, state dipublikasikan ketika aplikasi berjalan setelah startup berhasil, lalu terjadi fatal error sebelum request berikutnya mengonsumsinya. Jadi, menganggap semua konfigurasi FPM pasti aman atau pasti dapat dieksploitasi dengan cara yang sama akan mengabaikan prasyarat tersebut.
Menambah jumlah worker atau melakukan recycling dapat mengurangi peluang dua request mencapai worker yang sama. Keduanya tidak menghilangkan kerentanannya.
Versi PHP yang memuat perbaikan
PHP menerbitkan versi berikut untuk cabang yang masih didukung pada saat pengumuman:
| Cabang | Versi terdampak pada cabang tersebut | Rilis pertama yang memuat perbaikan |
|---|---|---|
| PHP 8.2 | Sebelum 8.2.35 | 8.2.35 |
| PHP 8.3 | Sebelum 8.3.36 | 8.3.36 |
| PHP 8.4 | Sebelum 8.4.27 | 8.4.27 |
| PHP 8.5 | Sebelum 8.5.12 | 8.5.12 |
Gunakan rilis yang memuat perbaikan tersebut atau rilis lebih baru pada cabang yang masih didukung. PHP 8.1 dan versi lebih lama tidak lagi menerima pembaruan resmi rutin dari proyek PHP. Periksa ketersediaan backport dari distributor atau penyedia LTS, atau migrasikan aplikasi ke cabang yang didukung.
PHP juga menyediakan minimal source backport untuk 7.4, 8.0, dan 8.1 sebagai bantuan darurat. Ketersediaan patch itu tidak mengembalikan status dukungan rutin cabang tersebut.
Paket distribusi Linux dapat memuat backport tanpa mengganti nomor versi upstream menjadi angka di tabel. Cocokkan versi paket lengkap dengan advisory distributor; jangan menilai status patch hanya dari header HTTP atau nomor versi pendek.
Langkah yang perlu dilakukan pengelola aplikasi
1. Inventarisasi runtime yang melayani request
Periksa server publik, layanan internal, container, image dasar, dan seluruh replika. Catat versi PHP, metode eksekusi seperti FPM atau mod_php, serta asal paketnya. Prioritaskan layanan yang terbuka ke internet, terutama mod_php.
Perintah berikut berguna untuk memeriksa PHP CLI:
php -v
php --ini
Hasilnya tidak membuktikan versi PHP yang dipakai web server. Satu host dapat memiliki beberapa versi PHP sekaligus. Verifikasi binary dan paket yang digunakan service FPM atau modul Apache, lalu cocokkan dengan konfigurasi deployment. Jika membutuhkan diagnostik melalui web, batasi aksesnya dan jangan meninggalkan halaman phpinfo() terbuka untuk publik.
2. Perbarui paket dan ganti worker lama
Pasang paket resmi yang sudah diperbaiki sesuai sistem operasi atau platform hosting. Untuk container, perbarui image dasar, bangun ulang image aplikasi, lalu deploy ulang seluruh replika. Jika memakai hosting terkelola, minta penyedia mengonfirmasi patch pada runtime yang benar-benar melayani aplikasi.
Restart atau ganti seluruh worker PHP setelah pembaruan. Memperbarui file binary di disk saja belum menjamin proses lama berhenti memakai kode yang rentan.
Setelah deployment, periksa kembali versi runtime aktif dan jalankan alur aplikasi yang menggunakan login, session, upload, serta operasi utama lainnya. Pastikan tidak ada replika atau pool lama yang tertinggal.
3. Jika belum bisa memperbarui, batasi paparan
PHP menyatakan pembaruan adalah satu-satunya penanganan lengkap. Batasi akses jaringan atau pertimbangkan menonaktifkan sementara layanan yang belum dapat diperbarui. WAF dapat menjadi lapisan tambahan, tetapi bukan bukti bahwa server sudah aman.
Advisory menyediakan mitigasi parsial untuk jalur tertentu:
- Menonaktifkan
session.upload_progress.enabledmelalui konfigurasi administratif yang berlaku sebelum parsing request, lalu me-restart seluruh worker, memblokir jalur session yang didemonstrasikan.ini_set()atau FPM.user.initidak cukup untuk tujuan ini. - Pada PHP 8.5, menonaktifkan
fatal_error_backtracesdan me-restart worker memblokir jalur fatal backtrace yang telah dikonfirmasi, tetapi tidak mencakup seluruh state global lainnya. - Membatasi ukuran request yang sudah didekode, jumlah bagian multipart, header, input, dan kedalaman nesting di frontend dapat mengurangi jalur pemicu serta risiko denial of service. Blokir multipart sebelum mencapai PHP jika aplikasi tidak memerlukannya.
Untuk CVE-2026-109618, PHP juga menjelaskan memory_limit=-1 sebagai mitigasi parsial terhadap kegagalan pada batas memori per request. Pengaturan ini menghapus batas memori PHP dan menambah risiko kehabisan memori pada host; kegagalan alokasi di lapisan sistem tetap dapat mencapai jalur rentan. Jangan menerapkannya sebagai resep umum tanpa menilai pembatasan sumber daya dan risiko ketersediaan. Ikuti advisory lengkap, termasuk larangan memakai RLIMIT_AS atau RLIMIT_DATA sebagai pengganti karena keduanya dapat memicu kegagalan alokasi yang rentan.
Menyembunyikan warning dengan display_errors, error_reporting, atau operator @ tidak memperbaiki akses ke state internal yang bermasalah.
Apakah sudah ada eksploitasi aktif?
watchTowr melaporkan pengamatan eksploitasi kedua CVE di dunia nyata melalui jaringan honeypot mereka pada 21 Oktober 2026. Ini merupakan laporan pengamatan dari watchTowr; artikel ini tidak melakukan validasi eksploitasi secara mandiri.
Bedakan status patch dengan status kompromi. Memasang patch menutup kerentanan yang diperbaiki, tetapi tidak menghapus backdoor atau kredensial yang mungkin sudah dicuri sebelumnya.
Jika ada indikasi serangan, simpan log dan bukti yang relevan, isolasi sistem sesuai prosedur respons insiden, lalu periksa file web yang berubah, proses atau koneksi keluar yang tidak dikenal, serta mekanisme persistensi. Error kehabisan memori atau worker crash bisa menjadi petunjuk investigasi, tetapi tidak cukup sebagai bukti eksploitasi. Ketiadaan error di log juga bukan bukti bahwa server aman.
Jangan menjalankan PoC acak pada server produksi. Verifikasi perbaikan melalui paket vendor, runtime aktif, dan pemeriksaan aplikasi; lakukan pengujian keamanan hanya di lingkungan terisolasi yang memang diizinkan.