PHP2Shell: Dua Celah Kritis PHP Mengancam Jutaan Situs
Irfan Mulyana
October 22, 2026 3:57 am
.
9 min read
Verdict: Update PHP Bukan Lagi Pilihan
TL;DR: Pada 21 Oktober 2026, PHP merilis update keamanan darurat untuk dua celah kritis, CVE-2026-109618 dan CVE-2026-109619, yang dijuluki PHP2Shell. Keduanya berskor CVSS 9.2 dan memungkinkan penyerang tanpa login menjalankan perintah di server web mana pun yang menjalankan PHP. Versi perbaikan yang aman adalah PHP 8.5.12, 8.4.27, 8.3.36, dan 8.2.35. National Cyber Security Centre (NCSC) Inggris mendesak semua organisasi bertindak segera, dan menyarankan mempertimbangkan membawa sistem offline bila update tidak bisa dilakukan dengan cepat. Setiap situs berbasis WordPress, WooCommerce, Laravel, dan aplikasi PHP lain perlu memeriksa versi PHP di servernya hari ini juga.
Apa yang Terjadi: Patch Darurat untuk Mesin Web Dunia
PHP Foundation mengumumkan pada 20 Oktober 2026 bahwa dua kerentanan kritis ditemukan di mesin PHP, lalu merilis versi perbaikan pada Rabu, 21 Oktober 2026 pukul 14:00 UTC. Masalahnya, jendela waktu untuk bersantai hampir tidak ada. Cloudflare melaporkan trafik serangan awal pada 07:43 UTC di hari yang sama, beberapa jam sebelum patch tersedia. Perangkat eksploitasi dan tulisan teknis mendalam tentang kedua celah ini juga sudah beredar publik, sehingga peneliti keamanan memperkirakan eksploitasi massal terjadi dalam waktu sangat dekat.
Sejumlah situs di Belanda memilih offline sebagai langkah pencegahan pada 21 Oktober, termasuk Tweakers, situs parlemen Belanda Tweede Kamer, situs NCSC Belanda sendiri, dan Security.NL. Di Inggris, NCSC menerbitkan peringatan resmi yang mendorong organisasi untuk segera mengambil tindakan mitigasi. Nada peringatannya tidak main-main: bila remediasi langsung tidak memungkinkan, organisasi sebaiknya mempertimbangkan mematikan sistem sampai bisa dimitigasi sepenuhnya.
Kedua celah ini ditemukan melalui proses pengungkapan terkoordinasi yang berjalan sejak Agustus 2026. Penemunya adalah Ryan Austin dari Calif dan tim Wiz Research, dengan bantuan model AI dari OpenAI dan Google untuk menemukan serta memverifikasi jalur serangannya. Artinya, celah yang bersembunyi di kode PHP selama lebih dari satu dekade akhirnya terungkap berkat kombinasi riset manusia dan kecerdasan buatan. Rincian latar penemuannya bisa dibaca pada liputan Computer Weekly.
Dua Celah Use-After-Free di Jantung PHP
Kedua CVE ini berakar pada kelas bug yang sama, yaitu use-after-free. Sederhananya, ketika sebuah request memicu error fatal, umumnya kondisi out-of-memory saat request melewati batas memory_limit, proses bersih-bersih internal PHP terputus di tengah jalan. Request berikutnya, atau worker yang dipakai ulang, kemudian memperlakukan memori yang sudah dibebaskan seolah masih berisi data yang sah. Dari titik itulah penyerang bisa menyusupkan data versinya sendiri dan mengarahkan eksekusi ke perintah yang diinginkan.
| CVE | Kelas Kerentanan | Dampak |
|---|---|---|
| CVE-2026-109618 | Use-after-free pada unserializer upload progress sesi | Kebocoran memori jarak jauh dan eksekusi kode jarak jauh (RCE) |
| CVE-2026-109619 | Use-after-free pada backtrace error fatal, kebingungan tipe di OPcache | Eksekusi kode jarak jauh (RCE) |
Rincian resmi dari NCSC menjelaskan perbedaan mekanismenya. Pada CVE-2026-109618, penanganan out-of-memory dapat menyela PHP ketika data internal request baru terisi sebagian, dan proses pembersihan sesudahnya memperlakukan data yang tidak valid itu sebagai data sah. Pada CVE-2026-109619, status internal milik sebuah request dapat bertahan setelah memori pendukungnya dibebaskan, lalu dipakai oleh request berikutnya pada worker yang sama sebelum inisialisasi normal sempat meresetnya.
Kode yang rentan ternyata berasal dari PHP 5.4.0 yang dirilis pada 2012, dan konfigurasi default ikut rentan. Apache dengan mod_php dan PHP-FPM sama-sama terdampak. Risiko dinilai paling tinggi pada Apache mod_php karena serangan yang terdemonstrasi berjalan sebelum kode aplikasi situs sempat dieksekusi sama sekali. Analisis teknis lengkap beserta langkah mitigasinya dirangkum oleh Sansec.
Siapa Saja yang Terdampak
Jawaban singkatnya: hampir semua yang menjalankan PHP. NCSC menyatakan organisasi yang menggunakan versi PHP berapa pun terdampak dan sangat dianjurkan memperbarui ke versi perbaikan terbaru. PHP sendiri menopang porsi web yang sangat besar, sekitar 24 juta website menurut BuiltWith dan sekitar tiga perempat situs yang bahasa pemrogramannya dapat diidentifikasi menurut W3Techs. Telemetri Unit 42 dari Palo Alto Networks mengidentifikasi lebih dari 22,6 juta instance PHP yang terekspos dan berpotensi rentan.
Karena celahnya berada di mesin PHP, aplikasi populer ikut terekspos meskipun kode aplikasinya sendiri bersih. Calif mendemonstrasikan eksekusi kode tanpa login pada WordPress 7.1.2, WooCommerce, Magento 2.4.9, Drupal 11.4.3, Joomla 6.1.4, MediaWiki 1.46.2, Roundcube 1.7.4, phpMyAdmin 5.2.3, Nextcloud 35.0.1, Laravel 13.11, Symfony 8.1, dan WHMCS. Semua mode eksekusi PHP yang melayani request web berisiko, termasuk PHP-FPM, mod_php, php-cgi, FrankenPHP, dan LiteSpeed.
Kelompok yang paling terjepit adalah pengguna versi lama. PHP 8.1 dan yang lebih lama tidak lagi menerima update dari proyek PHP, sehingga tidak ada perbaikan resmi untuk kelompok ini. Sebagai jalan keluar darurat, tim keamanan PHP menyediakan backport sumber minimal untuk PHP 7.4, 8.0, dan 8.1 bagi yang membangun PHP dari kode sumber, sementara sejumlah distribusi Linux dan vendor dukungan jangka panjang menyediakan perbaikan backport versi mereka. Situasi ini mirip pelajaran pada insiden cloud tanpa guardrail: sistem yang dibiarkan tua dan tanpa pengawasan adalah yang paling dulu membayar mahal.
Kenapa Kasus Ini Disebut Salah Satu yang Terbesar
Ada empat alasan mengapa komunitas keamanan memperlakukan PHP2Shell sebagai peristiwa besar. Pertama, skor keparahannya 9.2 dari 10 pada skala CVSS v4.0 untuk kedua celah, dan eksploitasinya tidak membutuhkan kredensial apa pun. Pemicunya adalah request multipart/form-data biasa, format yang sama yang dipakai browser untuk mengunggah berkas, dan request itu diproses PHP sebelum kode aplikasi berjalan.
Kedua, CVE-2026-109618 membawa bonus yang mengerikan: kebocoran memori yang mengingatkan pada Heartbleed. Handler upload progress PHP dapat mengembalikan memori worker yang sudah dibebaskan kepada klien di dalam cookie PHPSESSID. Isi memori itu bisa mencakup kata sandi, token sesi, kunci API, sampai kunci privat TLS milik request lain. Mekanisme ini berjalan sebelum kode aplikasi, sehingga tetap bekerja bahkan pada aplikasi yang tidak pernah memanggil fungsi session_start().
Ketiga, skala dan kecepatannya. Peneliti keamanan Kevin Beaumont menyebut situasi ini akan memicu gelombang insiden dan menilainya sebagai salah satu kerentanan terbesar dalam beberapa tahun terakhir, seperti dikutip Help Net Security. Cloudflare sudah menyebarkan aturan WAF untuk vektor eksploitasi yang diketahui ke seluruh pelanggan, termasuk paket gratis. Keempat, ada ekor panjang yang sulit dibereskan: jutaan instalasi PHP tertanam di perangkat, appliance, dan aplikasi warisan yang tidak pernah diperbarui, persis seperti kekhawatiran yang disuarakan para praktisi forensik sejak hari pertama.
Cara Mengecek Versi PHP di Server dan Hosting
Langkah pertama mitigasi adalah mengetahui versi PHP yang sedang berjalan. Ada beberapa cara cepat:
- Terminal server atau VPS: jalankan perintah
php -v. Versi yang tampil adalah versi CLI, dan pada kebanyakan server nilainya sama dengan versi yang melayani web. - WordPress: masuk ke Dasbor, buka menu Kesehatan Situs atau Site Health, pilih tab Info, lalu lihat bagian Server. Versi PHP tercantum di sana.
- Panel hosting: di cPanel, versi PHP diatur melalui menu MultiPHP Manager atau Select PHP Version. Panel lain seperti Plesk dan DirectAdmin menyediakan menu setara di pengaturan domain.
- Berkas phpinfo sementara: buat berkas berisi fungsi phpinfo() lalu akses melalui browser. Cara ini akurat, tetapi berkasnya wajib dihapus segera setelah selesai karena isinya membocorkan detail server.
Bandingkan hasilnya dengan daftar versi aman: 8.2.35, 8.3.36, 8.4.27, 8.5.12, atau yang lebih baru dari masing-masing cabang rilis. Bila versi yang berjalan lebih rendah, server tersebut rentan. Bagi yang mengelola layanan self-hosted di VPS, misalnya mengikuti panduan setup n8n self-hosted di VPS, pemeriksaan ini berlaku juga untuk container dan image Docker yang membundel PHP di dalamnya.
Langkah Mitigasi: Update Sekarang atau Offline Dulu
Perbaikan sejati hanya satu: memperbarui PHP ke versi yang sudah ditambal. Celah ini berada di mesin PHP, jadi tidak ada perubahan kode aplikasi, plugin, atau tema yang bisa menutupnya. Bila server dikelola penyedia hosting, hubungi mereka dan minta update diterapkan segera. Perlu dicatat, repositori Remi yang populer di server berbasis RHEL belum menyediakan update pada hari rilis, sehingga pengguna repositori tersebut disarankan beralih ke paket distribusi atau membangun PHP dari sumber.
Sembari menunggu update, ada mitigasi sementara yang bersifat parsial dan hanya membeli waktu:
- Blokir request multipart/form-data di web server. Semua pemicu yang diketahui memakai format ini. Aturan penolakan bisa dipasang di nginx maupun Apache. Konsekuensinya, fitur upload berkas ikut rusak, jadi uji kembali fungsi toko dan formulir setelah aturan dipasang, lalu cabut aturan begitu PHP selesai diperbarui.
- Atur ulang dua opsi PHP. Calif menerbitkan mitigasi parsial berupa menonaktifkan session.upload_progress.enabled dan menghapus batas memori dengan memory_limit = -1. Developer inti PHP Gina Peter Banyard mengingatkan langkah pertama saja tidak cukup. Nilai memory_limit -1 juga berisiko menghabiskan memori server, jadi pantau pemakaian memori dan kembalikan batas normal setelah update.
- Aktifkan mode baca-saja. Tolak semua method selain GET dan HEAD dengan respons 503. Pengunjung tetap bisa menjelajah katalog, tetapi tidak bisa login atau bertransaksi.
- Manfaatkan WAF. Pengguna Cloudflare sudah dilindungi aturan awal untuk vektor yang diketahui, termasuk pelanggan gratis. Perlindungan WAF tetap bukan pengganti update.
Bila update dan mitigasi sementara tidak bisa diterapkan dengan cukup cepat, NCSC menyarankan mempertimbangkan membawa sistem offline sampai bisa dimitigasi sepenuhnya, karena mode maintenance bawaan aplikasi tidak membantu: PHP memproses request sebelum aplikasi memeriksa status maintenance. NCSC juga menekankan pemeriksaan tanda kompromi dan backdoor sebelum melakukan upgrade, terutama pada sistem yang sudah lama terekspos. Prinsip dasarnya sejalan dengan praktik keamanan website pada umumnya: permukaan serangan yang terlihat publik harus selalu diasumsikan sedang dipindai penyerang.
Checklist Khusus Pengguna WordPress dan Shared Hosting
Bagi pemilik situs WordPress di shared hosting, kendali atas versi PHP biasanya berada di tangan provider, tetapi bukan berarti hanya bisa menunggu. Berikut langkah yang bisa dilakukan hari ini:
- Cek versi PHP lewat Site Health. Bila belum aman, buka tiket ke provider hosting dan minta jadwal update yang jelas. Provider besar umumnya bergerak cepat pada kasus sebesar ini, seperti dibahas pada profil Hostinger.
- Buat backup penuh situs dan basis data sebelum ada perubahan versi PHP.
- Setelah versi naik, uji fungsi penting: login, formulir, checkout, dan plugin utama. Lompatan dari PHP 7.4 atau 8.0 ke 8.2 ke atas bisa memunculkan peringatan kompatibilitas pada plugin lama, tetapi bertahan di versi rentan jauh lebih berbahaya.
- Aktifkan autentikasi dua faktor untuk akun admin, dan pertimbangkan rotasi kata sandi serta kunci API. Langkah ini penting karena CVE-2026-109618 berpotensi membocorkan kredensial dari memori server, serupa risiko yang dibahas pada artikel keamanan AI agent dan risiko akses sistem.
- Pantau pengumuman resmi provider dan kanal PHP selama beberapa hari ke depan untuk update lanjutan.
Kesimpulan Final: Cek, Update, Verifikasi
PHP2Shell adalah pengingat keras bahwa risiko terbesar sebuah situs kadang bukan berasal dari plugin atau tema, melainkan dari bahasa pemrograman yang menjalankan semuanya. Dua celah use-after-free yang bersembunyi sejak 2012 kini memiliki patch, perangkat eksploitasi yang publik, dan trafik serangan yang sudah terdeteksi. Kombinasi itu membuat penundaan menjadi pilihan paling mahal.
Tindakan yang perlu dilakukan hari ini sederhana dan berurutan: cek versi PHP, perbarui ke 8.2.35, 8.3.36, 8.4.27, atau 8.5.12, pasang mitigasi sementara bila update harus menunggu, lalu verifikasi dan pantau tanda kompromi. Bagikan artikel ini kepada rekan yang mengelola situs berbasis PHP, karena dalam kasus seperti ini, server tetangga yang belum ditambal ikut menentukan keamanan ekosistem web secara keseluruhan.