Pada 22 September 2026, sehari sebelum libur Hari Nasional, WordPress merilis pembaruan keamanan 7.1.2 untuk menutup CVE-2026-87902. Celah ini tidak ada di plugin atau tema. Celah ini ada di inti WordPress, dan memengaruhi setiap versi dari 4.7.0 hingga 7.1.1. Pada hari yang sama, pukul 11:49 UTC (pukul 2:49 siang waktu Riyadh), perusahaan keamanan Patchstack melihat upaya pertama untuk mengeksploitasinya, dan kurang dari empat jam kemudian, upaya pertama untuk menulis file ke server sebuah situs.

Bagaimana serangan menyebar dalam lima hari

Kemudian serangan itu menyebar. Menurut laporan CrowdSec yang diterbitkan hari ini, 28 September, jaringannya mencatat 322.680 sinyal serangan yang cocok dengan celah tersebut dari 30.813 alamat IP berbeda antara 23 dan 27 September, dengan puncak pada 27 September sebanyak 124.154 sinyal. Otoritas Keamanan Siber Nasional (NCA) Arab Saudi mengeluarkan peringatan Kritis, nomor 2026-7873, pada 23 September, dan badan Amerika Serikat CISA menambahkan celah itu ke katalog kerentanan yang diketahui telah dieksploitasi pada 25 September.

Apa yang dilakukan celah ini, secara sederhana

Saat pengunjung meminta sebuah halaman, WordPress menentukan file template tema mana yang dipakai untuk menampilkannya. Bug-nya ada di langkah itu: penyerang yang tidak login dapat mengarahkannya ke file PHP yang berada di server di luar folder tema, dan WordPress akan menjalankannya. WordPress memberi celah ini nilai 9.2 dari 10; CISA memberinya nilai 8.1.

Celah ini berubah menjadi kendali atas situs ketika kondisi yang disebutkan dalam advisori WordPress dan laporan para peneliti terpenuhi bersamaan:

  • Tema: tema aktif memiliki folder yang namanya diawali page-. Advisori menyebut Twenty Twelve, Twenty Fourteen, Neve, Hestia, dan Sydney di antara tema yang memilikinya.
  • Pengaturan PHP: register_argc_argv aktif, yang menurut CrowdSec merupakan pengaturan bawaan pada image Docker PHP resmi dan pada server cPanel yang menjalankan PHP lebih lama dari 8.5.
  • File pembantu: pearcmd.php milik PEAR ada di server. Penyerang menggunakannya untuk menulis file PHP baru, dengan kata lain sebuah backdoor yang tetap bertahan setelah pembaruan.

Jadi celah ini tidak menghantam setiap situs secara sama, tetapi Security Affairs merangkumnya begini: eksekusi kode memerlukan konfigurasi server yang sesuai, dan banyak server memang sesuai. Pemilik bisnis biasanya tidak tahu tema mana yang aktif atau bagaimana server dikonfigurasi, sehingga asumsi yang aman adalah situs itu rentan sampai terbukti sebaliknya.

Mengapa serangan datang dalam hitungan jam, bukan minggu

Pembaruan keamanan pada dasarnya mengungkap letak bug, karena perubahan kodenya bersifat publik. Patchstack menyatakan payload pertama cocok persis dengan pola yang ditutup oleh perbaikan, artinya siapa pun yang menulisnya berangkat dari perbaikan itu sendiri, bukan dari penemuan independen. Upaya pertama meminta file inti WordPress biasa, seperti wp-login.php dan wp-cron.php, untuk melihat bagaimana situs merespons, lalu beralih ke penulisan file.

Lalu lintas tersebut juga membawa jejak pemindai otomatis dan kode proof-of-concept yang telah dipublikasikan. Bagi pemilik bisnis, artinya tidak ada yang secara khusus memilih situs Anda. Alat-alat itu menyisir setiap situs WordPress yang bisa mereka jangkau, dan perbedaan antara situs yang dibobol dan situs yang bersih adalah apakah pembaruan tiba lebih dulu daripada mereka.

Apakah situs Anda memperbarui diri sendiri?

Kemungkinan besar ya, tetapi jangan berasumsi. WordPress memiliki pembaruan latar belakang otomatis sejak versi 3.7, dan sejak 5.6 instalasi baru memperbarui otomatis rilis minor maupun mayor. Pengumuman 7.1.2 menyebutkan situs yang mendukung pembaruan latar belakang otomatis akan mulai diperbarui secara otomatis.

