Defekti i Plugin-it GiveWP Lejon Ekzekutim të Largët të Kodit pa Autentifikim

Një dobësi në plugin-in e dhurimeve GiveWP për WordPress lejoi një sulmues pa llogari të ekzekutonte komanda arbitrare në serverin themelor të ueb-it, sipas një njoftimi sigurie nga Patchstack. GiveWP është një plugin popullor që ofron formularë dhurimi, porta pagesash, menaxhim dhuruesish dhe raportim për organizata jofitimprurëse dhe organizata të tjera grumbulluese fondesh. Defekti, i gjurmuar si CVE-2026-82222, mori një rezultat ashpërsie CVSS prej 10.0, vlerësimi më i lartë i mundshëm. Ai preku versionet e GiveWP 4.16.7.1 dhe më të ulëta, dhe u rregullua në versionin 4.16.7.2, i publikuar më 27 gusht 2026. Patchstack, një kompani sigurie për WordPress, tha se përdoruesit e saj ishin të mbrojtur nga rregulla zbutëse dhe se çështja u zbulua dhe u raportua nga studiuesi Udin Chan. Njoftimi e rendit plugin-in si me rreth 100,000 instalime, gjë që e bën përditësimin urgjent për shumë pronarë faqesh.

Problemi teknik njihet si injektim objektesh PHP. Faqet e ndërtuara me WordPress dhe PHP shpesh ruajnë të dhëna komplekse si një varg teksti, një proces i quajtur serializim, dhe më vonë e kthejnë atë varg përsëri në një objekt programi të gjallë përmes një funksioni të quajtur unserialize. Nëse një sulmues mund të kontrollojë tekstin e serializuar, aplikacioni PHP mund të mashtrohet për të krijuar një objekt të rrezikshëm që ekzekuton kod të zgjedhur nga sulmuesi. GiveWP u përpoq ta bënte këtë të sigurt me një funksion ndihmës të quajtur safeUnserialize, i cili përdorte opsionin PHP allowed_classes të vendosur në false. Megjithatë, ai opsion nuk e fshin objektin e sulmuesit. Në vend të kësaj, ai e konverton objektin në një vendmbajtës të quajtur __PHP_Incomplete_Class që ruan emrin origjinal të klasës dhe të gjitha vetitë e tij. Kur ai vendmbajtës serializohet përsëri më vonë, PHP i shkruan bajtet origjinale të rrezikshme përsëri të pandryshuara. Siç shpjegon njoftimi i Patchstack, ndihmësi e fshehu ngarkesën për një lexim dhe më pas ia ktheu objektin e serializuar të paprekur ruajtjes, kështu që sulmi thjesht ndodhi në leximin tjetër të pambrojtur.

Hapi i parë në sulm kërkon një dhurues të regjistruar. Kjo tingëllon si një pengesë, por studiuesit përshkruan një mënyrë për të marrë një llogari falas. GiveWP ekspozon një veprim regjistrimi pa autentifikim të quajtur give_action=user_register, i cili kurrë nuk kontrollon cilësimin e WordPress që kontrollon nëse vizitorët mund të regjistrohen. Edhe në një faqe me regjistrim të çaktivizuar, një sulmues mund të dërgonte një kërkesë të përgatitur për të krijuar një llogari dhe të merrte një cookie autentifikimi. Para versionit 4.16.6 nuk kishte kërkesë nonce në këtë trajtues. Një nonce është një shenjë e përkohshme që synon të provojë se një kërkesë erdhi nga një faqe e lejuar. Versioni 4.16.6 shtoi një kërkesë nonce, por nonce-ja emetohet vetëm nga një faqe që përdor shortcode-in [give_register], dhe nonce-t e WordPress për vizitorët e çregjistruar janë identike për çdo kërkesë anonime në të njëjtën faqe. Kjo do të thotë se një sulmues mund ta mbledhë nonce-n një herë dhe ta ripërdorë atë në çdo faqe që e shfaq atë shortcode publikisht. Me pak fjalë, pengesa e llogarisë nuk ishte një pengesë e vërtetë.

Pasi brenda, sulmuesi vendos një zinxhir gadgetesh të serializuar në fushën e mbiemrit të llogarisë së tij përmes faqes së profilit. Termi zinxhir gadjetesh i referohet një sekuence metodash në kodin tashmë të ngarkuar që, kur një objekt shkatërrohet ose serializohet, përfundimisht thërret një funksion të rrezikshëm. GiveWP vjen me dy biblioteka që së bashku formojnë një zinxhir të plotë: biblioteka TCPDF dhe klasat Give\TestData. Kur objekti i injektuar shkatërrohet, ai hyn në TCPDF::__destruct, i cili thërret _destroy, dhe kjo arrin një metodë magjike në tiparin ProviderForwarder. Kjo metodë përdor call_user_func_array me një callable dhe argument të kontrolluar nga sulmuesi. Për shkak se sulmuesi kontrollon një veti vargu të quajtur loadedProviders brenda objektit të injektuar, ai mund ta vendosë atë në funksionin system të PHP. Rezultati është ekzekutimi i një komande arbitrare të sistemit operativ si përdoruesi i serverit të ueb-it.

