Të metat CSRF në Elementor lejojnë sulmuesit të krijojnë llogari administratori

Elementor, ndërtuesi i faqeve më i përdorur për WordPress me më shumë se dhjetë milionë instalime aktive, ka rregulluar një dobësi cross-site request forgery (CSRF) që lejonte një lidhje të vetme të ekzekutonte çdo veprim të REST API që përdoruesi i identifikuar lejohet të kryejë. Zbuluar nga studiuesi Saggre dhe raportuar në Patchstack, e meta prek vetëm versionet 4.3.0 dhe 4.3.1 të shtojcës Elementor Website Builder. Në një instalim standard të WordPress, një administrator që klikon një lidhje të ndërtuar posaçërisht ndërsa është i identifikuar mund të krijojë pa e ditur një llogari të dytë administratori për një sulmues, pa JavaScript, pa formular dhe pa asnjë faqe nën kontrollin e sulmuesit. Patchstack ka lëshuar rregulla zbutjeje për të mbrojtur kundër shfrytëzimit.

Në versionet e prekura, Elementor çaktivizon mbrojtjen e vetme CSRF të bërthamës së WordPress për kërkesat REST API të vërtetuara me cookie sa herë që vargu literal elementor/v1/events/ shfaqet kudo në URI-n e kërkesës. Për shkak se URI-ja e kërkesës përfshin vargun e pyetësorit, dhe vargu i pyetësorit shkruhet nga kushdo që harton lidhjen, çdo kërkesë REST mund të përjashtojë veten nga kjo mbrojtje duke shtuar një parametër që duket i padëmshëm. Kodi i cenueshëm ndodhet në modulin Editor Events, i cili përfaqëson telemetrinë e redaktorit të Elementor. Moduli është i fshehur nga ekrani Experiments i faqes, por është i aktivizuar si parazgjedhje për çdo faqe instalimi i parë i Elementor i së cilës ishte versioni 3.32.0 ose më vonë, kështu që një instalim i parazgjedhur i 4.3.0 ose 4.3.1 është i prekur. Konstruktori i modulit regjistron filtrin pa kushte, që do të thotë se asnjë cilësim telemetrie në faqe nuk e parandalon atë. Versionet para 4.3.0 nuk e përfshijnë këtë proxy dhe nuk janë të cenueshme.

Problemi kryesor është koha. Proxy-ja e ngjarjeve regjistron dy rrugë REST dhe dëshiron që kërkesat e veta të përjashtohen nga kontrolli REST nonce. Për ta arritur këtë, ajo lidh rest_authentication_errors në prioritetin 0, përpara se WordPress të ketë përputhur ndonjë rrugë. Funksioni i kthimit kontrollon nëse URI-ja e papërpunuar e kërkesës përmban vargun elementor/v1/events/, duke përdorur një kërkim nënvargu të paankoruar. Meqenëse vargu i pyetësorit është plotësisht nën kontrollin e sulmuesit, një emër dhe vlerë parametri mund të ndërtohen për të plotësuar këtë kontroll ndërsa kërkesa dërgohet në një pikë fundore krejtësisht të ndryshme. Pasi kontrolli kalon, funksioni i kthimit kthen true, që u tregon të gjithë trajtuesve të mëvonshëm të vërtetimit, përfshirë verifikimin e nonce të bërthamës së WordPress, se vërtetimi tashmë ka pasur sukses. permission_callback i rrugës ende ekzekutohet, kështu që lejet e vetë viktimës përcaktojnë se çfarë mund të bëjë sulmuesi. Autorizimi mbetet i paprekur; vetëm prova e qëllimit është zhdukur.

Sulmi përshtatet plotësisht brenda një URL-je sepse bërthama e WordPress pranon një parametër pyetësori _method që anashkalon foljen HTTP. Një navigim normal GET mund të kryejë kështu shkrime. Studiuesit e Patchstack demonstruan një URL që krijon një përdorues të re me rolin administrator: kërkesa synon /wp-json/wp/v2/users dhe shton _method=POST, plus parametra për emrin e përdoruesit, emailin, fjalëkalimin dhe rolet. Parametri i fundit, x=elementor/v1/events/, është e vetmja pjesë që ka rëndësi. Pa të, WordPress kthen HTTP 401 me rest_cannot_create_user. Me të, serveri kthen HTTP 201 dhe një objekt përdoruesi, grupi i roleve i të cilit është ["administrator"]. Studiuesi gjithashtu konfirmoi se një shënues një karakter më i shkurtër se hapësira e emrit të vërtetë, elementor/v1/event/, refuzohet, duke përjashtuar çdo shpjegim tjetër për ndryshimin. Për shkak se një etiketë e vetme ankorimi është e mjaftueshme, ngarkesa mund të dorëzohet kudo ku mund të shkojë një lidhje: një email, një mesazh chat-i, një postim në forum ose një koment në një faqe të palidhur. Viktima sheh një lidhje normale dhe një përgjigje JSON.

