PHP2Shell: Celah Kritis Remote Code Execution di Inti PHP (CVE-2026-109618 dan CVE-2026-109619)

Pendahuluan

Pada 21 Oktober 2026, komunitas keamanan siber dunia menghadapi salah satu pengungkapan kerentanan terbesar dalam sejarah ekosistem web. Dua celah kritis di dalam mesin inti (core engine) PHP, bahasa pemrograman server-side yang menjalankan sekitar 70% situs web di dunia, diumumkan bersamaan dengan rilis perbaikannya. Rangkaian celah ini dijuluki PHP2Shell.

Kedua celah tersebut tercatat sebagai CVE-2026-109618 (RCE via OOM corruption) dan CVE-2026-109619 (RCE via stale global state). Masing-masing dinilai CVSS v4.0 9.2, dan keduanya dapat dimanfaatkan penyerang tanpa autentikasi untuk mengeksekusi kode dari jarak jauh (Remote Code Execution, RCE) di server yang menjalankan PHP.

Yang membuat PHP2Shell istimewa bukan hanya tingkat keparahannya. Celah ini berada di PHP itu sendiri, bukan di aplikasi yang berjalan di atasnya. Artinya, WordPress, Drupal, Joomla, Moodle, Laravel, hingga aplikasi buatan sendiri yang kodenya sudah ditulis dengan aman tetap bisa terdampak selama versi PHP yang dipakai belum diperbarui.

Artikel ini merangkum apa itu PHP2Shell, bagaimana kedua CVE bekerja pada tingkat konsep, siapa saja yang berisiko, peran kecerdasan buatan dalam penemuannya, serta langkah-langkah praktis yang perlu diambil oleh administrator sistem, pengembang, dan institusi pendidikan. Pembahasan teknis sengaja dijaga pada tingkat konseptual untuk tujuan edukasi dan mitigasi, dan tidak memuat langkah eksploitasi.

Sekilas tentang PHP dan Mengapa Celah Ini Berdampak Luas

PHP adalah tulang punggung web modern. Menurut W3Techs yang dikutip oleh ProjectDiscovery, PHP digunakan oleh 69,3% situs web yang bahasa server-side-nya dapat diidentifikasi. Pada 21 Oktober 2026, Shodan juga mencatat lebih dari 1,6 juta rekaman layanan yang secara eksplisit menampilkan versi PHP.

Beberapa sistem populer yang berbasis PHP antara lain:

• Sistem manajemen konten: WordPress, Joomla, Drupal, dan MediaWiki (perangkat lunak di balik Wikipedia).
• Platform pembelajaran dan wiki: Moodle dan MediaWiki.
• Panel hosting dan administrasi: cPanel, Plesk, phpMyAdmin, dan Adminer.
• Pemantauan jaringan: Zabbix, Cacti, Nagios XI, dan LibreNMS.
• Perangkat jaringan dan telepon: pfSense, OPNsense, dan FreePBX.
• Surel dan berkas: Roundcube, Nextcloud, dan ownCloud.
• Penagihan, CRM, dan helpdesk: WHMCS, SuiteCRM, vTiger, osTicket, dan GLPI.

Karena PHP berada pada lapisan fondasi, satu kelemahan di mesin inti dapat merambat ke jutaan situs sekaligus. Tim Wiz Research menyebut bahwa setiap versi PHP yang dirilis dalam satu dekade terakhir terdampak oleh setidaknya satu dari celah ini, dengan jangkauan hingga PHP 5.4.

Ringkasan Dua CVE

Penjelasan resmi dari tim PHP merumuskan keduanya sebagai berikut.

• CVE-2026-109618 (RCE via OOM corruption): penanganan kondisi kehabisan memori (out-of-memory) dapat menginterupsi PHP ketika data internal permintaan baru terinisialisasi sebagian. Proses pembersihan permintaan kemudian bisa memperlakukan data yang tidak valid itu seolah-olah valid.
• CVE-2026-109619 (RCE via stale global state): status internal milik sebuah permintaan dapat tetap tersisa setelah memori pendukungnya dibebaskan. Permintaan berikutnya yang ditangani oleh worker yang sama dapat menggunakan status basi tersebut sebelum inisialisasi normal mereset-nya.

