Fushata XSS në WordPress instalon llogari administratori të fshehura
Një fushatë XSS në WordPress e vëzhguar për herë të parë nga Patchstack më 4 tetor 2026 po përdor defekte të ruajtura të skriptimit ndër-site në dy shtojca të palidhura për të instaluar një llogari administratori që pronarët e faqeve nuk mund ta shohin në wp-admin. E njëjta ngarkesë JavaScript, e dorëzuar përmes të dyja dobësive, tërhiqet nga imgcdn1.com dhe u mor dhe u analizua nga Patchstack. Është një implant post-shfrytëzimi dhe persistencë i projektuar për të ekzekutuar në shfletuesin e një administratori të identifikuar, për të abuzuar atë sesion administratori për të instaluar një shtojcë me qëllim të keq, për të krijuar një administrator të fshehur, për të shtuar një URL hyrjeje backdoor dhe për të raportuar rezultatet në infrastrukturën e kontrolluar nga sulmuesi.
Dobësia e parë e shfrytëzuar është CVE-2026-93836, një XSS e ruajtur e paautentikuar në WPC Product Bundles për WooCommerce deri në versionin 8.6.6. Defekti lejon që një vlerë sasie që fillon me një numër të vlefshëm të kalojë validimin ndërsa mbart gjithashtu markup të kontrolluar nga sulmuesi. Vlera ruhet në metadata e porosisë WooCommerce dhe më vonë paraqitet në mënyrë të pasigurt. Patchstack pa kërkesa më 4 tetor që furnizonin ngarkesën përmes parametrit woosb_ids[…][qty], me një parashtesë numerike të ndjekur nga një etiketë skripti që ngarkon x.js nga imgcdn1.com. Të nesërmen, e njëjta ngarkesë u shfaq përmes CVE-2026-94504 në Ninja Forms deri në versionin 3.15.3. Ninja Forms ruante parashtresat e textarea dhe mund t'i paraqiste ato pa kodim të sigurt HTML në redaktorin e vjetër administrativ të parashtresave. Versioni 3.15.4 forcoi escapimin e daljes. Sulmuesi dorëzoi ngarkesën përmes pikës normale AJAX të Ninja Forms në /wp-admin/admin-ajax.php me action=nf_ajax_submit, duke futur një etiketë imazhi me një mbajtës onerror që krijon një element skripti dhe ngarkon të njëjtin x.js. Dy ngarkuesit ndryshojnë sepse sulmuesit përshtaten me çdo kontekst të cenueshëm, por faza e dytë e centralizuar i lidh të dyja përpjekjet me një fushatë.
x.js i marrë është një skript post-shfrytëzimi dhe persistencë i ndërtuar posaçërisht për WordPress, i obfuskuar lehtë me tabela vargjesh të koduara dhe kërkime indirekte funksionesh. Rrjedha e tij është: XSS e ruajtur në wp-admin, zgjidh origjinën, kontrollo me serverin komandë-dhe-kontroll (C2), instalo shtojcën, krijo administratorin, merr emer-run.php dhe raporto përsëri. JavaScript-i nuk ka nevojë për një dobësi të dytë në anën e serverit; ai përdor funksionalitetin legjitim administrativ të WordPress përmes sesionit ekzistues të autentikuar të administratorit.
Malware-i nuk vjedh kurrë cookie-n e administratorit të WordPress. Për shkak se JavaScript-i ekzekutohet në kontekstin e sigurisë së faqes së komprometuar, kërkesat me origjinë të njëjtë drejt /wp-admin/ mbajnë automatikisht sesionin e përdoruesit të identifikuar. Skripti ngarkon faqe të privilegjuara WordPress, mbledh nonce-t CSRF, të cilat janë shenja sigurie njëpërdorimshe që veprimet legjitime administrative kërkojnë, dhe i riprodhon ato për të kryer vetë ato veprime. Cookies HttpOnly, një mbrojtje e shfletuesit që ndalon JavaScript-in të lexojë cookies, nuk ndihmojnë sepse skripti nuk e lexon kurrë cookie-n; ai thjesht shfrytëzon sesionin.
Para çdo veprimi persistence, malware-i kontakton https://imgcdn1.com/fz/c.php?xa=check&site=. Përgjigja përmban fusha gjendjeje duke përfshirë plugin, admin, emer dhe skip, të cilat lejojnë C2 të vendosë se cilat faza kanë pasur tashmë sukses për një viktimë. Malware-i gjithashtu ruan gjendjen lokale të ekzekutimit në shfletues nën një çelës Local Storage që fillon me __xp_v9_, duke gjurmuar fazat e suksesshme si plugin, admin dhe emer, dhe përfundimisht duke shënuar një kompromis të përfunduar si all. Të dhënat e statusit dërgohen duke përdorur fetch(), navigator.sendBeacon() dhe një kërkesë imazhi si rezervë, kështu që C2 merr rezultate edhe nëse navigimi ndërpret ekzekutimin.
Duke përdorur sesionin e viktimës, skripti ngarkon /wp-admin/plugin-install.php?tab=upload, mbledh nonce-n e ngarkimit, tërheq një ZIP nga https://imgcdn1.com/fz/c.php?xa=pkg dhe e dorëzon atë përmes instaluesit të vetë shtojcave të WordPress. Patchstack mori dhe analizoi paketën. Ajo instalohet në slug-un wp-smart-thumbnails dhe përmban katër skedarë: wp-smart-thumbnails.php (20,728 bajt, dropper i paketuar dhe menaxher skedarësh), emer-run.php (14,330 bajt, instalues persistence), readme.txt (46 bajt, karrem) dhe includes/class-thumb-cache.php (41 bajt, karrem). Shtojca paraqitet si WP Smart Thumbnails 1.2.4 nga "MediaPress Labs", një shtojcë për caching miniaturash responsive, por skedari i funksionalitetit përmban vetëm një roje ABSPATH, dhe readme.txt është dy rreshta. Çdo skedar ka vulë kohore korrik 2026, muaj para fushatës, gjë që përputhet me prapavendosje të qëllimshme të datave. Skedari kryesor i shtojcës hapet me një roje të përmbysur: nëse ABSPATH është i përcaktuar, ai kthehet, kështu që ngarkesa nuk ekzekutohet kurrë ndërsa WordPress ngarkon shtojcën. E instaluar dhe aktive, ajo nuk bën asgjë; ajo shpërthen vetëm me një kërkesë të drejtpërdrejtë HTTP, siç thotë komenti i vetë sulmuesit.
Nën atë roje qëndron një blob i vetëm base64. Ai dekodohet nga base64, XOR-ohet kundër një çelësi 26-bajtësh, kthehet mbrapsht, kalon përmes ROT13, dekodohet nga base64 dy herë të tjera, rrotullohet me dy bajt dhe dekompresohet me gzuncompress, pastaj kontrollohet kundër një MD5 të koduar fort para se të ekzekutohet. Ai kontroll i fundit është roja e integritetit e vetë autorit, dhe faza e shpaketuar e Patchstack përputhet me të. Në vend të eval(), dropper-i regjistron një mbështjellës të personalizuar stream dhe përfshin kodin burimor të dekoduar përmes një URL dyiv://, duke shmangur rregullat që shikojnë për eval() në hyrje të dekoduar. Faza e shpaketuar është afërsisht 37 KB: një menaxher skedarësh grafik me titull "Moon, tell me if I could", duke ofruar listim, ngarkim, fshirje, riemërtim, mkdir, lexim dhe ruajtje mbi një API JSON. Nuk ka asnjë lloj autentikimi. Asnjë fjalëkalim, asnjë shenjë, asnjë kontroll aftësie; testi i vetëm i barazisë në një çelës është një mbajtës JavaScript për tastin Escape. Nuk ka primitivë të ekzekutimit të komandave, por ngarkimi dhe ruajtja mund të shkruajnë bajt të furnizuar nga sulmuesi në çdo shteg të shkrueshëm, mjaftueshëm për të hedhur një shell të dytë.
emer-run.php është vendi ku ndërtohet persistenca e qëndrueshme. Mbi HTTP ai bootstrap-on WordPress-in, kërkon current_user_can('administrator') dhe kthen JSON, që është arsyeja pse x.js e thërret atë nga brenda sesionit të administratorit. Nga linja e komandës ose WP-CLI ai e anashkalon plotësisht kontrollin e aftësisë. Komenti i tij i kokës thotë "hidden admin + magic login (invoked via XSS admin session). Returns JSON only; drops obfuscated MU-plugins." Ai bën tre gjëra. Së pari, krijon një llogari administratori të ndërtuar për t'u dukur rutinë: një emër përdoruesi i zgjedhur rastësisht nga një fjalor prej rreth pesëdhjetë fjalësh operacionale të padëmshme si support, updater, maintenance dhe backup, me një adresë emaili @wordpress.org dhe një fjalëkalim të rastësishëm 16-karakterësh. Së dyti, e fsheh atë llogari nga pronari i faqes. Skripti shkruan një shtojcë must-use në wp-content/mu-plugins/class-wp-query-.php, ku heksi rrjedh nga emri i përdoruesit. Ai skedar instalon tre grepa: pre_user_query shton AND user_login != '' në SQL-in e pyetjes së përdoruesit; users_list_table_query_args shton llogarinë në login__not_in; views_users zvogëlon numërimet e roleve të shfaqura mbi listë. Llogaria nuk shfaqet në Users → All Users, nuk shfaqet në filtrin Administrator dhe nuk numërohet në totalet mbi listë. Është një administrator plotësisht i privilegjuar që pronari i faqes nuk mund ta shohë. Shtojcat must-use ngarkohen në çdo kërkesë, nuk mund të çaktivizohen nga wp-admin dhe nuk listohen kurrë në ekranin Plugins; heqja e wp-smart-thumbnails nuk i heq ato. Së treti, krijon një URL hyrjeje magjike në /wp-login.php?_wplogin=, e mbështetur nga një shtojcë e dytë must-use, class-wp-token-validate.php. Shenja jeton në opsionin fz_emer_login_tokens, dhe shtojca lidh init në prioritet 1 për ta shkëmbyer atë me një cookie sesioni. Ajo shenjë nuk është e lidhur me llogarinë e fshehur; ajo është e lidhur me administratorin më të vjetër ekzistues në faqe, kështu që kushdo që mban URL-në identifikohet në heshtje si pronari origjinal, në një sesion të padallueshëm nga një i vërtetë nga regjistrat që shënojnë vetëm një ID përdoruesi. Të dyja shtojcat must-use shkruhen të obfuskuara, si blob-e XOR-plus-gzdeflate me emra variablash të rastësishëm dhe një çelës të freskët për faqe, kështu që asnjë dy faqe të infektuara nuk ndajnë një hash. Secila prej tyre pastaj prapavendoset me datë: skripti skanon rrënjën e WordPress, merr kohën më të vjetër të modifikimit që gjen dhe e vulos atë mbi skedarin që sapo hodhi. Implantet përfundojnë duke u dukur si skedarët më të vjetër në sistem, duke mposhtur gjuetinë e zakonshme për skedarë të ndryshuar së fundmi.
Një ekzekutim i vetëm i suksesshëm i XSS-së së ruajtur i lë sulmuesit katër rrugë të pavarura për t'u kthyer në faqe, vetëm njëra prej të cilave është e dukshme nga paneli i WordPress: administratori i dukshëm i krijuar përmes user-new.php me kredenciale të furnizuara nga C2; administratori i fshehur i krijuar nga emer-run.php dhe i fshehur nga një shtojcë must-use; URL-ja e hyrjes magjike, e cila autentikon mbajtësin si administratori më i vjetër i faqes; dhe menaxheri i skedarëve i paautentikuar në vetë shtojcën, i arritshëm me kërkesë të drejtpërdrejtë. Heqja e shtojcës së cenueshme, apo edhe e asaj me qëllim të keq, nuk mbyll asnjë nga tre të fundit.
XSS e ruajtur i përshtatet kësaj fushate sepse heq pjesën më të vështirë të sulmit: marrjen e një përdoruesi të privilegjuar për të bashkëpunuar. Një XSS e reflektuar ka nevojë që viktima të vizitojë një URL të kontrolluar nga sulmuesi, ndërsa një XSS e ruajtur është tashmë brenda aplikacionit, duke qëndruar në të dhëna që administratorët i hapin si pjesë e punës së tyre: një porosi WooCommerce në rastin e parë, një parashtresë Ninja Forms në të dytin. Ajo shkrehet në momentin që ata shikojnë. Ky dallim ka pasur rëndësi për WordPress Core kohët e fundit. Në shtator 2026, WordPress 7.1.1 rregulloi një XSS të ruajtur të paautentikuar në wpautop() që lejonte skriptin e kontrolluar nga sulmuesi të persistonte përmes përmbajtjes së komenteve, subjekt i miratimit të komenteve. Modeli i sulmit është: sulmuesi dorëzon të dhëna, WordPress i ruan ato, sulmuesi pret, administratori i shikon ato, ngarkesa ekzekutohet në wp-admin, kompromis i qëndrueshëm. Cila shtojcë ofron XSS-në fillestare mezi ka rëndësi; sapo JavaScript-i ekzekutohet brenda një origjine administrative të autentikuar, faza post-shfrytëzuese është identike, që është arsyeja pse këta sulmues mbledhin dobësi XSS të ruajtura në vend që të ndërtojnë një zinxhir të veçantë malware për çdo shtojcë.
Një domen i vetëm mbart çdo fazë të fushatës. Pikat fundore në imgcdn1.com përfshijnë /fz/x.js (implant post-shfrytëzimi i bazuar në shfletues), /fz/c.php?xa=check (gjendja e viktimës dhe detyrat), /fz/c.php?xa=pkg (paketa e shtojcës me qëllim të keq), /fz/c.php?xa=admin_creds (kredencialet e administratorit të zgjedhura nga sulmuesi) dhe /fz/c.php (raportimi i kompromisit). Domeni u regjistrua më 1 tetor 2026, dhe një shërbim publik indeksimi DNS e liston atë midis domeneve të deleguara te nameserver-i Cloudflare hazel.ns.cloudflare.com më 2 tetor. Patchstack e pa atë të përdorur në shfrytëzim dy ditë më vonë. Të dyja dobësitë ishin shpallur publikisht më 22 shtator, afërsisht dhjetë ditë para se të shfaqej domeni; koha përputhet me infrastrukturën e ngritur posaçërisht për këtë fushatë.
Deri në publikim, Patchstack ka konfirmuar këtë infrastrukturë shpërndarjeje përmes të paktën dy dobësive të veçanta XSS të ruajtura, dhe vëllimi i shfrytëzimit mbetet i kufizuar në telemetrinë e tyre. Asnjë numër nuk është tavan; faza post-shfrytëzuese është agnostike ndaj shtojcave, kështu që çdo XSS e ruajtur që vendos JavaScript përpara një administratori WordPress është një vektor kandidat për të njëjtin implant. Më 4 tetor, CVE-2026-93836 u shënjestrua nga IP-të 204.8.96.109, 147.90.235.22 dhe 90.184.10.74. Më 5 tetor, CVE-2026-94504 u shënjestrua nga 94.16.115.121 dhe 43.250.53.42. Kërkesa më e hershme në telemetrinë e Patchstack u vëzhgua më 4 tetor në 10:39 UTC, duke shënjestruar një URL produkti WooCommerce dhe duke furnizuar ngarkuesin përmes parametrit woosb_ids në një vlerë të koduar URL që përmban një etiketë skripti. IP-të burimore ndryshojnë ndërsa infrastruktura e fazës së dytë dhe malware mbeten identike, në përputhje me shfrytëzimin e shpërndarë në disa hoste skanimi pas një ngarkese të centralizuar dhe serveri C2. Katër nga pesë adresat janë nyje dalëse Tor që firewall-i i Patchstack i ka bllokuar më parë; e pesta, 43.250.53.42, është e shënuar për aktivitet spam dhe brute-force dhe shfaqet në fushata të tjera të fundit. Bllokimi i këtyre adresave nuk është një zbutje e qëndrueshme më vete. Grupet e synuara ndryshojnë ndjeshëm: WPC Product Bundles ka më shumë se 30,000 instalime aktive, Ninja Forms më shumë se 500,000.
Treguesit e malware të listuar nga Patchstack: mostra e analizuar x.js është 19,378 bajt; SHA-256 af803bc822cf9596b1f1785e1d59642f91f6fbc21f8e9943feefa19a6df8c2a4; MD5 8a4413c1aa058179ff54b95571bcf2a3. Shtojcat must-use janë të obfuskuara me një çelës të freskët për faqe dhe nuk do të përputhen me një hash fiks, kështu që ato listohen sipas shtegut: /wp-content/mu-plugins/class-wp-query- dhe /wp-content/mu-plugins/class-wp-token-validate.php. Ngarkesa është https://imgcdn1.com/fz/x.js, C2 është https://imgcdn1.com/fz/c.php, dhe slug-u i shtojcës me qëllim të keq është wp-smart-thumbnails. Pronarët e faqeve duhet të kërkojnë këta tregues dhe gjithashtu të kontrollojnë për çdo llogari administratori të fshehur, sepse lista e dukshme e përdoruesve mund të mos tregojë pamjen e plotë.
Për pronarët e faqeve që nuk mund të monitorojnë çdo njoftim shtojce gjatë gjithë kohës, një host WordPress i menaxhuar si AEU Hosting mund të ofrojë kopje rezervë automatike dhe forcim sigurie specifik për WordPress për të zvogëluar mundësinë që një përditësim i humbur të kthehet në një llogari administratori të fshehur. Patchstack vazhdon të monitorojë aktivitetin e shfrytëzimit dhe evolucionin e ngarkesës për ndryshime në infrastrukturë, obfuskim dhe teknika post-shfrytëzimi, dhe do të përditësojë raportin e tij ndërsa konfirmohen shtojca të tjera të prekura. Fushata është një kujtesë se patchimi nuk ka të bëjë vetëm me shtojcën e cenueshme, sepse shtresa e persistencës së sulmuesit i mbijeton heqjes së shtojcës.