Ndikimi është më i gjerë se pikat fundore të vetë Elementor. Anashkalimi ekzekutohet përpara se WordPress të drejtojë kërkesën, kështu që zbatohet për të gjithë sipërfaqen e REST API të faqes: rrugët e bërthamës së WordPress dhe rrugët e çdo shtojce tjetër të instaluar bashkë me të. Krijimi i një administratori përmes /wp/v2/users është demonstrimi më i qartë, por raporti i Patchstack tregoi gjithashtu se GET /wp-json/wp/v2/settings kthehet nga HTTP 401 në HTTP 200 me cilësimet e faqes në trupin e përgjigjes. Çdo veprim që llogaria e viktimës mund të kryejë përmes REST është në fushëveprim, përfshirë pikat fundore që u përkasin shtojcave që nuk bënë asgjë të gabuar.

Elementor rregulloi dobësinë në versionin 4.3.2. Kontrolli zëvendësues lexon $wp->query_vars['rest_route'], që është rruga që WordPress zgjidhi në të vërtetë pas rishkrimit, me vargun e pyetësorit tashmë të ndarë. Asnjë tekst i hartuar nga sulmuesi nuk mbetet në vlerën që testohet. Krahasimi gjithashtu ndryshoi nga një kërkim i lirshëm nënvargu në një kontroll të ankoruar që rruga fillon me /elementor/v1/events/. Një mbrojtës is_string mbyll derën për dërgimin e rest_route si grup. Si burimi i hyrjes ashtu edhe krahasimi i ankoruar kanë rëndësi; rregullimi i vetëm njërit do të kishte lënë një version më të vogël të të njëjtit bug.

Shkaku rrënjësor është një mospërputhje midis një pyetjeje dhe të dhënave të disponueshme për t'iu përgjigjur asaj. Kodi donte të dinte nëse një kërkesë ishte për rrugën e vet, por pyeti në një pikë të ciklit të jetës së kërkesës ku WordPress nuk e kishte vendosur ende këtë, dhe u kënaq me një kërkim nënvargu mbi një varg që kontrollohet nga klienti. Dy mësime përgjithësohen përtej Elementor. Së pari, $_SERVER['REQUEST_URI'] është input i kontrolluar nga sulmuesi, jo metadata e drejtimit; çdo vendim sigurie i bazuar në të duhet të heqë vargun e pyetësorit dhe të ankorojë krahasimin. Së dyti, rest_authentication_errors është një kanal i përbashkët, dhe kthimi i një vlere të vërtetë në të nuk është një përjashtim lokal; ai deklaron sukses për çdo trajtues në rrjedhën e mëvonshme, përfshirë verifikimin e nonce të bërthamës së WordPress. Një filtër që ka nevojë vetëm të thotë 'pa mendim' duhet të kthejë rezultatin origjinal të pandryshuar. Patchstack mori raportin më 2026-09-22, Elementor lëshoi versionin 4.3.2 më 2026-09-24, dhe këshilla publike u publikua më 2026-09-25. Rekomandimi është të përditësoni Elementor në versionin 4.3.2 ose më të lartë menjëherë.

Për pronarët e faqeve, kjo dobësi është një kujtesë se shtojcat e përdorura gjerësisht janë objektiva tërheqës dhe se një shtojcë e vetme e vjetruar mund të vërë në rrezik të gjithë faqen. Shërbimet e hostimit të menaxhuar të WordPress si AEU Hosting, që ofron hostim të menaxhuar WordPress nga fillimi në fund të siguruar, mund të jenë një pjesë e dobishme e një rutine sigurie që përfshin përditësime të shpejta të shtojcave dhe monitorim.