PHP2Shell 22 Oktober 2026: Panduan Pemilik Website

Keamanan website • PHP2Shell • 22 Oktober 2026

Website masih terbuka bukan berarti pembaruan PHP boleh ditunda.

Dua celah kritis memicu pembaruan darurat. Pemilik bisnis perlu memastikan hosting sudah menerapkan perbaikan yang sesuai.

Oleh Masbadar · Diterbitkan 22 Oktober 2026
Ringkasan berdasarkan pengumuman resmi yang tersedia saat penyusunan.

Isu PHP yang ramai pada 22 Oktober 2026 adalah PHP2Shell, sebutan untuk dua kerentanan kritis yang berpotensi memungkinkan penyerang menjalankan kode dari jarak jauh tanpa login. Tim PHP telah merilis perbaikan darurat pada 21 Oktober 2026.

Bagi pemilik website perusahaan, toko online, dan pengelola WordPress, langkah pertama adalah menghubungi penanggung jawab hosting. Pastikan perbaikan benar-benar terpasang pada PHP yang melayani website Anda, lalu periksa kembali fungsi bisnisnya.

1. Apa yang terjadi pada PHP?

PHP merupakan teknologi yang menjalankan banyak aplikasi web di sisi server. WordPress adalah salah satu aplikasi yang menggunakannya. Karena posisinya mendasari aplikasi, kelemahan pada PHP dapat relevan bagi beragam website sekaligus.

Dalam pengumuman keamanan PHP, dua masalah tersebut diidentifikasi sebagai CVE-2026-109618 dan CVE-2026-109619. Keduanya berkaitan dengan penanganan memori dan keadaan internal ketika pemrosesan permintaan mengalami gangguan.

Menurut keterangan Ubuntu, keduanya memperoleh skor CVSS 4.0 sebesar 9,2, dalam kategori kritis. Angka ini menunjukkan tingkat keparahan teknis, bukan persentase kemungkinan website tertentu sudah disusupi.

Pernyataan bersama yang dipublikasikan ENISA meminta organisasi mengidentifikasi aplikasi berbasis PHP, berkoordinasi dengan penyedia layanan, dan memprioritaskan sistem yang terbuka ke internet. Bila perbaikan belum dapat dilakukan, isolasi aplikasi yang terekspos perlu dipertimbangkan.

2. Website mana yang perlu diperiksa?

Tim PHP memasukkan instalasi yang melayani permintaan web ke dalam cakupan risiko, termasuk PHP-FPM, Apache dengan mod_php, php-cgi, FrankenPHP, dan LiteSpeed. Pengumuman tersebut menempatkan mod_php pada risiko tertinggi berdasarkan eksploitasi yang telah didemonstrasikan.

Bagi pemilik usaha, Anda tidak harus menguasai nama-nama konfigurasi itu. Yang diperlukan adalah jawaban jelas dari hosting: apakah layanan Anda menggunakan PHP yang terdampak, dan perbaikan apa yang telah diterapkan?

Bedakan aplikasi website dan pengelolaan servernya
Jenis layananLangkah yang relevan
WordPress di hosting sendiriCek versi PHP dan minta konfirmasi patch dari hosting atau administrator server.
Website perusahaan atau toko berbasis PHPMinta pengelola memeriksa aplikasi utama, subdomain, dan layanan pendukung yang menggunakan PHP.
WordPress.comPengumuman platform pada 21 Oktober menyatakan website yang dihosting di WordPress.com telah dilindungi. Pernyataan ini tidak mewakili seluruh penyedia hosting WordPress.
Blogger dengan domain sendiriDomain kustom tidak otomatis berarti memakai hosting PHP sendiri. Periksa layanan terpisah yang dihubungkan, misalnya toko atau formulir pada server lain.

WordPress.org menegaskan bahwa kerentanan ini tidak khusus menyerang WordPress dan tidak memerlukan pembaruan WordPress tersendiri untuk memperbaikinya. Sementara itu, WordPress.com mengumumkan perlindungan pada infrastrukturnya.

