Sulmuesit shfrytëzuan RCE-në e bërthamës së WordPress-it në 90 minuta

Sulmuesit filluan të shfrytëzojnë një zinxhir kritik të ekzekutimit të kodit në distancë (RCE) në bërthamën e WordPress-it vetëm 90 minuta pasi u publikua versioni i arnuar, sipas një kërkimi të ri nga Patchstack. Shitësi i sigurisë, i cili shet shërbime muri mbrojtës aplikacioni dhe shërbime dobësish për WordPress-in, thotë se ka bllokuar më shumë se 65,000 përpjekje shfrytëzimi kundër dy dobësive themelore në ditët pas zbulimit. Këto përpjekje erdhën nga më shumë se 1,500 adresa unike IP, dhe pothuajse të gjitha synonin faqe të paarnuara që ekzekutonin versione të cenueshme të WordPress-it. Shpejtësia me të cilën filloi fushata e sulmit tregon se pronarët e faqeve kanë pothuajse asnjë kohë midis publikimit të një rregullimi dhe përpjekjes së kriminelëve për të përdorur defektin.

Incidenti përfshin dy defekte të veçanta që mund të kombinohen në një marrje të plotë në zotërim. I pari, CVE-2026-60137, është një injektim SQL në një pjesë të WordPress-it të quajtur WP_Query përmes parametrit author_exclude ose author__not_in. Një injektim SQL ndodh kur një sulmues vendos komanda të bazës së të dhënave në hyrje që faqja më pas i ekzekuton; në këtë rast injektimi është vetëm për lexim, që do të thotë se mund të lexojë informacion nga baza e të dhënave të faqes, por nuk mund të shkruajë drejtpërdrejt në të. Ai defekt prek versionet e WordPress-it 6.8 deri në 7.0.1. Defekti i dytë, CVE-2026-63030, është një konfuzion rruge dhe trajtuesi në pikën fundore të grupit të REST API-së në /batch/v1. REST API është një mënyrë që programet e jashtme të komunikojnë me WordPress-in, dhe pika fundore e grupit lejon që të dërgohen disa veprime njëherësh. Ky defekt prek versionet 6.9 deri në 7.0.1. Vetëm, asnjëri nga defektet nuk i jep sulmuesit kontroll të plotë. Por kur kombinohen, konfuzioni i grupit lejon që një kërkesë e paautentikuar të futë injektimin SQL përtej kontrolleve normale të të dhënave, dhe një shfrytëzim publik më pas krijon një llogari të re administratori dhe përfundimisht arrin ekzekutim kodi në distancë. Rregullimet u lëshuan në WordPress 7.0.2, 6.9.5 dhe 6.8.6. Degët më të vjetra si 6.1 dhe 6.2 nuk preken, sepse kodi i cenueshëm u prezantua vetëm në 6.8 dhe 6.9.

Telemetria e Patchstack tregon se sa shpejt filloi fushata. Rregullimi u krye në trungun e zhvillimit të WordPress-it rreth 1.5 orë para se versioni 7.0.2 të etiketohej për lëshim. Për shkak se çdokush mund të shikojë ndryshimet e kodit, ai angazhim në mënyrë efektive shërbeu si zbulim publik. Përpjekjet e para reale të shfrytëzimit arritën te sensorët e Patchstack rreth 90 minuta pasi u lëshua 7.0.2, dhe tre orë pasi u krye rregullimi. Gjatë ditëve në vijim, Patchstack bllokoi më shumë se 65,000 përpjekje shfrytëzimi nga më shumë se 1,500 adresa unike IP. Kompania vëren se veçoria e saj RapidMitigate aktivizon rregullat e zbutjes vetëm në faqet që ekzekutojnë një version të cenueshëm, dhe i heq ato rregulla pasi faqja është arnuar, kështu që përpjekjet e bllokuara ishin të gjitha drejtuar sistemeve të paarnuara. Trafiku u vu re gjithashtu brenda vetë aplikacionit, që do të thotë se çdo mur mbrojtës në nivel rrjeti ose serveri përpara faqes tashmë e kishte lejuar kërkesën të kalonte. Asnjë rrjet i vetëm nuk dominoi trafikun; rrjeti më i ngarkuar përbënte vetëm 6.45 përqind, dhe dhjetë rrjetet kryesore së bashku përbënin rreth 22 përqind. IP-të sulmuese vinin kryesisht nga ofrues cloud dhe VPS si Vultr (Choopa), M247 dhe HostPapa. Pothuajse i gjithë trafiku i bllokuar ishte provë e hershme e injektimit SQL, por në një faqe të pambrojtur e njëjta kërkesë do të vazhdonte deri në krijimin e administratorit dhe ekzekutimin e kodit.