Sebagai catatan, tim Wiz Research menyatakan bahwa semua kerentanan yang mereka laporkan adalah masalah keamanan memori (memory-safety) yang berakar pada cara PHP menangani fatal error, terutama out-of-memory, di tengah pemrosesan permintaan. Kondisi itu dapat meninggalkan keadaan internal PHP yang rusak setelah permintaan berakhir tiba-tiba, lalu dipakai ulang oleh permintaan atau worker berikutnya.

Memahami Akar Masalah Secara Konseptual

Untuk memahami PHP2Shell, ada tiga gagasan dasar yang perlu dipahami.

1. Model permintaan PHP dan pemakaian ulang worker

Pada umumnya, PHP menangani setiap permintaan HTTP dengan siklus yang bersih: menyiapkan memori, menjalankan kode, lalu membebaskan semuanya. Namun worker (misalnya proses PHP-FPM atau modul Apache mod_php) tidak dihentikan setelah satu permintaan. Satu proses worker melayani banyak permintaan secara berurutan. Akibatnya, apabila ada sisa status dari permintaan sebelumnya yang tidak dibersihkan dengan benar, permintaan berikutnya dapat "mewarisinya".

2. Kegagalan alokasi memori di tengah jalan

Ketika PHP kehabisan memori pada titik yang sangat awal dalam pemrosesan permintaan, seluruh heap permintaan dihancurkan secara paksa. Jika ada variabel global yang masih menunjuk ke memori yang baru saja dibebaskan, penunjuk tersebut menjadi dangling pointer. Inilah yang dalam literatur keamanan dikenal sebagai kelas bug use-after-free: program terus memakai memori yang sebenarnya sudah dilepas.

3. Dari bug memori menjadi eksekusi kode

Bug use-after-free tidak otomatis berarti eksekusi kode. Penyerang harus mengisi kembali area memori yang dibebaskan itu dengan data pilihannya, lalu membuat PHP memperlakukan data tersebut sebagai struktur internal yang sah. Tim Wiz menjelaskan bahwa proses ini sangat rumit karena melibatkan beberapa bug yang dirangkai, serta penyesuaian terhadap tata letak memori yang berbeda pada tiap versi, konfigurasi, dan aplikasi.

Empat Bug di Balik Dua CVE

Tim Wiz Research melaporkan empat contoh bug yang dikelompokkan di bawah dua CVE tersebut. Keempatnya mengikuti pola yang sama: kegagalan fatal akibat kehabisan memori meninggalkan status yang tidak konsisten.

Bug 1: Use-after-free pada unserializer progres unggah (CVE-2026-109618)

Modul Session PHP dapat mendekode data sesi saat menangani progres unggah berkas pada fase sebelum inisialisasi penuh. Pembukuan internal milik permintaan disimpan pada struktur global. Jika alokasi memori gagal secara fatal di jalur ini, heap permintaan dihancurkan, tetapi status unserializer yang sudah dipublikasikan tetap tertinggal.

Pada permintaan berikutnya yang ditangani worker yang sama, PHP dapat mengonsumsi memori yang diisi ulang oleh penyerang sebagai pembukuan unserializer yang sah. Menurut Wiz, kondisi ini menjadi primitif kerusakan memori yang kuat, dan ketika dikombinasikan dengan kebocoran memori, dapat menghilangkan ketidakpastian alamat sehingga memungkinkan RCE tanpa autentikasi pada WordPress, Drupal, dan Joomla.

Bug 2: Kebocoran memori proses dari jarak jauh (CVE-2026-109618)

PHP mengurai permintaan multipart (RFC 1867) pada tahap awal, sebelum inisialisasi modul normal selesai. Penanganan progres unggah sesi dapat menginisialisasi status Session lebih awal dan menyimpan ID sesi pada variabel internal. Bila terjadi kehabisan memori sebelum pembersihan selesai, heap dihancurkan sementara penunjuk ID sesi masih mengarah ke area yang sudah bebas.

