Pada 22 September 2026, sehari sebelum cuti Hari Kebangsaan, WordPress mengeluarkan kemas kini keselamatan 7.1.2 untuk menutup CVE-2026-87902. Kelemahan ini bukan dalam pemalam atau tema. Ia berada dalam teras WordPress, dan menjejaskan setiap versi dari 4.7.0 hingga 7.1.1. Pada hari yang sama, pada pukul 11:49 UTC (pukul 2:49 petang waktu Riyadh), syarikat keselamatan Patchstack melihat cubaan pertama untuk mengeksploitasinya, dan kurang daripada empat jam kemudian, cubaan pertama untuk menulis fail ke pelayan sebuah laman web.

Bagaimana serangan merebak dalam lima hari

Kemudian ia merebak. Menurut laporan CrowdSec yang diterbitkan hari ini, 28 September, rangkaiannya merekodkan 322,680 isyarat serangan yang sepadan dengan kelemahan itu daripada 30,813 alamat IP berbeza antara 23 dan 27 September, dengan kemuncak pada 27 September sebanyak 124,154 isyarat. Pihak Berkuasa Keselamatan Siber Kebangsaan (NCA) Arab Saudi mengeluarkan amaran Kritikal, no. 2026-7873, pada 23 September, dan agensi Amerika Syarikat CISA menambah kelemahan itu ke dalam katalog kerentanan yang diketahui telah dieksploitasi pada 25 September.

Apa yang dilakukan oleh kelemahan ini, secara mudah

Apabila pelawat meminta sesuatu halaman, WordPress memutuskan fail templat tema yang mana akan digunakan untuk memaparkannya. Pepijatnya berada pada langkah itu: penyerang yang tidak log masuk boleh menghalakannya ke fail PHP yang terletak pada pelayan di luar folder tema, dan WordPress akan menjalankannya. WordPress menilai kelemahan ini 9.2 daripada 10; CISA menilainya 8.1.

Ia bertukar menjadi kawalan ke atas laman web apabila syarat yang dinyatakan dalam nasihat keselamatan WordPress dan laporan para penyelidik dipenuhi serentak:

  • Tema: tema aktif mengandungi folder yang namanya bermula dengan page-. Nasihat itu menyenaraikan Twenty Twelve, Twenty Fourteen, Neve, Hestia dan Sydney antara tema yang mempunyainya.
  • Tetapan PHP: register_argc_argv dihidupkan, yang menurut CrowdSec merupakan tetapan lalai dalam imej Docker PHP rasmi dan pada pelayan cPanel yang menjalankan PHP lebih lama daripada 8.5.
  • Fail pembantu: pearcmd.php milik PEAR wujud pada pelayan. Penyerang menggunakannya untuk menulis fail PHP baharu, dalam erti kata lain pintu belakang yang kekal selepas kemas kini.

Jadi kelemahan ini tidak menjejaskan setiap laman web secara sama rata, tetapi Security Affairs merumuskannya begini: pelaksanaan kod memerlukan persediaan pelayan yang sepadan, dan banyak pelayan memang sepadan. Pemilik perniagaan biasanya tidak tahu tema mana yang aktif atau bagaimana pelayan dikonfigurasikan, jadi andaian yang selamat ialah laman web itu terdedah sehingga dibuktikan sebaliknya.

Mengapa serangan datang dalam beberapa jam, bukan minggu

Kemas kini keselamatan secara semula jadi mendedahkan lokasi pepijat, kerana perubahan kod adalah terbuka kepada umum. Patchstack menyatakan bahawa muatan pertama sepadan tepat dengan corak yang ditutup oleh pembaikan itu, bermakna sesiapa yang menulisnya bermula daripada pembaikan itu sendiri dan bukan daripada penemuan bebas. Cubaan pertama meminta fail teras WordPress biasa, seperti wp-login.php dan wp-cron.php, untuk melihat bagaimana laman web bertindak balas, kemudian beralih kepada menulis fail.

Trafik itu juga membawa kesan pengimbas automatik dan kod bukti konsep (proof-of-concept) yang telah diterbitkan. Bagi pemilik perniagaan, ini bermakna tiada sesiapa yang memilih laman web anda secara khusus. Alat-alat itu menyapu setiap laman web WordPress yang boleh dicapai, dan perbezaan antara laman web yang telah dicerobohi dengan yang bersih ialah sama ada kemas kini tiba lebih awal daripada mereka.

Adakah laman web anda mengemas kini dirinya sendiri?

Mungkin, tetapi jangan menganggapnya begitu. WordPress mempunyai kemas kini latar belakang automatik sejak versi 3.7, dan sejak 5.6 pemasangan baharu mengemas kini secara automatik kedua-dua keluaran kecil dan utama. Pengumuman 7.1.2 menyatakan bahawa laman web yang menyokong kemas kini latar belakang automatik akan mula dikemas kini secara automatik.