Trafiku dha një pamje të qartë se si punonin sulmuesit. Pothuajse 97 përqind e gjithçkaje që Patchstack bllokoi synonte pikën fundore të grupit REST. Sulmuesit përdorën dy mënyra kryesore për ta arritur atë: /?rest_route=/batch/v1 dhe /wp-json/batch/v1, me të parën më të zakonshme. Ata gjithashtu spërkatën variante rrugësh si /index.php?rest_route=/batch/v1, /wp/?rest_route=/batch/v1, /blog/?rest_route=/batch/v1 dhe /wp-json?rest_route=/batch/v1 për të kaluar rregullat e thjeshta të filtrimit. Rreth tre të katërtat e kërkesave të bllokuara përfshinin një përpjekje injektimi SQL në parametrin author_exclude, dhe ngarkesat përdornin fjalë kyçe me shkronja të përziera, komente inline, komente të kushtëzuara specifike për bazën e të dhënave dhe kodim URL për t'u fshehur. Studiuesit i ndanë kërkesat në dy grupe. Grupi shumë më i madh ishte prova të vërtetimit, si AND (1=1), AND (1=2), ose OR SLEEP(5), të përdorura për të kontrolluar nëse një faqe ishte e cenueshme përpara se të shpenzonin më shumë përpjekje. Një grup shumë më i vogël, por më serioz mbante zinxhirin e plotë të publikuar të ngritjes së privilegjeve dhe shkonte direkt për krijimin e administratorit, me një kërkesë grupi që do të thërriste POST /wp/v2/users dhe të vendoste rolet në administrator. Ato përpjekje të plota zinxhirore erdhën nga vetëm tre adresa IP: 129.121.77.134, 91.202.233.61 dhe 125.164.233.50.

Patchstack gjithashtu raporton se rregullat e veta RapidMitigate për dy dobësitë u vendosën në momentin që u publikua këshilla, përpara se të arrinin përpjekjet e para. Gjatë fushatës, 99.9 përqind e të gjitha përpjekjeve të bllokuara u ndaluan nga ato dy rregulla specifike të dobësive të bërthamës së WordPress-it, ndërsa rregullat shtesë gjenerike mezi u regjistruan. Ky rezultat tregon se rregullat e shkakut rrënjësor i kapën sulmet përpara se ato të arrinin te mbrojtjet gjenerike.

Për këdo që ende ekzekuton WordPress 6.9 deri në 7.0.1 pa arnimin, rezultati është i rëndë. Shfrytëzimi publik, i qarkulluar si një mjet i quajtur wp2shell, përdor injektimin SQL vetëm për lexim për të falsifikuar të dhëna që WordPress-i më pas i vepron. Ai mbjell postime dhe një ndryshim të personalizuesit që çojnë në një llogari të re administratori. Pasi një sulmues ka atë llogari admin, ai mund të hyjë, të ngarkojë një shtojcë që në fakt është një guaskë ueb, dhe të ekzekutojë kod në server. Patchstack thotë se verifikoi në mënyrë të pavarur se dobësitë e kombinuara çojnë në marrjen e plotë të faqes, duke përfshirë ekzekutimin e kodit në distancë. Pronarët e faqeve duhet të kontrollojnë për llogari administratori të panjohura, shtojca të papritura, skedarë PHP të rastësishëm në dosjen uploads, dhe çdo gjë të papritur në dosjen mu-plugins, e cila ngarkohet automatikisht dhe nuk shfaqet në ekranin normal të Shtojcave.

