WordPress 7.1.2 rregullon një dobësi kritike të path traversal

2026-10-06

WordPress 7.1.2, i lëshuar më 22 shtator 2026, rregullon një dobësi kritike të paautentikuar të path traversal në WordPress Core, të gjurmuar si CVE-2026-87902. E meta, e cila ka një rezultat CVSS v4.0 prej 9.2 (Kritike), mund të lejojë një sulmues pa llogari WordPress të detyrojë një faqe të përfshijë një skedar PHP të lexueshëm nga jashtë direktorisë së temës aktive. Në faqet ku tema dhe serveri plotësojnë disa kushte, kjo mund të çojë në ekzekutim kodi në distancë dhe marrje të plotë të faqes. Ekipi i Sigurisë së WordPress lëshoi gjithashtu backport-e sigurie për çdo degë deri në WordPress 4.7. Një tabelë përmbledhëse e Wordfence Intelligence e renditi të metën si CVSS 8.1 (E Lartë) sipas një konvente vlerësimi, ndërsa këshillimi kryesor dhe njoftimi i patch-it përdorin CVSS v4.0 9.2 (Kritike).

Një dobësi e path traversal është një mënyrë për të mashtruar softuerin që të lexojë një skedar jashtë dosjes ku supozohet të punojë, shpesh duke përdorur '..' në një shteg skedari. Në këtë rast, WordPress Core nuk kontrolloi siç duhet që një emër shablloni të zgjidhej në një skedar brenda direktorisë së temës aktive. Një sulmues që dërgon një kërkesë të krijuar posaçërisht në një faqe të cenueshme mund të bëjë që WordPress të përfshijë një skedar lokal PHP të zgjedhur nga sulmuesi. Kjo njihet si përfshirje lokale skedari. Nëse skedari i përfshirë është diçka si pearcmd.php, një mjet linje komandimi i përfshirë me disa instalime PHP, dhe serveri ka register_argc_argv të aktivizuar, përfshirja mund të bëhet ekzekutim kodi në distancë, që do të thotë se sulmuesi mund të ekzekutojë komandat e tij në server. Këshillimi i WordPress vëren se imazhi zyrtar PHP Docker dhe konfigurimet e parazgjedhura të cPanel në PHP para 8.5 mund të ekspozojnë pikërisht këtë kombinim.

Shfrytëzimi nuk është automatik në çdo faqe të papatchuar. Këshillimi i WordPress identifikon dy kushte kryesore. Së pari, tema aktive prind ose fëmijë duhet të përmbajë një direktori të nivelit të lartë, emri i së cilës fillon me page-, për shembull dosja page-templates që gjendet në temat e vjetra Twenty Twelve dhe Twenty Fourteen, si dhe në temat Neve, Hestia dhe Sydney. Së dyti, serveri duhet të ketë një skedar PHP të lexueshëm që prodhon sjellje të dobishme kur përfshihet, si pearcmd.php me register_argc_argv të aktivizuar. Faqet që nuk plotësojnë të dy kushtet mund të mos jenë menjëherë të shfrytëzueshme për ekzekutim kodi në distancë, por path traversal themelor mbetet i pranishëm në WordPress Core derisa të aplikohet përditësimi. Vetëm emrat e temave nuk mjaftojnë për të gjykuar ekspozimin sepse këshillimi nuk liston diapazonet e versioneve të prekura të temave; administratorët duhet të kontrollojnë drejtpërdrejt strukturën e direktorisë së temës së instaluar dhe skedarët e serverit.

Shkaku teknik qëndron në mënyrën se si WordPress zgjidh shabllonet e faqeve. Në versionet e cenueshme, funksioni get_page_template() lexon variablin publik të kërkesës pagename dhe aplikon një urldecode() shtesë përpara se të ndërtojë një kandidat shablloni të quajtur page-{$pagename}.php. Meqenëse WordPress tashmë i dekodon një herë parametrat e kërkesës, një sulmues mund të kodojë dyfish karaktere traversal si '..' në mënyrë që ato të dekodohen vetëm më vonë gjatë zgjidhjes së shabllonit. Kandidati që rezulton i kalohet më pas locate_template(), i cili bashkonte kandidatin me shtegun e temës aktive dhe kontrollonte nëse skedari ekzistonte, por nuk verifikonte që shtegu përfundimtar qëndronte brenda një direktorije të miratuar të temës. Ky kombinim lejoi që një kërkesë e krijuar për faqe të shpëtonte nga një direktori e përputhshme page-* dhe ta drejtonte WordPress-in te një skedar PHP diku tjetër në server. Wordfence i dha meritat Robert Ressl për zbulimin dhe raportimin e përgjegjshëm të të metës, dhe riprodhoi sjelljen në WordPress 7.1.

