BSSN Peringatkan Celah Kritis PHP2Shell, Pemilik Website Segera Update

---

Ringkasan: BSSN memperingatkan dua celah kritis PHP bernama PHP2Shell (CVE-2026-109618 dan CVE-2026-109619). Keduanya bernilai 9,2 dari 10 dan bisa memicu eksekusi kode jarak jauh tanpa login. Perbaikan resmi sudah rilis sejak 21 Oktober 2026. Update WordPress, plugin, atau tema tidak menutup celah ini. Yang harus diperbarui adalah PHP di server.

Apa itu PHP2Shell dan mengapa BSSN memperingatkannya?

PHP2Shell adalah sebutan untuk dua kerentanan kritis di inti bahasa PHP, yaitu CVE-2026-109618 dan CVE-2026-109619. Penyerang bisa menjalankan kode di server hanya lewat permintaan HTTP yang dirancang khusus, tanpa login. Akibatnya bisa berupa gangguan layanan sampai pengambilalihan sistem. BSSN menerbitkan peringatannya pada Kamis, 22 Oktober 2026.

Kenapa pemilik website perlu peduli? PHP menjalankan sebagian besar situs dinamis, termasuk WordPress, Drupal, Joomla, dan MediaWiki. Media yang mengutip BSSN menyebut keempat CMS itu dalam pemberitaan peringatan ini. Celahnya ada di mesin PHP, bukan di CMS, jadi login yang kuat atau plugin keamanan tidak menutupnya.

Pengelola situs sering berpikir, “Saya sudah update WordPress, berarti aman.” Dalam kasus ini keliru. WordPress, plugin, dan tema berada di atas PHP. Celahnya ada di bawah semuanya.

Kronologi PHP2Shell: dari temuan Agustus sampai peringatan BSSN

Peristiwa ini bergerak cepat. Perbedaan beberapa jam menentukan siapa yang sempat menambal sebelum diserang. Tabel berikut merangkum urutan kejadian dari sumber yang bisa dicek.

Tanggal	Peristiwa	Sumber
Agustus 2026	Peneliti melaporkan kerentanan ini	Pemberitaan media nasional soal peringatan BSSN
17 Oktober 2026	Amazon Threat Intelligence mencatat percobaan eksploitasi di telemetri MadPot, empat hari sebelum pengumuman	Wikipedia (PHP2Shell)
20 Oktober 2026	Keberadaan celah diumumkan publik. Detail teknis dan kode eksploit beredar, sehingga PHP mempercepat rilis patch satu hari	Wikipedia; iSIDefense
21 Oktober 2026, 07.43 UTC	Cloudflare melaporkan percobaan serangan pertama, lebih dari enam jam sebelum patch rilis	Black Kite; TuxCare
21 Oktober 2026, 14.00 UTC	PHP merilis 8.5.12, 8.4.27, 8.3.36, dan 8.2.35	GitHub php-src
21 Oktober 2026	CISA dan UK NCSC menerbitkan peringatan. CISA belum mengamati eksploitasi saat peringatan terbit	Black Kite; Tenable
22 Oktober 2026	BSSN menerbitkan peringatan. watchTowr melaporkan percobaan eksploitasi aktif	Kompas.com; Katadata; Black Kite

Komdigi ikut menyebarluaskan peringatan BSSN. Juru bicaranya, Farida, menyatakan penanganan teknis insiden siber berada dalam kewenangan BSSN, dan kedua lembaga berkoordinasi. Pernyataan itu dimuat Media Kompeten dengan merujuk KompasTekno.

Dua celah, dua mekanisme: apa bedanya?

Keduanya berkaitan dengan pengelolaan memori, tetapi pemicunya berbeda. Perbedaan ini menjelaskan mengapa PHP menyatakan tidak ada konfigurasi yang menutup celah sepenuhnya.

	CVE-2026-109618	CVE-2026-109619
Jenis	Eksekusi kode jarak jauh lewat korupsi memori saat PHP kehabisan memori (out-of-memory)	Eksekusi kode jarak jauh lewat state global yang basi (stale global state)
Pemicu	Permintaan HTTP yang dirancang khusus	Permintaan HTTP yang dirancang khusus
Autentikasi	Tidak diperlukan	Tidak diperlukan
Skor	9,2 (CVSS v4.0)	9,2 (CVSS v4.0)

Sumber: watchTowr (FAQ PHP2Shell), Tenable, dan Phoenix Security. Skor 9,2 berasal dari tim keamanan PHP.

Kata “kritis” di sini punya arti teknis. Penyerang tidak perlu kredensial, tidak perlu akun, dan tidak perlu mengelabui admin. Server yang menerima permintaan web sudah cukup menjadi sasaran.

