Elementor CSRF: satu link, satu akaun admin

Elementor CSRF: satu link, satu akaun admin

Satu link, yang dibuka oleh seorang pentadbir WordPress yang masih log masuk, sudah memadai untuk memberi penyerang satu akaun pentadbir kedua. Tiada JavaScript, tiada form, tiada halaman di bawah kawalan penyerang. Hanya satu URL, dan orang yang tidak dikenali mengkliknya dalam keadaan masih log masuk.

Ringkasnya, CVE-2026-62062, didedahkan pada 25 September 2026 dalam Elementor Website Builder, page builder drag-and-drop yang berjalan pada lebih daripada sepuluh juta laman WordPress. Rekod CVE memberi markah CVSS 3.1 sebanyak 8.8, HIGH, dengan vector AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H dan CWE-352. Rekod triaj Patchstack sendiri menlabel pepijat yang sama sebagai "medium priority" — peringatan kami bahawa label keutamaan vendor dan skor CVSS ialah dua perbualan berasingan.

Pepijat itu dilaporkan kepada Elementor pada 22 September 2026 oleh researcher Saggre, melalui Patchstack. Elementor menyediakan fix dua hari kemudian, dalam 4.3.2. Hanya versi 4.3.0 dan 4.3.1 terjejas, dan statistik WordPress.org menunjukkan sehingga dua juta laman menjalankan salah satu daripada dua versi itu.

Eksperimen tersembunyi, bukan tetapan yang kelihatan

Kod yang terjejas milik modul Editor Events Elementor, yang menjadi proksi telemetri editor itu. Penulisan Patchstack menemukan ia dikunci di sebalik satu eksperimen, dan di sinilah ceritanya menjadi tidak selesa:

// core/common/app.php - init_components()
if ( Plugin::$instance->experiments->is_feature_active( Events_Manager::EXPERIMENT_NAME ) ) {
    $this->add_component( 'events-manager', new Events_Manager() );
}

// core/common/modules/events-manager/module.php - get_experimental_data()
'hidden' => true, // not shown on the Experiments screen
'default' => Experiments_Manager::STATE_INACTIVE,
'new_site' => [
    'default_active' => true, // ...but on by default for new sites
    'minimum_installation_version' => '3.32.0',
],

hidden => true bermaksud suis itu tidak pernah muncul di skrin Experiments Elementor, jadi tiada apa-apa yang boleh dicari, dibaca, atau dimatikan oleh pemilik laman. Pemasangan lalai 4.3.0 atau 4.3.1, tanpa tetapan diubah dan tanpa plugin lain, sudah terjejas dengan sendirinya. Konstruktor modul itu juga mendaftarkan filter-nya tanpa syarat, jadi sekadar modul itu dimuatkan sudah cukup — tiada sebarang tetapan telemetri yang boleh menghalangnya. Versi sebelum 4.3.0 tidak menyertakan proksi Editor Events langsung dan tidak terjejas oleh pepijat ini.

Semakan itu tersalah pada rentetan yang salah

Niat modul itu mudah: mengecualikan request telemetri sendiri daripada semakan nonce REST WordPress. Untuk itu ia memasang rest_authentication_errors pada priority 0 dan memulangkan true apabila ia menganggap request itu miliknya.

// core/common/modules/events-manager/rest-api/events-proxy-rest-api.php
// identical in 4.3.0 and 4.3.1
public function register_hooks() {
    add_action( 'rest_api_init', fn() => $this->register_routes() );
    add_filter( 'rest_authentication_errors', [ $this, 'bypass_nonce_check_for_own_routes' ], 0 );
    // ...
}

public function bypass_nonce_check_for_own_routes( $result ) {
    if ( $this->is_own_route_request() ) {
        return true;
    }
    return $result;
}

private function is_own_route_request(): bool {
    $request_uri = Utils::get_super_global_value( $_SERVER, 'REQUEST_URI' ) ?? '';
    // API_NAMESPACE = 'elementor/v1', API_BASE = 'events'
    return false !== strpos( $request_uri, self::API_NAMESPACE . '/' . self::API_BASE . '/' );
}

Masalahnya ialah masa. rest_authentication_errors berlaku dalam WP_REST_Server::check_authentication(), iaitu sebelum request diproses — pada saat itu WordPress belum memadankan route mana-mana, jadi callback itu tiada apa-apa untuk diperiksa kecuali rentetan URI mentah. Penulis kod itu mengambil satu-satunya nilai yang ada, lalu memilih ujian yang paling longgar ke atasnya: strpos() tanpa anchor merentas keseluruhan $_SERVER['REQUEST_URI'].

Tetapi REQUEST_URI bukan route. Ia laluan dan query string, dan query string itu disusun sepenuhnya oleh orang yang menulis link itu. Nama parameter tidak penting, dan kedudukannya juga tidak. Setiap satu daripada ini memenuhi semakan itu sementara request-nya dihantar ke tempat yang langsung lain:

/wp-json/wp/v2/users?zzz=elementor/v1/events/
/wp-json/wp/v2/users?elementor/v1/events/        <- no parameter name at all
/wp-json/wp/v2/users?q=foo-elementor/v1/events/-bar  <- not even a whole segment

Memulangkan true juga lebih kuat daripada sekadar melangkau semakan. rest_authentication_errors ialah filter yang nilainya mengalir sepanjang satu rantaian, dan setiap handler yang betul mula dengan bertanya sama ada handler sebelumnya sudah memutuskan. Semakan nonce WordPress core sendiri ditulis dengan cara begitu, jadi true daripada priority 0 itu dibaca sebagai keputusan, bukan sekadar "entah".