Permintaan multipart berikutnya pada worker yang sama dapat mencapai jalur pembersihan itu dan mempercayai penunjuk basi tersebut sebagai string yang sah. Isi memori yang telah digunakan ulang kemudian ikut dikodekan ke dalam cookie PHPSESSID pada respons. Serangan ini bekerja bahkan ketika aplikasi tidak pernah memanggil session_start(), sehingga bersifat agnostik terhadap aplikasi. Wiz mendemonstrasikan pembacaan sebagian memori worker yang hidup, termasuk data dari luar permintaan penyerang. Data tersebut berpotensi memuat kata sandi, token, kunci API, dan sertifikat.

Bug 3: Use-after-free pada backtrace galat fatal (CVE-2026-109619)

Pada versi yang terdampak, PHP menyimpan backtrace dari galat fatal terakhir pada variabel global eksekutor. Galat fatal akibat kehabisan memori dapat menghancurkan heap permintaan tanpa mengosongkan variabel global tersebut. Worker tetap hidup dengan penunjuk yang mengarah ke memori milik permintaan sebelumnya.

Jika worker yang sama mengeluarkan pesan diagnostik di awal permintaan berikutnya, penunjuk itu bisa diakses sebelum eksekutor diinisialisasi ulang. Hasilnya adalah use-after-free lintas permintaan yang dapat dikembangkan menjadi kerusakan memori terkendali. Wiz mendemonstrasikan RCE tanpa autentikasi terhadap Drupal melalui primitif ini.

Bug 4: Type confusion pada OPcache (CVE-2026-109619)

OPcache menyimpan struktur PHP yang sudah dikompilasi dalam memori bersama, dan menetapkan indeks ke dalam peta penunjuk milik masing-masing worker. Antar-worker berkoordinasi melalui sebuah "batas depan" (frontier) bersama. Selama proses penyimpanan skrip, frontier lokal proses maju terlebih dahulu, sedangkan frontier bersama baru diperbarui setelah proses selesai. Kegagalan alokasi di antara dua peristiwa itu menyisakan kondisi tidak sinkron.

Ketika worker lain kemudian memakai ulang salah satu slot untuk objek runtime yang berbeda, metadata bersama yang basi diterjemahkan menjadi penunjuk dengan tipe yang salah. Ketidakcocokan ini menimbulkan type confusion lintas-worker dan merusak status OPcache bersama. Wiz menggunakannya untuk membangun rantai RCE tanpa autentikasi terhadap WordPress.

Varian lain

Wiz menegaskan bahwa ada varian lain, yang sebagian terlacak dan kemungkinan sebagian belum, dengan syarat eksploitasi dan dampak yang berbeda. Setelah penelitian berjalan, tim menyimpulkan bahwa kelemahan ini berakar dalam pada basis kode PHP dan memerlukan perbaikan yang menyeluruh. Perbaikan yang dirilis tim PHP disebut menangani masalah pada intinya sehingga menghapus seluruh varian pada rilis yang sudah ditambal.

Siapa yang Berisiko?

Tim PHP menyatakan bahwa semua instalasi PHP yang melayani permintaan web berisiko, termasuk PHP-FPM, Apache dengan mod_php, php-cgi, FrankenPHP, dan LiteSpeed. Risiko dinilai paling tinggi pada mod_php, karena telah ada eksploitasi terdemonstrasi di mana satu permintaan tanpa autentikasi dapat memicu serangan sebelum kode aplikasi mana pun dijalankan.

Wiz mencatat bahwa bahkan aplikasi sederhana sekelas "Hello World" pada versi PHP yang terdampak dapat rentan. Dalam demonstrasi, mereka menggabungkan kerentanan tersebut menjadi satu skrip exploit internal bernama php2shell, lalu menunjukkan eksekusi kode tanpa autentikasi pada citra kontainer terbaru WordPress, Drupal, dan Joomla saat pengujian. Selain RCE, penyerang juga dapat membaca data sensitif dari memori proses PHP tanpa perlu mencapai eksekusi kode.