Namun, pembaruan otomatis dapat dimatikan dengan satu baris di wp-config.php. Sebagian pengembang sengaja mematikannya agar pembaruan tidak merusak tema yang dikustomisasi, dan sebagian penyedia hosting mengelola pembaruan dari sisi mereka. Situs yang dibangun seorang freelancer bertahun-tahun lalu, yang kontraknya sudah berakhir, bisa tertahan di versi lama tanpa ada yang menyadarinya. Untuk memeriksanya:

  • Masuk ke halaman admin situs, buka halaman Pembaruan di bawah menu Dasbor, dan Anda akan melihat versi saat ini di sana.
  • Versi yang aman adalah 7.1.2 atau lebih baru. Jika situs Anda berada di cabang yang lebih lama, perbaikan telah menjangkau setiap cabang hingga 4.7, termasuk 7.0.6, 6.9.9, 6.8.10, dan 4.7.37; daftar lengkapnya ada di advisori WordPress yang ditautkan di bagian sumber.
  • Perlu dicatat bahwa WordPress menyatakan hanya versi terbaru yang didukung secara aktif. Situs yang dibiarkan di cabang lama memang menerima perbaikan ini, tetapi hidup di waktu pinjaman. Kami telah membahas apa yang ditawarkan versi baru untuk situs perusahaan dalam WordPress 7.1: fitur-fitur baru utama.

Elementor juga: satu tautan sudah cukup

Pada minggu yang sama, Elementor, page builder WordPress yang populer, memperbaiki celah yang hanya ada di versi 4.3.0 dan 4.3.1. Jika administrator situs membuka tautan yang dibuat khusus saat sedang login, penyerang dapat membuat akun administrator yang dikendalikannya, dan tautan itu bisa datang lewat email, chat, atau komentar. Menurut BleepingComputer, versi-versi tersebut berjalan di hingga 2 juta situs. Perbaikannya dirilis di versi 4.3.2 pada 24 September, dan situs tersebut tidak melaporkan eksploitasi aktif saat artikelnya terbit.

Pastikan Elementor berada di versi 4.3.2 atau lebih baru, dan jadikan ini aturan tim: jangan membuka tautan dari pesan atau komentar saat sedang login ke halaman admin situs.

Jika situs Anda belum diperbarui sejak 22 September

  • Perbarui sekarang: jika pengembang khawatir pembaruan akan merusak sesuatu, Patchstack menyatakan jalur serangan dapat ditutup sementara dengan memblokir upaya directory traversal pada parameter pagename, atau dengan mematikan register_argc_argv. Itu tugas penyedia hosting atau pengembang, dan tidak menggantikan pembaruan.
  • Anggap situs Anda sudah diselidiki penyerang: minta pengembang atau penyedia hosting mencari file PHP yang tidak pernah ditambahkan siapa pun, terutama di /tmp dan /var/tmp, tempat Patchstack menyebut file seperti poc87902.php dan wp-pear-rce-flag.php sebagai tanda eksekusi kode yang berhasil.
  • Jika ditemukan sesuatu: tangani sebagai insiden, bukan sebagai pembaruan. Ganti kata sandi akun admin, basis data, dan hosting, pulihkan situs dari cadangan yang bersih, lalu perbarui.
  • Jika situs menyimpan data pelanggan: misalnya menyimpan pesanan, formulir kontak, atau akun, maka panduan Otoritas Data dan Kecerdasan Buatan Saudi (SDAIA) tentang insiden pelanggaran data pribadi mewajibkan pengendali untuk memberi tahu otoritas yang berwenang dalam 72 jam sejak mengetahui pelanggaran yang dapat merugikan data atau orang-orang pemiliknya.

Pandangan Origami

Banyak situs web perusahaan dibangun di atas WordPress lalu diperlakukan seperti brosur cetak: pengembang menyerahkannya, pemilik membayar, dan tidak ada yang bertanya siapa yang akan menjaganya tetap mutakhir. Celah ini mengingatkan bahwa situs web adalah sistem hidup di server yang terhubung ke internet, dan bahwa jarak antara terbitnya perbaikan dan datangnya penyerang kini diukur dalam hitungan jam. Pertanyaan sebenarnya bukan apakah WordPress aman, karena WordPress telah memperbaiki bug itu dan mendistribusikan perbaikannya ke setiap cabang hingga 4.7. Pertanyaannya adalah siapa di perusahaan Anda yang bertanggung jawab memasangnya.

Itulah mengapa kami berpendapat kontrak pemeliharaan situs web harus menetapkan batas waktu maksimum untuk memasang pembaruan keamanan kritis, mewajibkan salinan staging tempat pembaruan diuji sebelum diterapkan ke situs live, dan menyimpan cadangan rutin di luar server itu sendiri. Dan jika pembaruan terus ditunda karena tema dikustomisasi sedemikian rupa sehingga rusak setiap kali diperbarui, itu adalah masalah cara situs dibangun, bukan masalah WordPress, dan layak diperbaiki sebelum celah berikutnya.

Kesimpulan: tiga langkah

  • Hari ini: buka halaman admin dan pastikan versinya 7.1.2 atau rilis perbaikan cabang Anda, dan Elementor berada di versi 4.3.2 atau lebih baru.
  • Minggu ini: minta pengembang atau penyedia hosting memindai server untuk mencari file PHP yang tidak dikenal dan mengonfirmasi secara tertulis bahwa pembaruan otomatis aktif.
  • Bulan ini: tambahkan batas waktu maksimum untuk memasang pembaruan keamanan ke dalam kontrak pemeliharaan, dan tunjuk orang yang bertanggung jawab atasnya.

Sumber