Untuk pengguna Blogger, panduan domain kustom Google menjelaskan pengarahannya ke layanan Blogger. Jadi, akhiran .com atau .co.id saja tidak cukup untuk menyimpulkan teknologi server yang dipakai.

3. Versi PHP mana yang memuat perbaikan?

Pengumuman proyek PHP pada 21 Oktober 2026 mencantumkan empat rilis berikut sebagai pembaruan yang memperbaiki kedua kerentanan.

Rilis perbaikan upstream pada 21 Oktober 2026
Cabang PHPRilis perbaikan
PHP 8.58.5.12
PHP 8.48.4.27
PHP 8.38.3.36
PHP 8.28.2.35

Jangan menilai status patch dari angka versi pendek saja. Penyedia sistem operasi dapat memasukkan perbaikan ke paket yang mempertahankan nomor versi dasar sebelumnya. Ubuntu, misalnya, mencantumkan nomor paket perbaikan tersendiri untuk distribusinya. Minta nomor paket lengkap dan rujukan pemberitahuan keamanan vendor.

PHP 8.1 dan versi lebih lama sudah tidak menerima pembaruan reguler dari proyek PHP. Sebagian distributor atau vendor dukungan jangka panjang menyediakan perbaikan tambahan. Pemilik website lama perlu meminta bukti cakupan dukungannya sekaligus merencanakan perpindahan ke cabang yang didukung.

4. Langkah yang perlu dilakukan pemilik website

Daftar berikut merupakan alur koordinasi praktis untuk pemilik bisnis. Pelaksanaan di server perlu disesuaikan oleh administrator dengan lingkungan hosting masing-masing.

  1. Catat website dan penanggung jawabnya. Sertakan subdomain, toko online, serta aplikasi yang dikelola vendor berbeda.
  2. Cek informasi PHP. Pada WordPress, buka Peralatan atau Tools → Kesehatan Situs atau Site Health → Info → Server. Informasi di panel hosting juga dapat membantu.
  3. Minta konfirmasi patch secara tertulis. Sertakan kedua nomor CVE agar jawaban tidak berhenti pada “server sudah aman”.
  4. Koordinasikan pencadangan dan pengujian. Pastikan salinan data serta rencana pemulihan tersedia tanpa menjadikannya alasan menunda penanganan darurat.
  5. Pastikan pembaruan sudah berjalan. Minta administrator mengonfirmasi layanan atau proses yang perlu dimulai ulang telah ditangani. Mengunduh paket belum tentu berarti proses aktif sudah memakai perbaikannya.
  6. Uji fungsi bisnis. Coba formulir kontak, login, katalog, pencarian, checkout, dan email transaksi yang memang digunakan.
  7. Pisahkan patch dan investigasi. Jika ada indikasi penyusupan, minta pemeriksaan log dan integritas file. Pemasangan patch saja tidak membuktikan sistem sebelumnya bersih.

Cloudflare melaporkan penerapan perlindungan WAF dan pengamatan lalu lintas serangan. Meski demikian, perusahaan tersebut tetap meminta pengguna memperbarui PHP. Penggunaan firewall tidak menggantikan pembaruan pada server asal.

5. Contoh pesan yang bisa dikirim ke hosting

Gunakan teks berikut melalui tiket dukungan resmi. Cukup cantumkan domain; jangan menyertakan kata sandi atau kunci akses.

Halo Tim Support, mohon pemeriksaan layanan untuk domain [nama-domain] terkait PHP2Shell, CVE-2026-109618 dan CVE-2026-109619.

Mohon konfirmasi apakah PHP yang melayani website kami terdampak, versi atau paket perbaikan yang sudah digunakan, waktu penerapan, dan apakah proses layanan terkait sudah dimulai ulang bila diperlukan.

Jika belum diperbaiki, mohon jadwal penanganan segera serta pembatasan akses sementara yang disarankan. Mohon informasikan juga bila terdapat indikasi eksploitasi yang perlu ditindaklanjuti. Terima kasih.