Ekziston gjithashtu një paralajmërim për vetë rregullat e zbutjes. Sipas Patchstack, pothuajse çdo rregull muri mbrojtës aplikacioni i publikuar në orët e para pas zbulimit ndante një pikë të verbër kritike. Rregullat kërkonin batch/v1 në URL-në e kërkesës, sepse kështu kodi publik i provës së konceptit arrinte te pika fundore. Por WordPress-i e regjistron rest_route si një variabël publik pyetjeje dhe i lexon ato variabla nga trupi i POST-it përpara se t'i lexojë nga vargu i pyetjes. Prandaj, një sulmues mund të dërgojë një kërkesë të thjeshtë POST në rrënjën e faqes me rest_route=/batch/v1 në trupin e formularit dhe ngarkesën e grupit së bashku me të, dhe WordPress-i do ta drejtojë të gjithë gjënë te pika fundore e grupit. URL-ja nuk përmban kurrë batch/v1, kështu që çdo rregull që inspekton vetëm URL-në sheh një kërkesë të padëmshme në rrënjën e faqes dhe e lë të kalojë. Një rregull që kontrollon vetëm URL-në mund të anashkalohet me një ndryshim të vogël kërkese. Patchstack e zbuloi këtë boshllëk dhe e trajtoi atë si një zbulim të koordinuar, duke njoftuar fillimisht shitësit e prekur të sigurisë dhe ekipin e sigurisë së WordPress-it në mënyrë që ofruesit e pritjes dhe ofruesit e mureve mbrojtës në nivel DNS të mund të përditësonin rregullat e tyre përpara se të publikohej shkrimi. Patchstack thotë se rregullat e veta të para kishin të njëjtin boshllëk, dhe tani i ka përditësuar ato për të kërkuar rrugën e grupit kudo që WordPress-i do ta pranojë, si në URL ashtu edhe në trupin e POST-it. Duke filluar rreth orës 17:00 UTC më 21 korrik, Patchstack filloi të shihte përpjekje shfrytëzimi që përdornin këto forma alternative, me rest_route dhe grupin e kërkesave të mbartur në trupin e POST-it. Pritës të tjerë panë të njëjtin model dhe raportuan se rregullat e tyre origjinale vetëm për URL po anashkaloheshin.

Treguesit kryesorë të zbulimit për këtë fushatë përfshijnë çdo kërkesë për pikën fundore të grupit në çdo formë, si /wp-json/batch/v1, ?rest_route=/batch/v1, ose rest_route=/batch/v1 në trupin e POST-it, plus variantet e rrugës. Webmasterët duhet gjithashtu të kërkojnë një vlerë author_exclude jo të plotë, veçanërisht me UNION, SLEEP(, ose AND/OR të errësuar me komente, dhe të përputhen me shkrimet author.exclude dhe author exclude sepse WordPress-i i normalizon ato përsëri në author_exclude. Çdo shkrim REST i privilegjuar i vendosur brenda një trupi grupi, më së shpeshti POST /wp/v2/users me "roles":["administrator"], ia vlen të shënohet. Pas faktit, shenjat e komprometimit përfshijnë një administrator të ri që nuk e keni krijuar, një shtojcë të saposhtuar që nuk e njihni, një skedar PHP të rastësishëm nën wp-content/uploads ose wp-content/plugins, dhe skedarë të papritur në wp-content/mu-plugins.

Mësimi më i rëndësishëm është koha. Nëntëdhjetë minuta nga një arnim publik deri në shfrytëzim të drejtpërdrejtë nuk lë kohë për të planifikuar një dritare mirëmbajtjeje, testuar një përditësim dhe për ta vendosur atë në mënyrë të sigurt. Kjo është arsyeja pse arnimi virtual dhe përditësimi i menjëhershëm kanë rëndësi. Përditësoni në WordPress 7.0.2, 6.9.5 ose 6.8.6 sa më shpejt që të mundeni, dhe nëse kjo matet me ditë dhe jo me minuta, sigurohuni që diçka po qëndron në hendek ndërsa arrini atje. Për pronarët e faqeve që kanë nevojë për pritje të menaxhuar WordPress me siguri të integruar, AEU Hosting (https://albhosting.eu) ofron pritje të menaxhuar WordPress të siguruar nga fillimi në fund, e cila mund të ndihmojë në reduktimin e dritares së ekspozimit ndërsa po aplikohet një përditësim i bërthamës.