Të metë në GiveWP lejon sulmuesit të ekzekutojnë kod në faqet WordPress

GiveWP, një shtojcë donacionesh dhe grumbullimi fondesh për WordPress, përmban një dobësi që lejon një sulmues pa llogari në faqe të ekzekutojë komanda në server, sipas një artikulli këshillues të botuar nga Patchstack më 28 gusht 2026. Versionet 4.16.7.1 dhe më poshtë të GiveWP janë të prekura. Prodhuesi lëshoi versionin 4.16.7.2 më 27 gusht 2026 për ta rregulluar, dhe identifikuesi CVE-2026-82222 është caktuar për raportin. Patchstack e liston shtojcën me 100,000 instalime dhe e vlerëson të metën me CVSS 10.0, maja e asaj shkalle ashpërsie.

Studiuesi Udin Chan e zbuloi të metën dhe e raportoi atë, sipas Patchstack, i cili thotë se konfirmoi problemin dhe kontaktoi prodhuesin. Patchstack gjithashtu thotë se ka lëshuar rregulla zbutëse për të mbrojtur kundër shfrytëzimit të kësaj dobësie. GiveWP përdoret nga organizata jofitimprurëse dhe organizata të tjera për të drejtuar formularë donacionesh, për të lidhur portat e pagesave, për të menaxhuar donatorët dhe për të prodhuar raporte.

Ajo që e bën këtë serioze është sa pak i nevojitet një sulmuesi. Në versionet 4.16.5.1 dhe më poshtë, një instalim i parazgjedhur mjafton, sepse GiveWP vjen me një portë manuale aktive (Test Donation) dhe një portë offline aktive, dhe kërkohet vetëm një formular donacioni i publikuar. Nuk nevojitet Modaliteti i Testit, regjistrimi i hapur i përdoruesve, modaliteti i korrigjimit ose veprimi i administratorit. Pasi zinxhiri ekzekutohet, një sulmues mund të ekzekutojë një komandë arbitrare të sistemit operativ si përdoruesi nën të cilin punon serveri i uebit, dhe rezultati i asaj komande mund të lexohet përsëri përmes HTTP.

Një instalim i parazgjedhur pushoi së mjaftuari në versionet 4.16.6 deri në 4.16.7.1, por vetëm në kuptimin e arritshmërisë, jo sepse problemi themelor u rregullua. Këto versione bëjnë që procesori i vjetër i donacioneve të ndalojë kur formulari i dorëzuar është një formular Visual Form Builder (v3). Patchstack vëren se një hyrje e vetme formulari që i mungon cilësimet e ndërtuesit të formularit riarmatos të gjithë zinxhirin, dhe se kjo mund të qëndrojë në çdo status postimi, duke përfshirë draft dhe të hedhur në kosh. Kjo mbulon çdo faqe të përmirësuar nga një version më i vjetër, çdo import ose rikthim formulari, dhe çdo faqe ku një administrator ka aktivizuar Redaktuesin e Formularëve të Bazuar në Opsione nën Cilësimet, Të Avancuara.

Dobësia është ndërtuar nga tre pjesë. E para është një ndihmës që GiveWP e kishte menduar si një mënyrë të sigurt për të përdorur unserialize, që është funksioni PHP që kthen një bllok teksti të ruajtur përsëri në objekte programimi të gjallë. Nëse një sulmues kontrollon atë tekst, ata mund të vendosin një objekt të një klase që zgjedhin. Ndihmësi në skedarin src/Helpers/Utils.php thërret unserialize me cilësimin allowed_classes të vendosur në false, që lexohet sikur objektet janë të bllokuara. Në praktikë PHP ende krijon objektin, por si një lloj zëvendësues i quajtur __PHP_Incomplete_Class që mban emrin origjinal të klasës dhe çdo veti. Kur ai zëvendësues shkruhet përsëri në ruajtje, PHP ri-emeton të njëjtat bajt origjinale, kështu që ngarkesa nuk neutralizohet, vetëm fshihet gjatë atij leximi të vetëm. Sulmi thjesht shtyhet për në një lexim të mëvonshëm që ndodh pa mbrojtjen.

Pjesa e dytë është një rrjedhë donacioni që i dorëzon të dhëna të kontrolluara nga sulmuesi atij ndihmësi. Një donator i identifikuar mund të ruajë një objekt të serializuar në fushën e mbiemrit të profilit të vetë përdoruesit. Kur ata dorëzojnë një donacion, kodi i përpunimit të donacionit në includes/process-donation.php ndërton informacionin e donatorit nga ato të dhëna të llogarisë dhe kalon çdo fushë përmes ndihmësit të sigurt unserialize përpara se të ruajë rezultatin në tabelën wp_give_sessions. Për shkak se të dhënat keqdashëse kthehen nga baza e të dhënave në vend që të mbërrijnë drejtpërdrejt në kërkesë, validimi i zakonshëm i hyrjes nuk i sheh kurrë ato, dhe zëvendësuesi që mban bajt origjinale zbarkon në bazën e të dhënave i paprekur.