Versi PHP mana yang terdampak?

Semua rilis PHP sebelum 8.5.12, 8.4.27, 8.3.36, dan 8.2.35 dinyatakan rentan. Menurut php.net, setiap instalasi yang melayani permintaan web berisiko. Itu mencakup PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, dan LiteSpeed.

Cabang PHP	Versi rentan	Versi perbaikan
8.5	Sebelum 8.5.12	8.5.12
8.4	Sebelum 8.4.27	8.4.27
8.3	Sebelum 8.3.36	8.3.36
8.2	Sebelum 8.2.35	8.2.35
8.1 dan lebih lama	Terdampak, tanpa patch resmi	Tidak ada. Migrasi atau pakai patch pihak ketiga

Catatan penting soal 8.2: rilis GitHub PHP menyebut cabang ini berakhir masa dukungannya pada 31 Desember 2026. Setelah tanggal itu, tidak ada lagi perbaikan keamanan untuk 8.2.

Ada perbedaan antarmedia. Satu laporan yang mengutip BSSN menyebut PHP 8.2 sampai 8.5 sebagai versi berpotensi terdampak. Laporan lain menyebut PHP 8.1 dan yang lebih lama. Keduanya konsisten dengan advisory PHP. Cabang 8.2 sampai 8.5 punya patch, sedangkan cabang lama tetap rentan tetapi tidak mendapat patch resmi. watchTowr bahkan mengonfirmasi cabang tak lagi didukung, termasuk PHP 5, ikut terdampak. Perkiraan Mallory yang dikutip TuxCare menyebut sekitar 884.000 host yang terhubung internet masih memakai versi seperti itu.

Mengapa ini relevan bagi startup dan UMKM digital?

Banyak startup dan toko online kecil menjalankan web di hosting bersama, VPS murah, atau container yang tidak dipantau tiap hari. Di sinilah risikonya. Pemilik tidak merasa “mengelola server”, padahal PHP di bawahnya tetap harus dipatuhi pembaruannya.

Dampak bisnisnya konkret. Situs yang diambil alih bisa menampilkan konten sisipan, mengarahkan pengunjung ke penipuan, atau mencuri data pelanggan. BSSN menyebut data berpotensi diakses, diubah, atau dihapus. Untuk bisnis yang menerima pembayaran, kebocoran semacam itu merusak kepercayaan lebih cepat daripada biaya patch.

Ada tiga alasan insiden ini penting bagi pemilik bisnis digital:

• Waktu reaksi sangat pendek. Serangan pertama tercatat lebih dari enam jam sebelum patch rilis.
• Tanggung jawab sering kabur. Di hosting terkelola, penyedia yang menambal. Di VPS, pemilik sendiri.
• Biaya pencegahan jauh lebih kecil dari biaya pemulihan. Memperbarui PHP biasanya tidak memakan waktu lama. Memulihkan situs yang disusupi bisa berhari-hari.

Pemilik usaha yang menerima transaksi online, misalnya yang dibahas dalam tren AI fintech untuk UMKM Indonesia, punya alasan ekstra untuk segera memeriksa server. Data pelanggan dan transaksi adalah aset yang paling mahal bila bocor.

Disiplin operasional juga menjadi sorotan investor. Ulasan tentang investor startup 2026 yang menolak model bakar uang menunjukkan arah pasar yang menuntut efisiensi. Insiden keamanan yang bisa dicegah dengan satu pembaruan jelas bertentangan dengan efisiensi itu.

Apakah PHP2Shell sudah dieksploitasi? Status per 24 Oktober 2026

Ya, ada percobaan eksploitasi yang dilaporkan beberapa pihak, tetapi tingkat keberhasilannya belum jelas. Gambaran berikut disusun dari laporan berbeda, dan sebagian berbeda penilaian.

• Amazon: menyebut PHP2Shell kini mengalami percobaan eksploitasi luas di alam liar. Amazon juga menyatakan belum jelas apakah percobaan 21 Oktober akan berhasil di sistem nyata.
• Cloudflare: CEO Matthew Prince, seperti dikutip SecurityWeek, menyebut ribuan percobaan dalam sepuluh jam sebelum pengumuman dan jutaan setelahnya. Cloudflare juga melihat penyerang mengubah payload untuk menghindari aturan WAF-nya.
• watchTowr: mereproduksi kedua celah dan mencatat percobaan eksploitasi di honeypot pada hari rilis.
• CISA: menyatakan belum mengamati eksploitasi saat peringatan 21 Oktober terbit. Menurut laporan Witscode per 23 Oktober, kedua CVE belum tercantum di katalog Known Exploited Vulnerabilities (KEV). Statusnya bisa berubah, jadi cek langsung di situs CISA.