Layanan yang paling berisiko biasanya adalah yang berjalan bertahun-tahun tanpa perhatian: panel administrasi hosting, alat pemantauan, perangkat jaringan, hingga aplikasi internal yang lupa diperbarui. ProjectDiscovery menyoroti beberapa alasan PHP sulit ditemukan dalam inventaris:

• Layanan berjalan pada port non-standar, misalnya 2083, 2087, 8080, 8443, dan 8880.
• Aplikasi berada pada sub-path, seperti /phpmyadmin/ atau /webmail/ pada host yang tampak seperti situs statis.
• Versi PHP disembunyikan melalui expose_php = Off atau aturan proksi/CDN yang menghapus header X-Powered-By.
• Perangkat dan panel kerap menyertakan PHP sendiri, sehingga perbaikan datang dalam bentuk pembaruan dari vendor.
• Kontainer yang dibangun di atas citra php: lama akan mempertahankan versi PHP lama sampai dibangun ulang.
• Domain terlupakan, seperti situs kampanye, salinan staging, dan server uji di luar inventaris utama.

Dampak di Dunia Nyata

ProjectDiscovery menggambarkan bahwa pada 21 Oktober 2026 sebagian besar internet seolah masuk ke mode pemeliharaan. Layanan seperti DeviantArt dan Pokémon Home dilaporkan luring, Wikimedia menonaktifkan banyak layanan di balik Wikipedia, dan sejumlah instansi pemerintah di Belanda, Finlandia, dan Denmark menurunkan situs publiknya, begitu pula Pelabuhan Rotterdam dan beberapa rumah sakit di Belanda. Penyedia hosting menjalankan pemeliharaan darurat semalaman dan menonaktifkan fitur PHP pada server bersama sambil menunggu paket pembaruan.

Sejumlah lembaga keamanan, yaitu CISA, NSA, NCSC Inggris, dan CERT-EU, menyampaikan imbauan agar segera menambal dan, bila tidak memungkinkan, mengisolasi atau memutus sistem PHP dari internet publik sampai pembaruan terpasang. Cloudflare juga melaporkan adanya lalu lintas serangan sebelum perbaikan dirilis.

Peran Kecerdasan Buatan: Titik Balik yang Perlu Dicermati

Salah satu aspek yang paling banyak dibicarakan dari PHP2Shell adalah peran AI. Menurut Wiz Research, kode yang rentan telah ada lebih dari satu dekade. Yang berubah bukan keberadaan bug-nya, melainkan kemampuan untuk memahami kelemahan tersebut dan mengubahnya menjadi exploit yang berfungsi.

Tim Wiz menggunakan Wiz Atlas, Gemini 4 Argon, dan GPT-5.6 Sol selama penelitian. Mereka menyatakan bahwa model AI terdepan membuat proses yang rumit menjadi praktis: menyesuaikan exploit terhadap tata letak memori, versi, dan konfigurasi yang berbeda, dengan siklus uji dan debugging yang berulang. Dalam kesimpulannya, Wiz menyebut seorang peneliti dapat menyelesaikan dalam sekitar satu minggu pekerjaan yang sebelumnya memerlukan tim kelas dunia selama berbulan-bulan.

Implikasinya penting bagi dunia keamanan dan pendidikan informatika.

1. Kompleksitas tidak lagi menjadi tameng. Selama ini, banyak celah memori dianggap "sulit dieksploitasi" sehingga prioritas perbaikannya rendah. Ketika AI menurunkan biaya dan keahlian yang dibutuhkan, asumsi itu perlu ditinjau ulang.
2. Ekonomi penemuan dan eksploitasi berubah. Celah lama yang tersembunyi bertahun-tahun menjadi lebih mungkin ditemukan, baik oleh peneliti maupun penyerang.
3. Pertahanan juga diuntungkan. Kemampuan yang sama dapat digunakan pembela untuk menemukan dan memperbaiki cacat yang lolos dari pemeriksaan bertahun-tahun, serta memvalidasi tambalan. Wiz menyebut peluangnya adalah menjadikan pekerjaan ini rutin: menemukan kelemahan pada perangkat lunak yang sudah ada dan menangkap yang baru sebelum masuk produksi.

