← AEU Hosting Blog

Defekti CSRF i Elementor e kthen një lidhje të klikuar në një llogari administratori

2026-10-08

Defekti CSRF i Elementor e kthen një lidhje të klikuar në një llogari administratori

Një defekt i cross-site request forgery (CSRF) në shtojcën Elementor Website Builder lejon që një lidhje e vetme, e hapur nga një përdorues i WordPress i kyçur, ta bëjë atë përdorues të kryejë çdo veprim të REST API që llogaria e tij ka leje të kryejë. Në një instalim standard të WordPress, një administrator që klikon lidhjen krijon një llogari të dytë administratori për sulmuesin. Dobësia prek saktësisht versionet 4.3.0 dhe 4.3.1, dhe vetëm këto dy versione. Ajo u zbulua dhe u raportua te Patchstack nga studiuesi i sigurisë Saggre, dhe Patchstack ka lëshuar rregulla zbutëse për t'u mbrojtur nga shfrytëzimi. Defekti ka një rezultat CVSS prej 8.8, duke e vendosur në rangun e ashpërsisë së lartë.

Elementor është ndërtuesi i faqeve më i përdorur për WordPress, aktiv në mbi dhjetë milionë sajte. Ai ofron një redaktues vizual drag-and-drop, një bibliotekë shabllonesh dhe një ndërtues temash për ndërtimin e faqeve pa shkruar kod. Kodi i prekur i përket modulit Editor Events, i cili përfaqëson telemetrinë e redaktuesit të Elementor. Ai modul është i mbyllur pas një eksperimenti, por jo në një mënyrë që shumica e pronarëve të sajteve mund ta shohin ose ndikojnë. Eksperimenti është shënuar si i fshehur, kështu që nuk shfaqet fare në ekranin e Eksperimenteve të Elementor, dhe cilësimi i tij default_active e aktivizon atë për çdo sajt instalimi i parë i Elementor i të cilit ishte versioni 3.32.0 ose më i ri. Një instalim i parazgjedhur i 4.3.0 ose 4.3.1, pa ndryshuar asnjë cilësim dhe pa asnjë shtojcë tjetër, është i prekur. Konstruktori i modulit gjithashtu regjistron filtrin përkatës pa kushte, kështu që asgjë në lidhje me cilësimet e telemetrisë së një sajti nuk e parandalon dobësinë. Versionet para 4.3.0 nuk e përfshijnë fare përfaqësuesin e Editor Events dhe nuk janë të prekura.

Përfaqësuesi i ngjarjeve regjistron dy rrugë REST dhe dëshiron që kërkesat e veta të përjashtohen nga kontrolli i nonce-it të REST, i cili është mbrojtja e integruar e bërthamës së WordPress kundër CSRF. Për ta bërë këtë, ai lidh filtrin rest_authentication_errors me përparësi 0. Problemi është koha: ky filtër ekzekutohet para se WordPress të ketë përputhur një rrugë, kështu që callback-u mund të inspektojë vetëm vargun e papërpunuar të URI-së së kërkesës. Kodi përdor një kërkim strpos() të paankoruar mbi të gjithë $_SERVER['REQUEST_URI'], e cila përfshin si shtegun ashtu edhe vargun e pyetjes. Për shkak se vargu i pyetjes shkruhet nga kushdo që kompozon lidhjen, çdo kërkesë REST mund të përjashtojë veten nga kontrolli i nonce-it duke shtuar një parametër me pamje të padëmshme që përmban vargun literal elementor/v1/events/. Për shembull, të gjitha sa vijojnë e plotësojnë kontrollin ndërsa kërkesa në fakt dërgohet në një pikë fundore krejtësisht të ndryshme: /wp-json/wp/v2/users?zzz=elementor/v1/events/, /wp-json/wp/v2/users?elementor/v1/events/ (pa emër parametri fare), dhe /wp-json/wp/v2/users?q=foo-elementor/v1/events/-bar (as një segment i plotë).

Kthimi i true nga ky filtër është më i fortë se thjesht anashkalimi i një kontrolli. Filtri rest_authentication_errors është një kanal i përbashkët, dhe çdo mbajtës i sjellshëm mbi të fillon duke kontrolluar nëse një mbajtës i mëparshëm ka marrë tashmë një vendim. Kontrolli i nonce-it i bërthamës së WordPress është shkruar pikërisht në atë mënyrë: ai kthehet menjëherë nëse një filtër i mëparshëm ka kthyer një vlerë jo të zbrazët. Për shkak se filtri i Elementor ekzekutohet me përparësi 0 dhe kthen true, ai pretendon se autentikimi ka pasur sukses tashmë para se çdo gjë tjetër të ketë një fjalë. Verifikimi i nonce-it i bërthamës nuk arrihet kurrë, dhe çdo shtojcë sigurie që forcon autentikimin REST përmes të njëjtit filtër anashkalohet bashkë me të. Ajo që mbetet është permission_callback i rrugës, i cili pyet se çfarë lejohet të bëjë përdoruesi aktual. Për shkak se viktima është e kyçur, cookie-ja e tyre i përgjigjet bujarisht asaj pyetjeje. Autorizimi ende mbahet; vetëm prova e qëllimit është zhdukur.