Sebagian analis menilai eksploit publik tidak selalu berhasil di instalasi PHP bawaan, dan banyak yang butuh celah kedua seperti local file inclusion. Penilaian ini berasal dari satu tulisan analis di DEV Community dan belum dikonfirmasi PHP atau BSSN.

Kesimpulan praktisnya sama dengan saran Witscode: tambal seolah eksploit yang berfungsi sudah ada. Menunggu kepastian justru memperpanjang waktu terpapar.

Cara cek dan update PHP: langkah demi langkah

Cara memperbaiki PHP2Shell: 1) cek versi PHP, 2) update ke versi perbaikan di cabang yang sama, 3) restart layanan PHP, 4) verifikasi hasilnya. Rinciannya berikut.

1. Cek versi PHP yang aktif. Di server jalankan php -v. Untuk Docker Compose, jalankan docker compose exec php php -v (ganti php dengan nama layanan Anda). Ingat bahwa PHP untuk web (FPM) bisa berbeda dari PHP di command line.
2. Cocokkan dengan tabel versi. Jika versi Anda di bawah 8.5.12, 8.4.27, 8.3.36, atau 8.2.35, anggap rentan.
3. Cek patch backport distro. Distribusi Linux sering menambal tanpa menaikkan nomor versi. Periksa catatan perubahan paket untuk nama CVE-nya. Contohnya apt changelog php8.3-fpm di Debian/Ubuntu atau rpm -q –changelog php di keluarga RHEL, lalu cari “CVE-2026-109618”.
4. Update ke versi perbaikan di cabang yang sama. Pakai paket resmi dari penyedia server Anda. Hindari lompat cabang tanpa uji, karena bisa merusak plugin atau aplikasi.
5. Restart layanan terkait. BSSN menyarankan restart PHP-FPM, Apache mod_php, atau php-cgi. Tanpa restart, proses lama tetap memakai interpreter lama.
6. Rebuild container jika memakai Docker. Tarik image terbaru atau bangun ulang dari base image yang sudah dipatch, lalu deploy ulang.
7. Verifikasi. Jalankan php -v lagi dan pastikan versi baru terpakai di proses web, bukan hanya di terminal.
8. Catat tanggal dan versi. Dokumentasi sederhana memudahkan audit bila ada insiden.

Jika Anda memakai hosting terkelola, langkah 1 sampai 7 biasanya tugas penyedia. Tetap tanyakan statusnya secara tertulis.

7 skenario hosting: siapa yang harus menambal?

Kewajiban menambal bergantung pada jenis hosting. Tabel ini merangkum pernyataan yang dipublikasikan pada 21 Oktober 2026. Status tiap penyedia bisa berubah, jadi konfirmasi langsung ke penyedia Anda.

#	Skenario	Siapa yang menambal	Catatan	Sumber
1	Situs di platform milik Automattic	Automattic	Perusahaan di balik WordPress menyatakan situs di platformnya sudah terlindungi	Cybernews
2	GoDaddy Managed Hosting for WordPress	GoDaddy	Semua versi PHP sudah dipatch. Web Hosting dan Windows Hosting masih menunggu paket vendor	Brandefense
3	VPS atau server sendiri	Pemilik server	GoDaddy menyerahkan pembaruan VPS kepada pelanggan. Prinsip yang sama berlaku di VPS penyedia lain	Brandefense
4	Container Docker	Pemilik, via image baru	Image ServerSideUp terbit sekitar 4 jam 20 menit setelah php.net merilis sumber	GitHub ServerSideUp
5	Platform PaaS (Heroku)	Penyedia, lalu pemilik rebuild	Heroku menerbitkan PHP 8.5.12, 8.4.27, 8.3.36, dan 8.2.35	Dokumentasi Sevalla
6	Situs di balik Cloudflare	Tidak ada, WAF hanya penyangga	Aturan WAF tersedia untuk semua paket, tetapi Cloudflare menyebutnya stopgap	Tenable; The Hacker News
7	Server PHP 8.1 ke bawah	Pemilik	Tidak ada patch resmi. Opsi: migrasi atau patch pihak ketiga seperti TuxCare	TuxCare

Poin 6 sering disalahpahami. Aturan WAF hanya melihat lalu lintas yang lewat Cloudflare. Seperti disorot mySites.guru dalam laporan Martin Cid, perlindungan itu baru berguna bila server menolak akses langsung ke alamat IP-nya. Cloudflare juga melihat penyerang mengubah payload agar lolos dari aturan.