Bagi mahasiswa dan dosen informatika, ini menegaskan pentingnya literasi keamanan perangkat lunak, pemahaman manajemen memori, serta etika pemanfaatan AI dalam penelitian keamanan, selaras dengan diskusi tentang kebijakan AI dan masyarakat 5.0.

Garis Waktu Pengungkapan

Berdasarkan catatan Wiz Research dan pengumuman PHP:

• 19 Agustus 2026: Wiz Research menemukan kerentanan PHP pertama menggunakan Wiz Atlas, Gemini 4 Argon, dan GPT-5.6 Sol.
• 20 Agustus 2026: RCE tanpa autentikasi terkonfirmasi pada Drupal.
• 21 Agustus 2026: RCE tanpa autentikasi terkonfirmasi pada WordPress.
• 24 Agustus 2026: Wiz melaporkan temuan kepada tim keamanan PHP.
• 21 September 2026: PHP mengakui laporan dan mulai menyusun perbaikan terkoordinasi.
• 20 Oktober 2026: PHP memberi pemberitahuan awal akan adanya rilis keamanan kritis yang dijadwalkan 21 Oktober pukul 14.00 UTC.
• 21 Oktober 2026: Rilis perbaikan dan pengungkapan publik. Menurut ProjectDiscovery, pengenal CVE bocor dua hari sebelum rilis terencana sehingga tim PHP merilis sehari lebih awal.
• 23 Oktober 2026: PHP menerbitkan nasihat informasional tambahan terkait progres unggah sesi (dibahas di bagian mitigasi).

Pengungkapan ini juga melibatkan kolaborasi lintas industri. Wiz menyebut kerja sama dengan tim PHP, Calif, dan OpenAI untuk penemuan, koordinasi, dan verifikasi tambalan, serta dengan banyak penyedia seperti Google Cloud, Cloudflare, AWS, Microsoft, Automattic, Fastly, Akamai, Imperva, dan Vercel untuk menyiapkan panduan dan mitigasi bagi organisasi yang tidak dapat memperbarui seketika.

Solusi Utama: Perbarui PHP

Pesan tim PHP sangat tegas: tidak ada mitigasi yang lengkap, memperbarui adalah satu-satunya pilihan yang aman. Versi PHP yang memuat perbaikan kedua CVE adalah sebagai berikut.

Catatan penting terkait pembaruan:

• PHP 8.1 dan yang lebih lama tidak lagi menerima pembaruan dari proyek PHP. Namun, tim keamanan PHP menyediakan backport sumber minimal untuk PHP 7.4, 8.0, dan 8.1 bagi pihak yang membangun dari sumber atau tidak memiliki vendor LTS. Bagi pengguna distribusi Linux, periksa apakah vendor menyediakan paket dengan backport.
• Nomor versi paket distribusi bisa tampak lebih lama. Distribusi, hosting, dan paket LTS dapat memuat perbaikan dengan string versi lama. Pastikan changelog paket menyebut kedua CVE.
• PHP 8.2 akan mencapai akhir masa dukungan (EOL) pada 31 Desember 2026, sehingga rencanakan migrasi ke cabang yang masih didukung.
• Mulai ulang layanan setelah pembaruan. Memasang paket yang diperbaiki tidak mengubah worker yang sedang berjalan; biner lama tetap melayani sampai proses dimulai ulang. Restart PHP-FPM, Apache, dan LiteSpeed. Untuk kontainer, bangun ulang citra di atas basis php: yang sudah diperbaiki lalu sebarkan ulang.
• Utamakan Apache mod_php karena dinilai berisiko paling tinggi.

Mitigasi Sementara Jika Belum Dapat Memperbarui

Tim PHP menekankan bahwa langkah berikut hanya mengurangi paparan pada jalur serangan tertentu dan tidak membuat instalasi menjadi aman. Gunakan sebagai penahan sementara, bukan pengganti pembaruan.

Untuk CVE-2026-109618 (OOM corruption)