Simpan nomor tiket dan jawaban penyedia layanan. Untuk perusahaan dengan beberapa website, buat catatan per domain agar tidak ada aplikasi yang terlewat.

6. Mengapa AI ikut menjadi sorotan?

Isu ini juga memperlihatkan peran AI dalam penelitian keamanan. Wiz menjelaskan penggunaan bantuan AI dalam penelitian dan pengujian kerentanan. Timnya mendemonstrasikan dampak pada beberapa aplikasi populer, termasuk WordPress, Drupal, dan Joomla.

Namun, ceritanya tidak sesederhana AI tiba-tiba menemukan semua masalah baru. The PHP Foundation menjelaskan bahwa tanda awal salah satu akar masalah telah terlihat dalam pekerjaan audit 2024. Laporan lanjutan pada 2026 memperjelas dampak dan jalur eksploitasi.

Foundation juga mengakui keterlambatan penanganan sebagai kegagalan struktural dan menjelaskan perubahan prosesnya. Bantuan AI mempercepat sejumlah pekerjaan, sementara keputusan, peninjauan, dan pengerjaan patch tetap melibatkan manusia.

Pelajaran bagi pengelola bisnis adalah menyediakan jalur respons yang jelas: siapa menerima pemberitahuan keamanan, siapa menghubungi hosting, dan siapa memeriksa website setelah diperbarui.

7. Pertanyaan umum tentang PHP2Shell

Apakah semua website WordPress sudah diretas?

Tidak ada dasar untuk menyimpulkan demikian. Kerentanan menunjukkan adanya risiko pada lingkungan yang terdampak. Kepastian penyusupan memerlukan bukti dan pemeriksaan tersendiri.

Apakah cukup memperbarui plugin keamanan?

Tidak. Perbaikan kedua celah berada pada PHP di server. Plugin dan tema tetap perlu dikelola, tetapi pembaruannya tidak menggantikan patch PHP.

Apakah PHP 8.3 pasti aman?

Nama cabang saja belum cukup. Periksa rilis lengkap atau paket vendor beserta konfirmasi perbaikannya. PHP 8.3.36 termasuk rilis perbaikan upstream yang diumumkan pada 21 Oktober.

Apakah website harus langsung dimatikan?

Prioritasnya adalah menerapkan perbaikan. Untuk sistem yang masih terekspos dan belum dapat diperbaiki, ENISA menyarankan mempertimbangkan isolasi. Koordinasikan keputusan tersebut dengan administrator, termasuk cara membatasi akses pada lapisan yang tepat.

Apakah sertifikat HTTPS mengatasi masalah ini?

HTTPS melindungi komunikasi dalam perjalanan. Pembaruan PHP menangani kelemahan pada pemrosesan di server; keduanya memiliki fungsi berbeda.

Apakah website yang sudah dipatch masih perlu diperiksa?

Ya. Pastikan fungsi bisnis berjalan dan tindak lanjuti bila ditemukan indikasi penyusupan. Status patch dan status insiden adalah dua pemeriksaan berbeda.

Sumber resmi dan catatan editorial

Rujukan berikut diperiksa untuk penyusunan artikel pada 22 Oktober 2026. Status penanganan dapat berkembang; cek pengumuman terbaru dari vendor yang digunakan.

Artikel ini menyarikan pemberitahuan keamanan untuk pemilik website. Tidak memuat hasil audit atas website pembaca dan tidak menyatakan bahwa suatu penyedia hosting tertentu telah terdampak atau selesai diperbaiki.

Postingan Terkait

Formulir Kontak

Nama

Email *

Pesan *

MARI MULAI DARI KEBUTUHAN ANDA

Punya bisnis yang
ingin tampil lebih baik?

Ceritakan kebutuhan website, company profile, atau konten Anda.

Hubungi Masbadar ↗
Perumahan Citra Kebun Mas, Blok Q3/11
Bengle, Majalaya, Karawang, Jawa Barat 41351
Buka lokasi di Google Maps →