Kenapa link biasa sudah memadai

Kebanyakan penemuan CSRF REST memerlukan halaman yang menghantar form atau memanggil fetch(), jadi penghantaran terhad kepada tempat yang boleh menaruh markup. Yang ini tidak, sebab WordPress core menerima parameter query _method yang menggantikan HTTP verb. Satu navigasi GET jadi memadai untuk melakukan write, dan serangannya muat sepenuhnya dalam satu URL — mekanisma yang sama yang dibincang di sini untuk kaedah HTTP QUERY itu sendiri.

https://example.com/wp-json/wp/v2/users
  ?_method=POST
  &username=csrfadmin
  &email=csrfadmin%40example.test
  &password=...
  &roles%5B%5D=administrator
  &x=elementor/v1/events/     <- the only part that matters

Buang parameter terakhir itu dan request yang sama ditolak seperti biasa: rest_cannot_create_user dengan HTTP 401. Tambahkannya dan server menjawab HTTP 201 dengan objek pengguna yang array roles-nya ialah ["administrator"]. Penyelidik juga mengesahkan bahawa marker satu aksara lebih pendek daripada namespace sebenar, elementor/v1/event/, ditolak — dan itu menyingkirkan sebarang penjelasan selain ujian substring itu.

Kuasanya meliputi setiap route REST

Ini tidak pernah hanya tentang endpoint Elementor sendiri. Filter itu duduk dalam rantaian autentikasi core, jadi melaluinya mematikan semakan nonce untuk route yang sebenarnya sampai, termasuk endpoint plugin lain yang tidak salah buat apa-apa.

Mencipta pentadbir melalui /wp/v2/users ialah demonstrasi paling jelas, tetapi peneliti itu turut menunjukkan GET /wp-json/wp/v2/settings bertukar daripada HTTP 401 kepada HTTP 200 dengan tetapan laman dalam body respons. Rumusan Patchstack itu tepat: satu link, yang dibuka oleh pengguna WordPress yang log masuk, membuat pengguna itu melakukan apa-apa sahaja tindakan REST API yang akaunnya memang dibenarkan. Kebenarannya masih berlaku — mangsa itu memang pentadbir. Yang hilang hanya bukti niat.

Apa yang perlu dibuat

Naik ke 4.3.2 atau lebih baharu; itu sahaja pembaikannya, dan ia hanya dua baris. Kemudian buat bahagian membosankan itu, sebab pepijat yang mudah dikapitalkan ini wajar diasumsikan sudah dicuba. Semak senarai pengguna untuk pentadbir yang anda tidak boleh terangkan asal-usulnya, dan lihat ada tidak yang baharu sahaja datang melalui /wp-json/wp/v2/users. Patchstack telah mengeluarkan mitigation rules untuk kerentanan ini — ganti sementara yang munasabah untuk sesiapa yang tidak dapat patch serta-merta — logik yang sama yang terpakai apabila WAF sahaja yang memisahkan anda dan minggu yang teruk. Tiada satu pun daripada dua penulisan itu melaporkan sebarang eksploitasi sebenar, jadi buat masa ini ini kerja patch, bukan respons insiden.

Tiga perkara yang boleh dibawa pulang

Tiga pelajaran ini jauh melepasi plugin ini. Pertama, hidden => true eksperimen ialah permukaan keselamatan yang tidak akan pernah disebut dalam dokumentasi: satu ciri boleh menjadi di luar jangkauan pemilik laman dan pada masa yang sama aktif secara default, dan jika ciri itu mendaftarkan filter dalam konstruktornya, tetapan pemilik laman tiada kaitan langsung. Kedua, jangan sekali-kali menguji input yang disusun penyerang dengan padanan substring tanpa anchor — bandingkan route yang telah ditetapkan, bukan URI mentah, kerana query string itu milik penyerang. Ketiga, memulangkan true daripada filter autentikasi ialah keputusan, bukan skip, dan ia akan dibaca sebagai keputusan oleh setiap handler di hilirannya.

Pengganti dalam 4.3.2 menunjukkan bagaimana bentuk semakan yang betul kelihatan: baca $wp->query_vars['rest_route'] — route yang benar-benar diselesaikan WordPress selepas query string diasingkan — dan ankurkan padanan itu pada posisi 0.

// 4.3.2 - is_own_route_request()
private function is_own_route_request(): bool {
    global $wp;
    $route = $wp->query_vars['rest_route'] ?? null;
    if ( ! is_string( $route ) ) {
        return false;
    }
    return 0 === strpos( $route, '/' . self::API_NAMESPACE . '/' . self::API_BASE . '/' );
}

Dua hari dari laporan kepada patch ialah kerja yang bagus. Bahagian yang menarik bukan tempoh penangguhan atau nombor CVE, tetapi kenyataan bahawa satu kemudahan telemetri yang menghantar primitif peningkatan hak akses yang tidak sesiapa boleh nampak, apatah lagi matikan.

Sumber

• Patchstack: Cross-Site Request Forgery in Elementor Plugin affecting 2 million sites
• Patchstack: WordPress Elementor Website Builder Plugin 4.3.0-4.3.1 Cross-Site Request Forgery (CSRF)
• BleepingComputer: Elementor WordPress flaw lets attackers create admin accounts
• cve.report: CVE-2026-62062