Untuk pemilik yang masih meraba arsitektur sistem, artikel tentang startup yang menghemat biaya dengan agentic AI membahas otomasi operasional. Pemantauan versi dan patch adalah salah satu pekerjaan rutin yang cocok diotomasi.

Jika belum bisa update: langkah sementara yang masuk akal

PHP menyatakan tidak ada mitigasi lengkap, sehingga memperbarui adalah satu-satunya pilihan yang aman. Langkah sementara hanya mengurangi risiko selama Anda menunggu patch tersedia. Ia bukan pengganti update.

Untuk situs yang belum bisa menambal, BSSN menyarankan pembatasan akses jaringan ke sistem terdampak. Dalam laporan yang mengutip BSSN, pembatasan itu sejalan dengan anjuran National Cyber Security Centre Inggris. Opsinya mencakup pembatasan akses atau penonaktifan sementara layanan yang rentan. Ringkasan iSIDefense menyebut FBI, UK NCSC, dan CERT-EU menyarankan hal serupa. Sistem yang tidak bisa ditambal segera sebaiknya dimatikan sampai perbaikan terpasang.

Beberapa langkah tambahan yang disebut para penyedia dan analis:

• Aktifkan WAF (Cloudflare, AWS WAF, dan sejenisnya) sebagai lapisan tambahan, bukan sebagai solusi.
• Batasi akses langsung ke IP server supaya lalu lintas hanya lewat WAF.
• Pantau log akses untuk permintaan aneh atau lonjakan lalu lintas.

Dokumentasi Sevalla juga memuat pengaturan PHP interim, seperti menonaktifkan session.upload_progress.enabled dan fatal_error_backtraces. Dokumen itu sendiri menegaskan bahwa pengaturan tersebut mempersulit serangan tetapi tidak memperbaikinya sepenuhnya. Beberapa opsi punya efek samping, misalnya fitur progres unggah sesi berhenti bekerja. Anggap ini jembatan darurat saja.

Setelah menambal: apa yang perlu diperiksa?

Karena percobaan eksploitasi sudah terjadi sebelum patch rilis, menambal tidak otomatis berarti situs bersih. Bagian ini adalah praktik keamanan umum, bukan temuan khusus PHP2Shell. Adaptasikan dengan konteks server Anda.

• Periksa file baru atau berubah. Cari file PHP yang tidak Anda kenal di direktori unggahan dan direktori web.
• Tinjau log akses dan error untuk periode 17 sampai 24 Oktober 2026, terutama permintaan yang aneh atau memicu kehabisan memori.
• Ganti kredensial (database, panel hosting, kunci API) bila ada tanda kompromi.
• Pulihkan dari cadangan bersih jika menemukan bukti penyusupan, lalu tambal sebelum menyalakan kembali.
• Libatkan pihak profesional. Untuk situs yang menyimpan data pelanggan, konsultasikan dengan engineer keamanan atau penyedia hosting.

Pemilik bisnis yang baru membangun fondasi digitalnya bisa membaca cara menghindari keputusan teknologi berisiko untuk startup pemula. Prinsip dasarnya sama: risiko yang diketahui harus punya pemilik dan batas waktu penanganan.

Apa yang tidak perlu dilakukan

Tidak semua langkah populer berguna di kasus ini. Tiga yang sering muncul:

• Update plugin WordPress. Tim WordPress menyatakan tidak ada pembaruan WordPress yang direncanakan, karena celahnya ada di PHP, bukan di tema atau plugin. Update WordPress tidak membantu.
• Panik migrasi CMS. Analis di DEV Community menilai migrasi platform tidak perlu bila patch PHP tersedia. Yang dibutuhkan adalah interpreter PHP yang sudah diperbarui.
• Mengandalkan login yang kuat. Mengandalkan login atau perlindungan akun saja tidak menghilangkan celah pada komponen PHP, kata laporan Media Kompeten yang mengutip BSSN.

FAQ: BSSN Peringatkan Celah Kritis PHP2Shell, Pemilik Website Segera Update

---

Catatan: Panduan ini bersifat informasi umum dan bukan nasihat hukum, keuangan, atau keamanan profesional. Untuk sistem produksi atau situs yang menyimpan data pelanggan, konsultasikan dengan engineer keamanan atau penyedia hosting Anda.

Disusun oleh Redaksi mstsgmo.

Sumber rujukan: Rilis PHP 8.5.12 (GitHub php-src) · watchTowr: FAQ PHP2Shell · Tenable: FAQ PHP2Shell · Kompas.com: BSSN peringatkan PHP2Shell · Katadata: BSSN soal PHP2Shell · Cybernews: PHP2Shell, Amazon dan Cloudflare · Wikipedia: PHP2Shell