Rregullimi shton dy shtresa mbrojtjeje. get_page_template() tani vërteton emrin e dekoduar të faqes me funksionin validate_file() të WordPress përpara se të krijojë një kandidat shablloni, duke refuzuar sintaksën e traversal të përdorur në sulm. Përveç kësaj, locate_template() tani i kalon kandidatët ekzistues përmes një kontrolli të ri të quajtur _wp_is_template_path_allowed(). Kur një shteg përmban komponentë traversal, WordPress zgjidh vendndodhjen e tij kanonike dhe konfirmon se qëndron brenda një direktorije të miratuar të temës ose të përputhshmërisë së temës përpara se ta ngarkojë. Kontrolli i parë mbyll shtegun specifik të kërkesës, ndërsa i dyti siguron mbrojtje në thellësi për funksionet dhe filtrat e tjerë të bërthamës që mund të furnizojnë emra shabllonësh.

Për shkak se lëshimi i sigurisë i 22 shtatorit mbulon shumë degë të vjetra, diapazonet e versioneve të prekura janë specifike për degë. Një deklaratë e përgjithshme si WordPress 7.1.1 dhe më herët do të ishte e gabuar, sepse backport-et ekzistojnë për degët e vjetra edhe pse numrat e versioneve të tyre renditen nën 7.1.1. Versionet e patched janë: 7.1.2 për serinë 7.1, 7.0.6, 6.9.9, 6.8.10, 6.7.9, 6.6.9, 6.5.12, 6.4.12, 6.3.12, 6.2.13, 6.1.14, 6.0.16, 5.9.18, 5.8.17, 5.7.19, 5.6.21, 5.5.22, 5.4.23, 5.3.25, 5.2.28, 5.1.26, 5.0.29, 4.9.33, 4.8.32 dhe 4.7.37. WordPress.org deklaron se vetëm lëshimi më i ri në serinë 7.1 mirëmbahet në mënyrë aktive; rregullimet e vjetra janë backport-e sigurie me mirësjellje. Faqet në një degë të vjetër duhet të aplikojnë përditësimin e disponueshëm menjëherë dhe të planifikojnë një përmirësim në një lëshim të mirëmbajtur aktualisht.

Klientët e Wordfence Premium, Wordfence Care dhe Wordfence Response morën mbrojtje firewall kundër CVE-2026-87902 më 22 shtator 2026, në të njëjtën ditë kur u lëshuan dobësia dhe përditësimet. Përdoruesit e Wordfence Free do të marrin të njëjtin rregull më 22 tetor 2026, pas vonesës standarde 30-ditore. Rregulli i firewall zbulon sintaksën e traversal në hyrjen pagename, duke përfshirë formën e koduar që mbetet pas kalimit të parë të dekodimit të firewall-it. Mbrojtja e firewall zvogëlon ekspozimin, por nuk është zëvendësim për përditësimin e WordPress Core.

Pronarët e faqeve duhet të kontrollojnë versionin e WordPress në çdo faqe që menaxhojnë, të përditësojnë në 7.1.2 ose lëshimin e rregulluar për degën e tyre, dhe më pas të konfirmojnë se përditësimi u krye me të vërtetë. Përditësimet automatike në sfond nuk kanë gjithmonë sukses. Nëse përditësimi i menjëhershëm është i pamundur, konfirmoni se një rregull i përshtatshëm firewall është aktiv dhe planifikoni përditësimin e Core sa më shpejt të jetë e mundur. Rishikoni regjistrat e serverit të internetit dhe firewall-it për kërkesa të dyshimta me vlera të ngjashme me traversal në parametrin pagename. Nëse ndonjë kërkesë arriti në shtegun e cenueshëm të shabllonit, trajtojeni faqen si potencialisht të komprometuar dhe filloni një përgjigje të plotë ndaj incidentit: rishikoni llogaritë e administratorit, shtojcat e instaluara ose modifikuara së fundmi, detyrat e planifikuara dhe skedarët e papritur PHP. Burimet kryesore përfshijnë këshillimin e sigurisë së WordPress Core GHSA-7hp8-65ch-5whp, ndryshimin e WordPress Core 63792 dhe arkivin e lëshimeve të WordPress. Për pronarët e faqeve që preferojnë të kenë përditësime në kohë të WordPress Core, konfigurim të forcuar të serverit dhe kopje rezervë automatike të trajtuara nga një ofrues, hostimi i menaxhuar i WordPress si AEU Hosting (albhosting.eu) është një mënyrë për të zvogëluar dritaren midis një lëshimi sigurie dhe një faqeje të patchuar, por përgjegjësia për të verifikuar përditësimin mbetet ende te pronari i faqes.