Pjesa e tretë është një zinxhir veglash, që është një sekuencë metodash në klasa që tashmë janë ngarkuar dhe që përfundon në një thirrje funksioni të rrezikshëm. GiveWP vjen me bibliotekën TCPDF dhe klasat e veta të të dhënave testuese, dhe së bashku ato formojnë një rrugë të plotë. Shkatërrimi i objektit të injektuar hyn në shkatërruesin e TCPDF, i cili thërret një metodë të brendshme shkatërrimi, e cila arrin në një metodë përcjellëse në tiparin ProviderForwarder që kaloi argumentet e tij drejtpërdrejt në call_user_func_array duke përdorur një të thirrshme të marrë nga vetë objekti. Meqenëse lista e ofruesve është thjesht një veti vargu e mbartur brenda objektit të injektuar, sulmuesi mund ta drejtojë atë në çdo funksion, duke përfshirë një që ekzekuton komanda të sistemit operativ.

Zinxhiri gjithashtu kërkon një përdorues të identifikuar, dhe GiveWP siguroi një falas. Patchstack raporton se një veprim regjistrimi pa autentifikim, give_action=user_register, nuk kontrollon kurrë cilësimin e WordPress që kontrollon nëse vizitorët mund të regjistrohen. Edhe në një faqe me regjistrimin e fikur, një sulmues mund të krijojë një llogari, të marrë një cookie autentifikimi dhe të vazhdojë menjëherë. Versioni 4.16.6 shtoi një kërkesë për kod një herë në atë trajtues, që ngushton dritaren në vend që ta mbyllë atë: kodi del vetëm nga shablloni i shkurt-kodit të regjistrimit, dhe WordPress lëshon kode identike një herë për të gjithë vizitorët e dalë nga një faqe e caktuar, kështu që në çdo faqe që shfaq publikisht atë shkurt-kod një sulmues mund të mbledhë një kod dhe ta ripërdorë atë.

Në sekuencë, sulmi i raportuar kishte katër hapa. Së pari, regjistro një llogari duke postuar në veprimin e regjistrimit, i cili kthen një cookie autentifikimi pavarësisht politikës së regjistrimit të faqes. Së dyti, lexo një kod profili nga faqja e profilit dhe posto veglën e serializuar në fushën e mbiemrit të llogarisë. Së treti, merr një kod donacioni dhe dorëzo një donacion me id formulari, portë dhe shumë por pa fushën e mbiemrit, që bën serverin të shkruajë objektin në tabelën e sesioneve përpara se të kthejë një gabim HTTP 500. Së katërti, kërko çdo faqe të përparme me të njëjtën cookie, në të cilën pikë serveri lexon sesionin e helmuar, rindërton objektin dhe ekzekuton komandën e sulmuesit.

GiveWP e rregulloi problemin në 4.16.7.2, dhe Patchstack thekson se rregullimi e thyen zinxhirin në disa vende të pavarura në vend të pikës së vetme të hyrjes që u raportua. Një përpjekje e mëparshme në 4.16.6 tregon pse kjo ka rëndësi: ajo zbuloi zëvendësuesin e paplotë dhe ktheu tekstin e papërpunuar të serializuar, që ruajti ngarkesën saktësisht si më parë. Versioni 4.16.7.2 kthen një vlerë dështimi në vend të kësaj. Lëshimi pastaj mbyll pesë pika: kodi i përpunimit të donacionit refuzon plotësisht një donacion nëse ndonjë fushë emri mban të dhëna të serializuara, dhe një rrugë rezervë e të dhënave të përdoruesit kalon përmes një funksioni pastrimi që kthen një varg bosh për hyrje të serializuar; tre vende që i lexojnë këto të dhëna përsëri tani bllokojnë krijimin e objekteve, duke përfshirë murin e donatorëve, i cili ishte i arritshëm nga një vizitor anonim përmes një shkurt-kodi publik pa asnjë cookie; vegla përcjellëse tani kontrollon që ofruesi që zgjidh në të vërtetë zbaton kontratën e pritur; fushat e emrit të donatorit dhe faturimit pastrohen përpara se të ruhen; dhe një migrim i quajtur SanitizeSerializedObjectPayloads kalon nëpër tabelat e të dhënave të përdoruesit, donatorit, donacionit dhe sesionit dhe zëvendëson çdo objekt të mbivendosur me një varg bosh. Ky hap i fundit ka rëndësi sepse një faqe që ishte helmuar përpara përditësimit përndryshe do të mbante një ngarkesë funksionale në bazën e të dhënave të saj.

Një çështje nga raporti mbetet e hapur. Patchstack deklaron se veprimi i regjistrimit ende nuk konsulton cilësimin e vetë faqes për lejimin e regjistrimeve, dhe e karakterizon atë si një problem kontrolli aksesi në vend të një hapi drejt ekzekutimit të kodit tani që injektimi i objekteve është mbyllur. Afati kohor i regjistruar nga Patchstack shkon nga 28 korriku 2026, kur mbërriti raporti që mbulonte versionet 4.16.5.1 dhe më poshtë dhe u caktua CVE, deri më 27 gusht 2026, kur prodhuesi lëshoi 4.16.7.2, deri më 28 gusht 2026, kur u publikua këshilla.

Për pronarët e faqeve mësimi praktik është koha e rregullimit. Përditësimi është i disponueshëm, ai heq kodin e dobët dhe gjithashtu pastron të dhënat që versionet e mëparshme mund të kenë ruajtur tashmë. Për këdo që nuk dëshiron të ndjekë nivelet e rregullimeve shtojcë për shtojcë, AEU Hosting, shërbimi ynë i hostimit të menaxhuar për WordPress, merr përsipër mirëmbajtjen dhe sigurinë e WordPress si pjesë të planit, që është pikërisht shtresa ku një rregullim si ky duhet të zbarkojë shpejt.