WordPress rregullon XSS në login që mund të mundësojë ekzekutim kodi

WordPress ka rregulluar një dobësi të reflektuar cross-site scripting (XSS) para-autentikimi në ekranin e hyrjes që prek çdo version të sistemit të menaxhimit të përmbajtjes (CMS), sipas studiuesve të sigurisë në pwn.ai të cilët raportuan gjetjet e tyre për The Hacker News. E meta, e gjurmuar si CVE-2026-64638 me një vlerësim CVSS 8.9, nuk kërkon privilegje sulmuesi. Pasi një emër përdoruesi i krijuar posaçërisht arrin faqen e gabimit të hyrjes së dështuar, kodi JavaScript që rezulton ekzekutohet në shfletuesin e vizitorit pa kërkuar ndërveprim të mëtejshëm në atë faqe.

Pasojat më të rënda janë se ky XSS mund të zinxhirohet në ekzekutim kodi PHP në server kur një administrator i identifikuar ndërvepron me një faqe të kontrolluar nga sulmuesi. PHP është gjuha programuese në anën e serverit që WordPress përdor për të ndërtuar dhe ekzekutuar faqet e internetit, kështu që ekzekutimi i saj i jep sulmuesit kontroll mbi faqen. Në demonstrimin e pwn.ai, ky ndërveprim është një klikim i zakonshëm. Studiuesit thanë se sulmi funksionon kundër instalimeve të parazgjedhura të WordPress dhe nuk kërkon cilësime të pazakonta hostimi ose vendosjeje. Ata përshkruan shtigje të shumta nga XSS në ekzekutim kodi, duke përfshirë variante që instalojnë një shtojcë ose ngarkojnë një arkivë ZIP arbitrare.

Këshilla e WordPress mban një qëndrim më të kujdesshëm ndaj shfrytëzueshmërisë, duke vënë në dukje se përshkallëzimi në ekzekutim kodi në distancë përfshin kushte jashtë kontrollit të sulmuesit dhe kërkon inxhinieri sociale të suksesshme plus ndërveprim të qartë të viktimës. Problemi u rregullua më 6 gusht në WordPress 7.0.3, me rregullime të bartura përmes degës 4.7. WordPress rekomandon përditësimin menjëherë, dhe faqet që mbështesin përditësime automatike në sfond duhet ta marrin versionin e sigurisë automatikisht. Versionet më të vjetra se 4.7 mbeten të prekura por bien jashtë gamës aktuale të bartjes së projektit.

pwn.ai, e cila e quan zinxhirin e sulmit XSS2Shell, tha se sistemi i saj autonom zbuloi dhe riprodhoi zinxhirin e dobësisë pasi iu dha si pikënisje kërkimi i Paulos Yibelo i vitit 2022 mbi Same Origin Method Execution (SOME). Kompania tha se puna zgjati pothuajse katër ditë duke përdorur modele me burim të hapur dhe një rrjedhë pune me shumë agjentë. Zinxhiri u riprodhua më 26 korrik dhe u raportua në WordPress të nesërmen.