• Atur memory_limit=-1, sebaiknya dengan cara yang tidak dapat ditimpa aplikasi, misalnya melalui php_admin_value pada kolam FPM atau konfigurasi Apache. Pastikan tidak ada kolam, direktori, atau pengaturan aplikasi yang mengembalikan batas terbatas. Tim PHP mengingatkan bahwa langkah ini menghilangkan kegagalan batas memori yang dapat dikendalikan, tetapi kegagalan alokasi yang mendasarinya masih dapat mencapai jalur rentan.
• Tetapkan post_max_size yang rendah: 8M untuk aplikasi tanpa kebutuhan unggah berkas, dan 32M bila unggah berkas diperlukan. Jaga upload_max_filesize lebih kecil dari post_max_size. Pertimbangkan pula pembatasan di server web atau proksi untuk ukuran permintaan terdekode, jumlah field, jumlah bagian multipart, jumlah header, dan kedalaman nesting, termasuk untuk permintaan tanpa Content-Length yang dapat dipakai.
• Gunakan batas kontainer atau cgroup sebagai pembatas ketersediaan, dengan kebijakan yang hanya mematikan worker yang terdampak. Jangan menggantinya dengan RLIMIT_AS atau RLIMIT_DATA, sebab keduanya justru dapat memicu kegagalan alokasi yang rentan.

Untuk CVE-2026-109619 (stale global state)

• Atur session.upload_progress.enabled=0 dan mulai ulang semua worker. Terapkan melalui php.ini, kolam FPM, atau konfigurasi server yang berlaku sebelum penguraian permintaan. Jangan mengandalkan ini_set() atau .user.ini. Langkah ini memblokir jalur sesi yang telah terkonfirmasi, tetapi bukan varian lain.
• Pada PHP 8.5, atur fatal_error_backtraces=0 dan mulai ulang semua worker. Ini hanya menutup jalur backtrace fatal yang telah terkonfirmasi.
• Hapus pengaturan per-permintaan yang tidak valid atau usang yang memunculkan diagnostik sebelum inisialisasi. Menyembunyikan diagnostik lewat error_reporting, display_errors, atau operator @ tidak membantu.
• Perbaiki galat fatal dan timeout eksekusi yang dapat dijangkau penyerang, termasuk kegagalan pada callback, pemrosesan unggah atau impor, dan pembersihan.

Nasihat tambahan 23 Oktober 2026 (CVE-2026-115560)

PHP juga menerbitkan nasihat informasional yang menyarankan session.upload_progress.enabled=0 hingga rilis perbaikan reguler berikutnya, untuk melindungi dari vektor RCE yang dinilai tidak lazim terjadi. Masalah ini hanya muncul pada kombinasi konfigurasi dan kode aplikasi yang tidak biasa: aplikasi mengatur session.serialize_handler ke php_binary atau php_serialize, lalu mengubahnya ke php saat runtime dengan ini_set() sebelum session_start(), sementara progres unggah sesi masih aktif. Bila pengaturan di atas sudah diterapkan sebelumnya, tidak diperlukan tindakan lanjutan. Tim PHP menyatakan akan menerbitkan nasihat lengkap untuk CVE-2026-115560 bersama rilis berikutnya.

Mengapa Menemukan Seluruh Instalasi PHP Justru Bagian Tersulit

ProjectDiscovery menegaskan bahwa menambal adalah langkah mudah (pembaruan paket dan restart), sedangkan tantangan sebenarnya adalah menemukan seluruh runtime PHP yang ada. Pernyataan CISA yang dikutip menyebut bahwa PHP sering menjadi komponen dari perangkat lunak lain sehingga keberadaannya tidak selalu terlihat langsung.

Alur kerja yang disarankan untuk inventarisasi dan penambalan terdiri dari lima tahap:

