Vulnerabilitete kritike në PHP vënë në rrezik faqet WordPress
Vulnerabilitete kritike në PHP, të gjurmuara si CVE-2026-109618 dhe CVE-2026-109619, mund t’i ekspozojnë faqet WordPress edhe kur WordPress Core, plugin-et dhe theme-et janë plotësisht të përditësuara. PHP, gjuha e programimit në të cilën është shkruar kryesisht WordPress, publikoi rregullime urgjente më 21 tetor 2026. Të dyja dobësitë kanë një vlerësim ashpërsie prej 9.2 nga 10 sipas Common Vulnerability Scoring System (CVSS) v4.0 dhe mund të lejojnë remote code execution, që do të thotë se një sulmues mund ta detyrojë serverin të ekzekutojë komanda pa u identifikuar më parë.
Këto janë dobësi të PHP në nivel serveri, jo dobësi të vetë WordPress. Prandaj, përditësimi i WordPress nuk instalon patch-et e nevojshme. Release-et e para të PHP që përmbajnë rregullimet 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 shtojnë të njëjtat patch-e në paketa që mbajnë numra më të vjetër të versionit kryesor, ndaj administratorët duhet ta verifikojnë revisionin e plotë të paketës kundrejt njoftimit të sigurisë të ofruesit. Pas instalimit, PHP duhet të riniset në mënyrë që çdo proces aktiv të ngarkojë kodin e korrigjuar. Instancat container, të cilat paketojnë një aplikacion bashkë me runtime dhe dependencies që i nevojiten, duhet të rindërtohen dhe të vendosen përsëri nga një image i përditësuar.
Shfrytëzimi me sukses do t’i jepte një sulmuesi të njëjtën qasje në skedarë dhe të dhëna që ka faqja e internetit. Sipas njoftimeve të projektit PHP, kjo mund të mundësonte leximin e kredencialeve të databazës, vjedhjen e të dhënave të faqes, ndryshimin e skedarëve të faqes ose instalimin e një backdoor të qëndrueshëm, që është një qasje e fshehtë e projektuar të mbetet aktive pas ndërhyrjes fillestare. PHP konfirmoi remote code execution për të dyja vulnerabilitetet dhe konfirmoi se një rrugë e CVE-2026-109618 ekzekutohet përpara se WordPress të fillojë të punojë. Ky dallim ka rëndësi, sepse një mjet sigurie që funksionon vetëm brenda WordPress mund të mos e shohë kurrë pjesën më të hershme të një kërkese të tillë.
Dy vulnerabilitetet arrijnë te ekzekutimi i kodit në mënyra të ndryshme. Me CVE-2026-109618, PHP mund t’i trajtojë gabimisht të dhënat kur një kërkesë shteron memorien e disponueshme. memory corruption që rezulton, domethënë ndryshimi në mënyrë të pasigurt i të dhënave në memorien e punës, mund t’i lejojë një sulmuesi të paautentikuar të ekzekutojë kod. Me CVE-2026-109619, një PHP worker, një nga proceset që trajtojnë kërkesat e faqes, mund të vazhdojë të përdorë informacion të mbetur nga një kërkesë e përfunduar. Një kërkesë e mëvonshme që i caktohet të njëjtit worker mund t’i përdorë këto të dhëna të vjetruara për të ekzekutuar kod.
CrowdStrike raporton se exploit-i i tij privat për këto vulnerabilitete funksionoi në mënyrë të besueshme në sistemet Intel/AMD dhe Arm, përfshirë kundër PHP worker që sapo ishin rinisur. Wordfence tha se nuk e kishte testuar në mënyrë të pavarur atë exploit të papublikuar. Materiale publike proof of concept, që janë kod demonstrues të synuar për të treguar nëse një dobësi mund të aktivizohet, tashmë po qarkullojnë, por Wordfence paralajmëroi se disa shembuj dhe komente janë të paplota, çorientuese ose të gabuara. Nevoja për ta përshtatur një exploit për një server të caktuar nuk provon se një instalim pa patch është i sigurt.
Ekipi Wordfence Threat Intelligence shqyrtoi patch-et e PHP dhe nisi testimet laboratorike brenda pak orësh nga publikimi i tyre. Në një mjedis PHP 8.5.11 të konfiguruar posaçërisht dhe që përdorte Apache, software që pranon dhe shërben kërkesa web, proof of concept i tij për CVE-2026-109619 mbërriti përmes HTTP dhe krijoi një skedar të përkohshëm teksti. Kjo konfirmoi ekzekutimin e kodit në atë laborator. I njëjti test shkaktoi crash në një build normal të optimizuar të PHP 8.5.11, në vend që të ekzekutonte kod, ndërsa PHP 8.5.12 i korrigjuar mbeti funksional.
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. Në teste të veçanta që përdorën WordPress 7.1.3 me një paketë të prekur Ubuntu PHP 8.5.4, kërkesa të ndërtuara posaçërisht shkaktuan dështime ose rinisje të PHP në disa konfigurime. Wordfence nuk arriti në mënyrë të pavarur të siguronte ekzekutim kodi për atë CVE. Këto rezultate paraprake tregojnë se sjellja ndryshon ndërmjet build-eve dhe konfigurimeve të serverëve, por një crash në vend të ekzekutimit të kodit nuk është provë se një server i prekur është i sigurt.
PHP 8.1 dhe branch-et më të hershme nuk marrin më release-e nga projekti PHP. Një ofrues i sistemit operativ ose i mbështetjes afatgjatë mund t’i ofrojë ende patch-et, por operatorëve u nevojitet konfirmim i qartë. Përndryshe, faqja duhet të zhvendoset në një branch PHP që mbështetet. Pronarët e faqeve mund ta shohin versionin që po i shërben realisht WordPress te Tools > Site Health > Info > Server. Rezultati i ekzekutimit të `php -v` në një terminal komandash nuk mjafton, sepse një server mund të përdorë një version të PHP për komandat dhe një tjetër për faqet e internetit.
Klientët e managed hosting duhet të pyesin nëse shërbimi PHP që i shërben faqes së tyre ka marrë patch-et 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, një shërbim që ekzekuton proceset PHP, ose cilindo shërbim PHP që është aktiv. Agjencitë dhe ofruesit e hosting duhet të kontrollojnë çdo faqe production, staging site, që do të thotë një kopje e veçantë testimi, adresë të drejtpërdrejtë origin dhe container më të vjetër, në vend që të kontrollojnë vetëm domain-in kryesor publik. Më pas, duhet të konfirmojnë si versionin te Site Health, ashtu edhe revisionin e plotë të paketës përmes host-it, mjeteve të paketave të sistemit operativ ose ofruesit të container image.
Si masë paraprake, Wordfence rekomandon mbajtjen e backup-eve dhe ruajtjen e logs të web server, PHP, firewall dhe sistemit, duke filluar të paktën nga 48 orë para release-it të 21 tetorit dhe deri në momentin kur PHP u përditësua me patch dhe u rinis. Nëse përditësimi u vonua, administratorët duhet t’i shqyrtojnë këto të dhëna për aktivitet të pazakontë për faqen dhe të hetojnë çdo gjë të dyshimtë. Logs që duken të pastër nuk mund të provojnë se shfrytëzimi nuk ka ndodhur. Rekomandimet e përkohshme të PHP mund ta zvogëlojnë ekspozimin ndaj disa rrugëve të veçanta të sulmit kur aplikimi i menjëhershëm i patch-eve ë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 Firewall mbron WordPress application layer, pjesën që përpunon kërkesat specifike të WordPress, duke përdorur Wordfence Threat Intelligence. Ai nuk i zëvendëson përditësimet dhe kontrollet për PHP, web server, sistemin operativ dhe network edge, domethënë sistemet e jashtme përmes të cilave trafiku arrin te faqja. Klientët e Wordfence Care dhe Wordfence Response mund të kontaktojnë ekipin e tij të incident response nëse dyshohet për komprometim; Wordfence thotë se Response është i disponueshëm 24/7/365, me kohë përgjigjeje prej një ore.
Ky incident tregon gjithashtu rëndësinë e shërbimeve të menaxhuara për pronarët që nuk e administrojnë vetë PHP: AEU Hosting ofron managed WordPress hosting të siguruar nga fillimi në fund. Pavarësisht modelit të hosting, reagimi thelbësor është instalimi i një pakete që është konfirmuar se përmban të dyja rregullimet, rinisja e PHP dhe verifikimi i shërbimit dhe paketës së saktë që po i shërbejnë faqes së internetit.