Namun, kemas kini automatik boleh dimatikan dengan satu baris dalam wp-config.php. Sesetengah pembangun mematikannya dengan sengaja supaya kemas kini tidak merosakkan tema yang telah disesuaikan, dan sesetengah penyedia hos menguruskan kemas kini di pihak mereka. Laman web yang dibina oleh pekerja bebas bertahun-tahun lalu, yang kontraknya telah tamat, boleh kekal pada versi lama tanpa disedari sesiapa. Untuk menyemak:

  • Log masuk ke bahagian pentadbir laman web, buka halaman Kemas Kini di bawah menu Papan Pemuka, dan anda akan melihat versi semasa di situ.
  • Versi yang selamat ialah 7.1.2 atau lebih baharu. Jika laman web anda berada pada cabang yang lebih lama, pembaikan telah sampai ke setiap cabang hingga 4.7, termasuk 7.0.6, 6.9.9, 6.8.10 dan 4.7.37; senarai penuh terdapat dalam nasihat keselamatan WordPress yang dipautkan dalam bahagian sumber.
  • Ambil perhatian bahawa WordPress menyatakan hanya versi terkini yang disokong secara aktif. Laman web yang dibiarkan pada cabang lama memang menerima pembaikan ini, tetapi ia hidup dengan masa yang dipinjam. Kami telah menerangkan apa yang dibawa oleh versi baharu kepada laman web syarikat dalam WordPress 7.1: ciri-ciri baharu utama.

Elementor juga: satu pautan sudah memadai

Pada minggu yang sama, Elementor, pembina halaman WordPress yang popular, membaiki kelemahan yang hanya wujud dalam versi 4.3.0 dan 4.3.1. Jika pentadbir laman web membuka pautan yang direka khas semasa log masuk, penyerang boleh mencipta akaun pentadbir yang dikawalnya, dan pautan itu boleh tiba melalui e-mel, sembang atau komen. Menurut BleepingComputer, versi-versi tersebut berjalan pada sehingga 2 juta laman web. Pembaikan dikeluarkan dalam 4.3.2 pada 24 September, dan laman web itu tidak melaporkan eksploitasi aktif pada masa penerbitannya.

Pastikan Elementor berada pada versi 4.3.2 atau lebih baharu, dan jadikannya peraturan pasukan: jangan buka pautan daripada mesej atau komen semasa log masuk ke bahagian pentadbir laman web.

Jika laman web anda tidak dikemas kini sejak 22 September

  • Kemas kini sekarang: jika pembangun bimbang kemas kini akan merosakkan sesuatu, Patchstack menyatakan laluan itu boleh ditutup buat sementara dengan menyekat cubaan directory traversal dalam parameter pagename, atau dengan mematikan register_argc_argv. Itu tugas penyedia hos atau pembangun, dan ia tidak menggantikan kemas kini.
  • Anggap laman web anda telah diintai: minta pembangun atau penyedia hos mencari fail PHP yang tidak pernah ditambah oleh sesiapa, terutamanya dalam /tmp dan /var/tmp, di mana Patchstack menamakan fail seperti poc87902.php dan wp-pear-rce-flag.php sebagai tanda pelaksanaan kod yang berjaya.
  • Jika sesuatu ditemui: kendalikannya sebagai insiden, bukan kemas kini. Tukar kata laluan bagi akaun pentadbir, pangkalan data dan hos, pulihkan laman web daripada sandaran yang bersih, kemudian kemas kininya.
  • Jika laman web menyimpan data pelanggan: iaitu menyimpan pesanan, borang hubungan atau akaun, maka panduan Pihak Berkuasa Data dan Kecerdasan Buatan Saudi (SDAIA) mengenai insiden pelanggaran data peribadi mewajibkan pengawal memaklumkan pihak berkuasa yang berkenaan dalam tempoh 72 jam selepas mengetahui pelanggaran yang boleh memudaratkan data atau individu yang memilikinya.

Pandangan Origami

Banyak laman web syarikat dibina di atas WordPress dan kemudian dilayan seperti risalah bercetak: pembangun menyerahkannya, pemilik membayar, dan tiada siapa bertanya siapa yang akan memastikannya sentiasa dikemas kini. Kelemahan ini mengingatkan bahawa laman web ialah sistem hidup pada pelayan yang terdedah kepada internet, dan jurang antara penerbitan pembaikan dengan ketibaan penyerang kini diukur dalam jam. Persoalan sebenar bukanlah sama ada WordPress selamat, kerana ia telah membaiki pepijat itu dan menghantar pembaikan ke setiap cabang hingga 4.7. Persoalannya ialah siapa dalam syarikat anda yang bertanggungjawab memasangnya.

Itulah sebabnya kami berpendapat kontrak penyelenggaraan laman web perlu menetapkan tempoh maksimum untuk memasang kemas kini keselamatan kritikal, mewajibkan salinan staging di mana kemas kini diuji sebelum laman web langsung, dan menyimpan sandaran berkala di luar pelayan itu sendiri. Dan jika kemas kini terus ditangguhkan kerana tema disesuaikan dengan cara yang rosak setiap kali dikemas kini, itu masalah cara laman web dibina, bukan masalah WordPress, dan ia wajar dibaiki sebelum kelemahan seterusnya.

Kesimpulan: tiga langkah

  • Hari ini: buka bahagian pentadbir dan sahkan versinya ialah 7.1.2 atau keluaran yang telah dibaiki bagi cabang anda, dan Elementor berada pada 4.3.2 atau lebih baharu.
  • Minggu ini: minta pembangun atau penyedia hos mengimbas pelayan untuk mencari fail PHP yang tidak dikenali dan mengesahkan secara bertulis bahawa kemas kini automatik dihidupkan.
  • Bulan ini: tambah tempoh maksimum untuk memasang kemas kini keselamatan ke dalam kontrak penyelenggaraan, dan namakan orang yang bertanggungjawab ke atasnya.

Sumber