E meta fillon në mënyrën se si WordPress trajton emrin e përdoruesit nga një hyrje e dështuar. Sipas studiuesve, vlera kalon përmes sanitize_user() dhe wp_strip_all_tags(), e cila mbështetet në strip_tags() të PHP. Një varg i ngjashëm me etiketë që përmban hapësirë pas < hapëse mund të mbijetojë atë analizues si tekst. Më vonë, WordPress e kalon vlerën përmes wp_kses_post(), analizuesi i të cilit i veçantë e interpreton të njëjtin input si HTML të lejuar. Rezultati është elementë DOM të gjallë të kontrolluar nga sulmuesi në faqen e hyrjes së dështuar. Këta elementë më pas ndërveprojnë me user-profile.js të vetë WordPress, një skript për menaxhimin e profilit që ngarkohet gjithashtu në faqen e hyrjes sepse faqja trajton rivendosjen e fjalëkalimit. Disa elementë profili që skripti pret mungojnë atje: dy inpute që mungojnë të dy zgjidhen në undefined, duke lejuar që një kontroll barazie të kalojë, ndërsa ndryshorja ajaxurl përndryshe e papërcaktuar mund të mbulohet me një element DOM të injektuar. Kjo e drejton JavaScript-in e vetë WordPress drejt një kërkese REST të zgjedhur nga sulmuesi në të njëjtin origjinë. Studiuesit përdorin mbështetjen JSONP të REST të WordPress për ta kthyer atë kërkesë në JavaScript që ekzekutohet në origjinën e faqes. Për vendosjet ku kërkesat anonime REST kthejnë HTTP 401, parametri _envelope=1 mund ta mbështjellë mohimin në një përgjigje të jashtme HTTP 200, duke lejuar jQuery të vazhdojë përpunimin e përgjigjes si skript. Studiuesit gjithashtu zbuluan në testimet e tyre se një Content Security Policy e bazuar në nonce që përdor strict-dynamic nuk bllokoi shtegun e demonstruar.

Shtegu nga XSS në ekzekutim PHP ndërtohet mbi teknikën e mëparshme SOME të Yibelo, e cila përdor një zinxhir të lejuar të vetive JSONP për të thirrur një metodë në një dritare tjetër të shfletuesit. Një shteg i demonstruar nga pwn.ai përdor XSS-në në origjinën e WordPress për të thirrur kontrollin vendas të miratimit të Application Password brenda sesionit të një Administratori të identifikuar. WordPress më pas krijon një kredencial API dhe e ridrejton atë në një success_url HTTPS të zgjedhur nga sulmuesi. Application Passwords janë kredenciale të anulueshme të destinuara për akses API, kështu që ky shteg nuk ka nevojë të vjedhë fjalëkalimin kryesor të administratorit. Studiuesit përdorën kredencialin për akses REST të autentikuar për të publikuar një faqe WordPress që përmban JavaScript në të njëjtën origjinë. Kur sesioni i mbajtur i administratorit hapi atë faqe, skripti i saj mori nonce-n e ngarkimit të shtojcave të WordPress dhe ngarkoi një ZIP të furnizuar nga sulmuesi. PHP më pas mund të kërkohej drejtpërdrejt nga shtojca e nxjerrë. Shtojca nuk kishte nevojë të aktivizohej.

Provat e prodhimit të dhëna për The Hacker News ndalen në XSS. Studiuesit riprodhuan veçmas XSS-në e faqes së hyrjes pa cookie kundër dy vendosjeve të WordPress 7.0.2 në profile të reja Chrome pa cookie ose kredenciale WordPress. Ata nuk u përpoqën të krijonin Application Password, të ngarkonin skedarë, të ruajnë vazhdimësi ose të ekzekutojnë PHP në ato sisteme. Zinxhiri i plotë i ekzekutimit PHP u demonstrua veçmas në një instalim të pastër lokal të WordPress 7.0.2.

Një ekzekutim i suksesshëm PHP do të ekspozonte kredencialet e bazës së të dhënave të WordPress në wp-config.php, do të lejonte krijimin e vazhdueshëm të administratorëve dhe ndryshime përmbajtjeje, do të ekspozonte skedarë dhe sekrete të lexueshme nga punëtori PHP, dhe do të lejonte komanda të sistemit operativ me privilegjet e atij punëtori. Studiuesit thanë se masat e njohura të forcimit të WordPress nuk duhet të trajtohen si një zbutje e plotë për XSS-në themelore dhe se aplikimi i përditësimit të sigurisë është i nevojshëm.

WordPress vlerësoi ekipin në pwn.ai për zbulimin dhe zbulimin e përgjegjshëm të dobësisë. Që nga 7 gushti, këshilla e projektit nuk raporton shfrytëzim në natyrë. Për pronarët e faqeve në hostim të menaxhuar WordPress, një shërbim si AEU Hosting fokusohet në mbajtjen e platformës të përditësuar dhe të forcuar, që është pikërisht lloji i mbrojtjes që ka rëndësi për të meta si kjo.