1. Daftar semua aset: domain, rentang IP, dan alamat keluar cloud, termasuk domain yang didaftarkan agensi atau hasil akuisisi.
2. Temukan layanan web di semua port, tidak hanya 80 dan 443.
3. Tandai layanan yang menjalankan PHP dari header seperti X-Powered-By atau cookie PHPSESSID, dengan memeriksa juga path aplikasi umum.
4. Periksa versi yang diiklankan. Tersedia templat Nuclei untuk CVE-2026-109618 yang membaca versi dari header dan hanya mengirim satu permintaan GET biasa tanpa upaya eksploitasi.
5. Konfirmasi di host, tambal, mulai ulang, lalu verifikasi. Banner hanya petunjuk; sumber kebenarannya adalah host. Periksa biner PHP yang terpasang dan proses yang sedang berjalan, lalu pastikan tidak ada proses yang masih memakai pustaka PHP lama yang sudah terganti di disk.

Untuk perangkat dan aplikasi terpaket (appliance), terapkan pembaruan vendor begitu tersedia, dan selama menunggu, jaga antarmuka administrasinya tetap tidak terbuka ke internet.

Deteksi dan Respons Insiden

Karena celah ini bekerja di bawah lapisan aplikasi, log aplikasi mungkin memuat sedikit konteks. Wiz menyarankan agar pembela memperhatikan sinyal berikut selama sistem belum ditambal:

• Permintaan multipart yang tidak biasa, diikuti galat batas memori atau respons HTTP 500 berulang.
• Cookie PHPSESSID pada respons yang tidak wajar besar atau tidak berbentuk normal.
• Pergantian proses worker PHP yang tidak dapat dijelaskan.

Sinyal ini membantu penyelidikan, tetapi pembaruan PHP tetap satu-satunya remediasi yang lengkap. Ekosistem juga menyediakan sumber daya komunitas, antara lain aturan WAF dari Cloudflare, deteksi Zeek/Suricata dari Corelight, aturan Elastic untuk aktivitas pascaeksploitasi, serta panduan pembaruan dari Hostinger dan Laravel.

Jika server yang terdampak pernah dapat dijangkau dari internet sebelum ditambal, ProjectDiscovery menyarankan untuk mengasumsikan rahasia di memori server tersebut telah terekspos. Langkah yang dianjurkan:

• Ganti kata sandi basis data, kunci API, dan kunci penandatangan sesi.
• Periksa server dari tanda-tanda penyusupan.
• Tinjau akses dan log pada sistem yang terhubung dengannya.

Waspadai Exploit Palsu dan Penipuan

Setiap kali celah besar diumumkan, bermunculan repositori yang mengaku berisi proof-of-concept (PoC). JFrog menemukan PoC palsu di GitHub yang disebarkan sebagai kelakar. Prinsipnya: jangan menjalankan PoC dari sumber tidak dikenal di mesin kerja atau server produksi. Bila memang perlu untuk riset, jalankan hanya di lingkungan laboratorium yang terisolasi. Bagi mahasiswa yang tertarik mempelajari keamanan, pembelajaran paling aman adalah melalui nasihat resmi (advisory), analisis teknis dari peneliti, dan lingkungan latihan yang sah.

Rekomendasi bagi Institusi Pendidikan dan Pengelola Sistem Informasi Kampus

Perguruan tinggi umumnya mengoperasikan banyak sistem berbasis PHP, mulai dari situs program studi, portal akademik, repositori, jurnal elektronik, hingga platform pembelajaran daring. Berdasarkan temuan di atas, berikut rekomendasi umum yang dapat dipertimbangkan.

1. Lakukan inventarisasi menyeluruh. Catat semua server, mesin virtual, kontainer, dan layanan hosting yang menjalankan PHP, termasuk situs lama, subdomain unit, dan aplikasi buatan mahasiswa atau kerja sama pihak ketiga.
2. Prioritaskan sistem yang terhubung ke internet, terutama yang berjalan dengan Apache mod_php dan panel administrasi.
3. Perbarui dan restart, lalu verifikasi bahwa proses yang berjalan benar-benar memakai versi yang sudah diperbaiki.
4. Koordinasikan dengan penyedia hosting dan vendor. Tanyakan kepastian penerapan tambalan, terutama pada hosting bersama, panel kontrol, dan aplikasi pihak ketiga.
5. Terapkan mitigasi sementara bagi sistem yang belum dapat diperbarui, sambil membatasi akses publik ke antarmuka administrasi.
6. Rotasi kredensial pada server yang sempat terpapar sebelum ditambal, dan siapkan prosedur tanggap insiden.
7. Rencanakan migrasi dari versi PHP yang sudah tidak didukung (8.1 dan sebelumnya), serta persiapkan peralihan dari PHP 8.2 sebelum 31 Desember 2026.
8. Jadikan insiden ini bahan pembelajaran. Studi kasus PHP2Shell relevan untuk mata kuliah keamanan informasi, rekayasa perangkat lunak, sistem operasi, dan etika profesi.

