Prova e WordPress CVE-2026-87902 filloi disa orë pas rregullimit

Sulmuesit filluan të provonin faqe WordPress për një dobësi kritike të njohur si CVE-2026-87902 më pak se pesë orë pasi u publikua versioni i rregulluar, sipas një raporti të ri nga Patchstack. E meta është një problem i përfshirjes së skedarëve lokalë pa autentikim në mënyrën se si WordPress zgjidh shabllonet e faqeve, dhe prek versionet bazë të WordPress nga 4.7.0 deri në 7.1.1. Një dobësi e përfshirjes së skedarëve lokalë lejon një sulmues në distancë të bëjë një faqe interneti të lexojë një skedar që nuk duhet, gjë që në këtë rast mund të çojë në ekzekutim kodi në distancë në disa kushte. WordPress e rregulloi problemin në versionin 7.1.2, me rregullime të sjella edhe për degët më të vjetra duke përfshirë 7.0.6, 6.9.9, 6.8.10 dhe deri në 4.7.37. Dobësia ka pikë 9.2 në shkallën CVSS, është pa autentikim, dhe Patchstack e liston statusin e shfrytëzimit si provim aktiv i vëzhguar.

Dobësia qëndron në mënyrën se si WordPress ndërton një kandidat shablloni faqe nga një parametër URL i quajtur pagename. Dave Jong, Drejtues i Kërkimit të Sigurisë në Patchstack, shpjegon se problemi kryesor është një kalim rrugësh që çon në përfshirje skedari lokal. Në trafikun e zakonshëm, një URL si /?page_id=1&pagename=about i tregon WordPress se cilën faqe të shfaqë. Një sulmues mund të përdorë në vend të kësaj një vlerë pagename të ndërtuar posaçërisht që fillon me templates%252f e ndjekur nga sekuenca të koduara pikë-pikë-vijë. Kodimi i dyfishtë ka rëndësi: WordPress fillimisht e kalon slug-un nëpër një pastrues që heq pikat e drejtpërdrejta dhe pret në vijat e drejtpërdrejta, por ruan oktetë e koduara me përqindje. Më vonë, get_page_template() i dekodon ato okte dhe kalimi rrugësh del nga drejtoria e temës për të përfshirë një skedar arbitrar. Sulmuesi duhet gjithashtu të japë një page_id të vlefshëm që zgjidhet në një faqe reale, sepse përndryshe WordPress kthen një 404 përpara se të arrihet rruga e kodit të dobët.

Patchstack thotë se përpjekja e parë e provimit arriti në regjistrat e tyre në 17:44 UTC më 22 shtator 2026, më pak se pesë orë pasi u publikua WordPress 7.1.2. Ngarkesat përputhen me kodimin e saktë që adreson rregullimi, gjë që sugjeron se kushdo që i ndërtoi po punonte nga ndryshimi i kodit dhe jo nga një zbulim i pavarur. Deri tani, çdo kërkesë e vëzhguar e drejton përfshirjen në një skedar të zakonshëm bazë të WordPress: wp-links-opml.php, wp-includes/functions.php ose wp-cron.php. Asnjë prej këtyre skedarëve nuk i jep sulmuesit asgjë më vete, por funksionojnë si një test i lirë po-ose-jo. Për shembull, wp-links-opml.php lëshon një dokument OPML të veçantë, kështu që shfaqja e atij rezultati nga një URL normale faqe konfirmon se përfshirja pati sukses. Patchstack e përshkruan këtë si zbulim informacioni, jo si dërgim ngarkese: dikush po ndërton një listë hostesh të shfrytëzueshme. Hapi më i rrezikshëm, drejtimi i të njëjtit truk në një skedar si pearcmd.php në një server me register_argc_argv të aktivizuar, nuk është shfaqur ende në të dhënat e Patchstack, por kompania pret që ai të pasojë sapo të kthehen rezultatet e skanimit.