Rrjedha e dhurimit i lidh këto pjesë. Kur sulmuesi i regjistruar paraqet një dhurim, plugin-i ndërton një regjistër informacioni për dhuruesin. Ai merr vlerën last_name nga baza e të dhënave, ku zinxhiri i serializuar i gadjetit është ruajtur, dhe e kalon atë përmes ndihmësit "të sigurt" unserialize. Për shkak se të dhënat vijnë nga baza e të dhënave dhe jo direkt nga kërkesa, validimi i zakonshëm i hyrjes nuk i sheh kurrë ato. Objekti vendmbajtës më pas serializohet në rrugën e tij në tabelën wp_give_sessions, dhe bajtet origjinale të rrezikshme ruhen të paprekura. Herën tjetër që faqja e lexon atë sesion, ajo i deserializon bajtet pa rojen allowed_classes, gjë që e sjell gadjetin e vërtetë në jetë. Zinxhiri i plotë i përshkruar nga Patchstack ka katër hapa: regjistro një llogari, vendos gadjetin në profil, helmo sesionin duke paraqitur një dhurim pa vlerë last_name, dhe më pas kërko çdo faqe front-end me të njëjtën cookie për të shkaktuar komandën.

Njoftimi gjithashtu shpjegon një ndryshim në arritshmëri midis versioneve. Në GiveWP 4.16.5.1 dhe më poshtë, një instalim i paracaktuar ishte i mjaftueshëm: plugin-i vinte me një portë aktive manuale (Test Donation) dhe një portë aktive offline, dhe kërkonte vetëm një formular dhurimi të publikuar. Nuk kërkohej Test Mode, regjistrim i hapur, debug mode, ose veprim administratori. Versionet 4.16.6 deri në 4.16.7.1 bënë që procesori i trashëguar i dhurimeve të dilte kur formulari i paraqitur është një formular Visual Form Builder (v3), kështu që një instalim i ri i paracaktuar nuk ishte më i shfrytëzueshëm përmes asaj rruge. Megjithatë, një postim i vetëm give_forms që i mungon formBuilderSettings e riarmatos zinxhirin, në çdo status postimi, përfshirë draft dhe të fshirë. Kjo mbulon faqet e përditësuara nga versione më të vjetra, çdo import ose restaurim formulari, dhe çdo faqe ku një administrator ka aktivizuar Option-Based Form Editor.

Patch-i përfshin një mësim të rëndësishëm për defektet e deserializimit. Para rregullimit përfundimtar, GiveWP publikoi versionin 4.16.6, i cili u përpoq të zbulonte vendmbajtësin __PHP_Incomplete_Class dhe, kur e gjente, të kthente vargun e serializuar të papërpunuar. Kjo i kthente bajtet origjinale të ngarkesës fjalë për fjalë, duke e lënë sulmin po aq të mundshëm më vonë. Versioni 4.16.7.2 e ndryshoi këtë për të kthyer false në vend të kësaj, gjë që e ndalon ngarkesën. Zhvilluesit më pas e mbyllën zinxhirin në pesë pika të pavarura. Rruga e shkrimit në process-donation.php tani e refuzon një dhurim krejtësisht nëse ndonjë fushë emri përmban të dhëna të serializuara, dhe fallback-u i user meta kalon përmes give_clean, i cili kthen një varg bosh për hyrje të serializuara. Tre lexues dalje tani kalojnë allowed_classes të vendosur në false: marrësi i sesionit, leximi i tabelës së sesionit dhe muri i dhuruesve. Muri i dhuruesve ka rëndësi sepse ishte i arritshëm nga një vizitor anonim përmes shortcode-it publik [give_donor_wall] pa asnjë cookie sesioni. Vetë gadjeti u rregullua: ProviderForwarder::__call tani verifikon që ofruesi i zgjidhur e zbaton kontratën e pritur përpara se ta thërrasë. Meta e emrit të dhuruesit dhe të faturimit kalon përmes sanitize_text_field kur ruhen pagesat. Së fundi, një migrim i quajtur SanitizeSerializedObjectPayloads kalon nëpër usermeta, give_donormeta, give_donationmeta dhe give_sessions dhe zëvendëson çdo objekt të mbivendosur me një varg bosh. Ky hap i fundit heq ngarkesat tashmë të ruajtura në bazën e të dhënave para përditësimit.

Njoftimi vë në dukje një artikull nga raporti që nuk adresohet. Trajtuesi i regjistrimit pa autentifikim give_action=user_register ende nuk konsultohet me opsionin users_can_register të WordPress. Patchstack e përshkruan këtë si një çështje kontrolli aksesi dhe jo si një hap drejt ekzekutimit të kodit pasi injektimi i objektit është mbyllur. Pronarët e faqeve duhet ta mbajnë parasysh këtë, por zinxhiri i ekzekutimit të largët të kodit vetë është thyer nga pesë shtresat e rregullimit. Afati kohor tregon se raporti u mor më 28 korrik 2026, u konfirmua të njëjtën ditë dhe iu zbulua shitësit. Disa përpjekje patch u refuzuan para publikimit të 4.16.7.2 më 27 gusht 2026. Njoftimi u bë publik më 28 gusht 2026.

Për pronarët e faqeve, ky rast është një kujtesë se një plugin me një bazë të madhe instalimesh dhe funksionalitet pagesash është një objektiv kryesor. Përditësoni GiveWP dhe çdo plugin aktiv menjëherë dhe trajtojini përditësimet e sigurisë si mirëmbajtje të ndjeshme ndaj kohës. Shërbimet e hostimit të menaxhuar WordPress që i mbajnë plugin-et të përditësuara, si AEU Hosting, mund ta shkurtojnë kohën që një version i prekshëm mbetet i gjallë në një faqe prodhimi. Ky është mbrojtje praktike për shumë organizata jofitimprurëse, grumbullues fondesh dhe biznese të vogla që mbështeten te GiveWP për të mbledhur dhurime online.