Dobësitë në PHP mundësojnë code execution në WordPress
Dy dobësi kritike në PHP mund t’i ekspozojnë faqet WordPress ndaj remote code execution, që do të thotë se një sulmues mund ta bëjë shërbimin bazë të faqes të ekzekutojë komanda pa u identifikuar më parë. PHP, gjuha e programimit në të cilën është shkruar kryesisht WordPress, publikoi përditësime emergjente sigurie më 21 tetor 2026. Dobësitë, CVE-2026-109618 dhe CVE-2026-109619, kanë secila një rezultat CVSS v4.0 prej 9,2 nga 10. CVSS, ose Common Vulnerability Scoring System, është një shkallë standarde për vlerësimin e rëndësisë së rreziqeve të sigurisë.
Këto nuk janë dobësi në WordPress Core, plugins ose themes. Ato prekin shërbimin PHP që përpunon trafikun e faqes, prandaj instalimi i një përditësimi të WordPress nuk do t’i korrigjojë. Versionet e para të korrigjuara të PHP janë 8.5.12, 8.4.27, 8.3.36 dhe 8.2.35. Shpërndarjet Linux dhe ofruesit e mbështetjes afatgjatë mund t’i vendosin të njëjtat korrigjime në paketa që ruajnë numra më të vjetër të versionit kryesor. Për këtë arsye, administratorët duhet të kontrollojnë revizionin e plotë të paketës, i cili identifikon build-in e saktë të ofruesit, dhe të lexojnë njoftimin e tij të sigurisë në vend që të mbështeten vetëm te versioni kryesor i PHP.
Të dyja dobësitë mund të shfrytëzohen pa autentifikim. Shfrytëzimi me sukses i jep sulmuesit të njëjtin nivel aksesi që ka vetë faqja e internetit. Në varësi të këtij aksesi, sulmuesi mund të lexojë kredencialet e databazës, të ndryshojë skedarët e faqes, të vjedhë të dhëna ose të instalojë një backdoor të qëndrueshëm, pra akses të fshehur të projektuar për të mbetur aktiv pas ndërhyrjes fillestare. PHP ka konfirmuar remote code execution për të dyja dobësitë. Gjithashtu ka konfirmuar një attack path për CVE-2026-109618 që vepron përpara se WordPress të fillojë të ekzekutohet, duke e vendosur atë jashtë mbrojtjes së ofruar vetëm nga kontrollet brenda WordPress.
CVE-2026-109618 lidhet me përpunimin e gabuar të të dhënave nga PHP kur një kërkesë bën që të mbarojë memoria. memory corruption që pason mund t’i lejojë një sulmuesi të paautentifikuar të ekzekutojë kod. CVE-2026-109619 lidhet me stale worker state: një worker i PHP, pra një nga proceset aktive që trajton kërkesat, mund të vazhdojë të përdorë të dhëna nga një kërkesë që ka përfunduar tashmë dhe duhej të ishte hequr. Një kërkesë e mëvonshme, e përpunuar nga i njëjti worker, mund t’i përdorë të dhënat e ruajtura për të ekzekutuar kod.
Wordfence Threat Intelligence analizoi korrigjimet e PHP dhe testoi sjelljen e cenueshme në mjedise laboratorike PHP dhe WordPress. Në një laborator Apache të konfiguruar posaçërisht dhe me PHP 8.5.11, një proof of concept, pra një test i projektuar për të treguar se një dobësi funksionon, shfrytëzoi CVE-2026-109619 përmes një kërkese HTTP në internet dhe krijoi një skedar të përkohshëm teksti. Kjo konfirmoi code execution në mjedisin e testimit. I njëjti test shkaktoi ndërprerjen e një build-i normal të optimizuar të PHP 8.5.11 në vend që të ekzekutonte kod, ndërsa PHP 8.5.12 i korrigjuar vazhdoi të funksiononte normalisht.
Për CVE-2026-109618, PHP 8.5.11 i cenueshëm dështoi gjatë testimit, ndërsa PHP 8.5.12 e përpunoi normalisht të njëjtën kërkesë proof of concept. Teste të veçanta përdorën WordPress 7.1.3 me një paketë të prekur Ubuntu PHP 8.5.4. Kërkesa të përgatitura posaçërisht shkaktuan dështime ose rinisje të PHP në disa konfigurime, por Wordfence nuk arriti në mënyrë të pavarur code execution për këtë dobësi. Testimi filloi brenda disa orësh nga publikimi i korrigjimeve dhe po vazhdonte në attack paths shtesë dhe në konfigurime të zakonshme hostimi për WordPress.
Rezultatet e ndryshme nuk e bëjnë të sigurt një sistem të papërditësuar. Shfrytëzimi mund të duhet të përshtatet për një server të caktuar. CrowdStrike raporton se exploit-i i tij privat funksionoi në mënyrë të besueshme në sisteme Intel dhe AMD, si edhe në sisteme Arm, përfshirë kundër worker të PHP të saporinisur, megjithëse Wordfence nuk e testoi në mënyrë të pavarur këtë exploit të papublikuar. Kodi publik proof of concept dhe komentet teknike po qarkullojnë tashmë, por Wordfence paralajmëron se disa shembuj janë të paplotë, çorientues ose të gabuar. Pronarët e faqeve duhet të ndjekin njoftimet zyrtare të PHP në vend që të presin për të parë nëse një exploit publik funksionon kundër serverit të tyre specifik.
PHP 8.1 dhe versionet më të vjetra nuk marrin më publikime nga projekti PHP. Disa ofrues të sistemeve operative dhe të mbështetjes afatgjatë mund t’i ofrojnë ende korrigjimet për këto degë. Kushdo që përdor një version më të vjetër duhet të marrë konfirmim të qartë nga ofruesi se të dyja dobësitë janë korrigjuar, ose të kalojë në një degë të mbështetur të PHP. Pas instalimit të një pakete të korrigjuar, PHP duhet të riniset që çdo proces aktiv të ngarkojë kodin e ri. Një container, mjedis i izoluar software i paketuar bashkë me varësitë e tij, duhet të rindërtohet dhe të rivendoset nga një image i përditësuar, jo thjesht të riniset me skedarët e vjetër.
Administratorët e WordPress mund ta kontrollojnë versionin që i shërben faqes te Tools, Site Health, Info dhe më pas Server. Kontrolli nga command line “php -v” nuk mjafton më vete, sepse faqja mund të përdorë një instalim tjetër të PHP. Klientët e managed hosting duhet të pyesin nëse shërbimi PHP që i shërben faqes së tyre është korrigjuar për të dyja CVE-të dhe nëse është rinisur. Operatorët që i menaxhojnë vetë sistemet duhet të përditësojnë PHP dhe të rinisin Apache, PHP-FPM, që është një shërbim që ekzekuton PHP për web servers, ose çdo shërbim tjetër PHP. Agjencitë dhe ofruesit e hostimit duhet të kontrollojnë faqet publike, kopjet staging të përdorura për testim, adresat origin të arritshme pas shërbimeve ndërmjetëse dhe mjediset e vjetra container.
Si masë paraprake, administratorët duhet të mbajnë backups dhe të ruajnë regjistrat e web server, PHP, firewall dhe sistemit që mbulojnë të paktën 48 orët përpara publikimit të 21 tetorit deri në momentin kur PHP u përditësua dhe u rinis. Faqet që u përditësuan me vonesë duhet t’i kenë këta regjistra të kontrolluar për aktivitet të pazakontë. Mungesa e hyrjeve dukshëm të dyshimta nuk provon se shfrytëzimi nuk ka ndodhur. Rekomandimet e përkohshme të PHP mund ta zvogëlojnë ekspozimin ndaj disa attack paths kur instalimi i menjëhershëm i korrigjimit është i pamundur, por ato janë të paplota, mund të pengojnë funksionet normale të faqes dhe nuk e zëvendësojnë përditësimin.
Wordfence thotë se firewall i tij funksionon në application layer të WordPress dhe mund të bllokojë sulme specifike ndaj WordPress që mjetet e përgjithshme mund të mos i njohin. Këto dobësi të PHP ekzistojnë në server layer dhe disa forma shfrytëzimi mund të fillojnë përpara se të niset WordPress, prandaj nevojiten kontrolle sigurie edhe për PHP, web server, sistemin operativ dhe network edge, pika ku trafiku i jashtëm hyn në infrastrukturë. Për lexuesit që po shqyrtojnë se ku funksionon faqja e tyre, AEU Hosting është shërbimi managed WordPress hosting i AEU Group, i përshkruar si i siguruar end to end.
Një instalim plotësisht i përditësuar i WordPress mund të mbetet i ekspozuar derisa shërbimi PHP pas tij t’i marrë të dyja korrigjimet dhe të riniset. Wordfence thotë se klientët e shërbimeve të tij Care dhe Response mund të kontaktojnë ekipin e incident response nëse dyshojnë për komprometim; Wordfence Response deklaron disponueshmëri 24 orë në ditë, gjatë gjithë vitit, dhe kohë përgjigjeje prej një ore. Veprimi thelbësor për çdo faqe të prekur mbetet i njëjtë: instaloni një paketë të korrigjuar PHP, rinisni shërbimin dhe verifikoni paketën e saktë që po përpunon realisht kërkesat e faqes.