Kërkesat e vëzhguara ndajnë dy detaje treguese. Së pari, ato janë të koduara dyfish në shtresën HTTP, prandaj %252e%252e shfaqet në regjistra në vend të një sekuence të thjeshtë ../. Patchstack thotë se kjo e bën %252e%252e një varg me zhurmë të ulët për t'u kërkuar. Së dyti, çdo kërkesë çifton pagename me page_id, sepse kalimi rrugësh i vetëm nuk mjafton për të arritur kodin e dobët. Vlera pagename fillon me templates%252f, duke vazhduar një drejtori reale që fillon me page- përpara se të dalë nga tema. Patchstack ka parë thellësi kalimi rrugësh nga tre deri në shtatë nivele, me gjasë për t'u përshtatur me faqosje të ndryshme instalimi, dhe kodime heksadecimale të mëdha e të vogla. Kërkesat vijnë përmes GET dhe POST, sepse WordPress e lexon pagename nga trupi i POST-it me përparësi ndaj vargut të kërkesës. Ato gjithashtu shkojnë drejtpërdrejt në /index.php si dhe në rrënjën e faqes. Aktiviteti erdhi nga një grup i vogël adresash burimore që goditën shumë faqe të mbrojtura, me pjesën më të madhe të volumit të përqendruar në dy adresa fqinje IPv4, 169.58.48.193 dhe 169.58.48.195, dhe disa trafik IPv6 nga 2001:df1:e8c0::106b. Shumica e kërkesave mbanin një user agent Go-http-client/1.1, me një pjesë më të vogël që përdornin vargje shfletuesi të falsifikuara. Aktiviteti arriti kulmin në orën e parë dhe u pakësua pas kësaj, gjë që Patchstack thotë se është forma e zakonshme për një skanim oportunist përmes një liste të përgatitur hostesh dhe jo një fushatë e synuar.

Patchstack thotë se klientët e tij mbrohen nga një rregull RapidMitigate, një rregull sigurie që bllokon automatikisht modelet e njohura të sulmit për faqet e mbrojtura, por për të gjithë të tjerët rregullimi është të përditësojnë në WordPress 7.1.2 ose versionin e rregulluar në degën e tyre. WordPress e solli rregullimin deri në 4.7.37, kështu që çdo degë e prekur ka një version të rregulluar dhe një faqe më e vjetër mund ta marrë pa kërcyer në një version të madh. Pronarët e faqeve mund të kontrollojnë dy parakushte nga shkrimi origjinal përpara përditësimit: nëse tema aktive ka një drejtori page- në nivelin kryesor, dhe nëse PHP ka register_argc_argv të aktivizuar. Nëse përditësimi i menjëhershëm nuk është i mundur, refuzimi i sekuencave të kalimit rrugësh në parametrin pagename është një zgjidhje e përkohshme efektive sepse një slug real faqe nuk përmban kurrë një të tillë. Për të gjuajtur në regjistrat ekzistues, Patchstack liston treguesit me sinjalin më të lartë: një parametër pagename që përmban %252e%252e në vargun e kërkesës ose trupin e POST-it, një vlerë pagename që fillon me templates%252f ose një emër tjetër drejtorie page-, pagename dhe page_id që shfaqen së bashku në rrënjën e faqes ose /index.php, dhe rezultat OPML ose çdo rezultat tjetër i papritur skedari bazë i kthyer nga një URL normale faqe. I fundit ju tregon nëse një provim pati sukses: një përgjigje 200 që mban OPML aty ku duhej të ishte një faqe do të thotë se përfshirja funksionoi në atë host, dhe faqja duhet ta trajtojë atë si një dritare të konfirmuar dobësie dhe jo si një përpjekje të bllokuar. Faqet e ekspozuara përpara rregullimit ose zbutjes duhet të rishikojnë regjistrat historikë mbi atë bazë dhe të kontrollojnë për skedarë të papritur ose të modifikuar.

Kronologjia e Patchstack tregon se WordPress 7.1.2 dhe këshilla GHSA-7hp8-65ch-5whp u publikuan më 22 shtator 2026. Dobësia u shtua në bazën e të dhënave të Patchstack dhe një rregull RapidMitigate u vendos për faqet e mbrojtura të njëjtën ditë. Përpjekja e parë e shfrytëzimit u vëzhgua dhe u bllokua në 17:44 UTC, dhe aktiviteti më i fundit në momentin e shkrimit ishte 19:51 UTC. Patchstack po vazhdon të monitorojë për një kalim nga provat e skedarëve bazë në objektiva përfshirjeje që bëjnë diçka të vërtetë, dhe thotë se do të përditësojë nëse kjo ndryshon. Për pronarët e faqeve në hosting WordPress të menaxhuar si AEU Hosting, përditësimet bazë dhe monitorimi i sigurisë në nivel serveri mund të shkurtojnë dritaren midis publikimit të një rregullimi dhe zbatimit të tij, gjë që është pikërisht ajo që zvogëlon ekspozimin ndaj provimeve të shpejta si kjo.