Pelajaran bagi Pengembang

Walaupun PHP2Shell adalah celah di mesin inti, ada beberapa praktik yang relevan bagi pengembang aplikasi.

• Bahasa pemrograman dan runtime adalah bagian dari permukaan serangan. Kode aplikasi yang bersih tidak menjamin keamanan jika fondasinya rentan. Jadikan pembaruan runtime bagian dari siklus pemeliharaan rutin.
• Kelola konfigurasi dengan disiplin. Konfigurasi seperti memory_limit, post_max_size, dan pengaturan sesi memengaruhi paparan. Terapkan pada tingkat yang tidak dapat ditimpa aplikasi bila memungkinkan.
• Perbaiki kegagalan fatal yang dapat dijangkau pengguna. Galat fatal dan timeout pada alur unggah atau impor, bukan sekadar masalah ketersediaan, dapat menjadi pintu masuk bagi kelas serangan seperti ini.
• Bangun ulang kontainer secara berkala. Citra yang tidak dibangun ulang akan terus memakai versi PHP lama.
• Terapkan pertahanan berlapis, seperti WAF, pembatasan ukuran dan jumlah bagian permintaan, isolasi proses, pembatasan hak akses, dan pemantauan.

Penutup

PHP2Shell adalah pengingat bahwa fondasi perangkat lunak yang kita pakai setiap hari dapat menyimpan kelemahan selama bertahun-tahun, dan bahwa lanskap ancaman sedang bergeser seiring kemajuan AI. Dua CVE kritis, CVE-2026-109618 dan CVE-2026-109619, menunjukkan bagaimana kegagalan memori yang tampak sepele dapat berujung pada eksekusi kode jarak jauh tanpa autentikasi pada skala internet.

Pesan utamanya sederhana: perbarui PHP ke versi yang sudah diperbaiki (8.2.35, 8.3.36, 8.4.27, atau 8.5.12), mulai ulang layanan, dan pastikan seluruh instalasi PHP Anda terinventarisasi. Untuk sistem yang tidak dapat segera ditambal, batasi akses publik dan terapkan mitigasi sementara sambil tetap menyadari bahwa itu bukan solusi tuntas.

Di sisi lain, kejadian ini juga menunjukkan potensi positif kolaborasi lintas organisasi dan pemanfaatan AI untuk pertahanan. Bagi komunitas informatika, ini menjadi kesempatan untuk memperkuat budaya keamanan: mengelola aset dengan baik, memperbarui secara disiplin, dan terus belajar secara etis dan bertanggung jawab.

Referensi

1. Wiz Research. "PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet." Wiz Blog, 21 Oktober 2026. https://www.wiz.io/blog/php2shell-php-rce
2. ProjectDiscovery. "PHP2Shell: finding and patching affected PHP." ProjectDiscovery Research, 21 Oktober 2026. https://projectdiscovery.io/research/php2shell
3. PHP.net. "Security advisory: Critical remote code execution vulnerabilities, update now" dan "Informational advisory: Session upload progress." News Archive 2026. https://www.php.net/archive/2026.php#2026-10-21-5
4. Advisori GitHub untuk CVE-2026-109618 (GHSA-w8hw-w9fx-j79w) dan CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp), sebagaimana ditautkan pada pengumuman PHP.

Catatan redaksi: informasi dalam artikel ini mengacu pada sumber-sumber di atas per 24 Oktober 2026. Situasi dapat berkembang, termasuk rilis tambalan lanjutan dan nasihat baru, sehingga pembaca disarankan memeriksa pengumuman resmi PHP dan vendor masing-masing.