Shumica e gjetjeve të CSRF në REST kanë nevojë për një faqe që dërgon një formular ose lëshon një kërkesë fetch(), gjë që kufizon dërgimin në vendet ku sulmuesi mund të vendosë skript ose markup. Kjo nuk e bën, sepse bërthama e WordPress pranon një parametër pyetjeje _method që anulon foljen HTTP. Një navigim i thjeshtë GET, siç është klikimi i një lidhjeje të thjeshtë, mjafton për të kryer një shkrim. I gjithë sulmi futet brenda një URL-je: 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/. Pa parametrin përfundimtar, e njëjta kërkesë kthen rest_cannot_create_user me HTTP 401. Me të, serveri kthen HTTP 201 dhe një objekt përdoruesi vargu i roleve të të cilit është ["administrator"]. Studiuesi konfirmoi se një shënues një karakter më i shkurtër se hapësira e vërtetë e emrave, elementor/v1/event/, refuzohet, duke përjashtuar çdo shpjegim tjetër për ndryshimin. Për shkak se një etiketë e vetme spirancë mjafton, ngarkesa mund të dërgohet kudo ku mund të shkojë një lidhje: një email, një mesazh chat, një postim forumi, një koment në një sajt të palidhur. Viktima sheh një lidhje normale dhe një përgjigje JSON.

Rrezja e shpërthimit është çdo rrugë REST. Kjo nuk është një dobësi në pikat fundore të vetë Elementor që ndodh të jetë e arritshme nga CSRF. Anashkalimi vlerësohet para rutimit, kështu që zbatohet për të gjithë sipërfaqen e REST API të sajtit: rrugët e bërthamës së WordPress, dhe rrugët e çdo shtojce tjetër të instaluar krahas tij. Krijimi i një administratori përmes /wp/v2/users është demonstrimi më i qartë, por studiuesi gjithashtu tregoi se GET /wp-json/wp/v2/settings ndryshon nga HTTP 401 në HTTP 200 me cilësimet e sajtit të kthyera në trupin e përgjigjes. Çdo gjë që llogaria e viktimës mund të arrijë mbi REST është në fushëveprim, duke përfshirë pikat fundore që u përkasin shtojcave që nuk bënë asgjë të gabuar.

Elementor e rregulloi defektin në versionin 4.3.2. Kodi zëvendësues lexon $wp->query_vars['rest_route'] në vend të URI-së së papërpunuar. Ajo vlerë është rruga që WordPress zgjidhi në të vërtetë, pas rishkrimit, me vargun e pyetjes tashmë të ndarë. Nuk ka më asnjë tekst të kompozuar nga sulmuesi në vlerën që testohet. Krahasimi gjithashtu ndryshoi nga false !== strpos(...) në 0 === strpos(...), kështu që hapësira e emrave duhet të shfaqet në fillim të rrugës dhe jo diku brenda saj. Ky ndryshim i dytë është kritik: anashkalimi i tij do të kishte lënë një version më të vogël të të njëjtit gabim, sepse një rrugë si /otherplugin/v1/x/elementor/v1/events/ do të ishte ende përputhur. Një mbrojtje e shtuar is_string() mbyll një derë tjetër ku rest_route mund të dorëzohej si një grup.

Shkaku rrënjësor është një mospërputhje midis pyetjes që kodi bëri dhe të dhënave të disponueshme për t'iu përgjigjur asaj. Kodi donte të dinte "a është kjo kërkesë për rrugën time?", por ai pyeti në një pikë ku WordPress nuk e kishte vendosur ende atë, dhe u mjaftua me një kërkim nënvargu mbi një varg që klienti e kontrollon. Dy mësime përgjithësohen përtej kësaj shtojce. Së pari, $_SERVER['REQUEST_URI'] është hyrje e kontrolluar nga sulmuesi, jo metadata rutimi; çdo vendim sigurie i bazuar në të ka nevojë që vargu i pyetjes të hiqet dhe krahasimi të ankorohet. Së dyti, rest_authentication_errors është një kanal i përbashkët, dhe kthimi i një vlere të vërtetë nuk është një përjashtim lokal. Ai pohon sukses për çdo mbajtës në rrjedhën e poshtme, duke përfshirë verifikimin e nonce-it të bërthamës së WordPress. Një filtër që duhet vetëm të thotë "pa mendim" duhet të kthejë $result të pandryshuar. Patchstack rekomandon fuqimisht përditësimin e Elementor në versionin 4.3.2 ose më lart. Afati kohor është i shkurtër: raporti mbërriti më 2026-09-22, Elementor lëshoi versionin 4.3.2 më 2026-09-24, dhe njoftimi publik u lëshua më 2026-09-25. Për pronarët e sajteve që nuk mund të monitorojnë vetë çdo lëshim shtojce, hostimi i menaxhuar i WordPress me kopje rezervë automatike dhe forcim sigurie, siç është AEU Hosting, zvogëlon dëmin nëse një shtojcë e cenueshme shfrytëzohet dhe ndihmon në rivendosjen e shpejtë të një kopjeje të pastër.