WordPress 7.1.2 rregullon një dobësi kritike në skedarët e shablloneve
WordPress 7.1.2 u publikua më 22 shtator 2026 si një përditësim vetëm sigurie për një dobësi të vetme në Core, por problemi është serioz: një përfshirje lokale skedari pa autentikim në zgjidhjen e shablloneve të faqeve, e cila, në disa konfigurime hostimi, mund të çojë deri te ekzekutimi i kodit në distancë. Pa autentikim do të thotë se sulmuesit nuk i duhet një llogari WordPress. Përfshirje lokale skedari do të thotë ta detyrosh faqen të ngarkojë një skedar që tashmë ndodhet në server. Ekzekutim kodi në distancë do të thotë ta bësh serverin të ekzekutojë komanda ose kod të zgjedhur nga sulmuesi.
Sipas Patchstack, dobësia prek WordPress Core nga 4.7.0 deri në 7.1.1 përfshirë. Ajo ka një vlerësim CVSS 4.0 prej 9.2, me vektorin AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N. CVSS, Common Vulnerability Scoring System, është një mënyrë standarde për të vlerësuar sa të rënda janë gabimet e sigurisë. Dobësia klasifikohet si CWE-98, kontroll i papërshtatshëm i emrit të një skedari për një deklaratë përfshirjeje, dhe i është caktuar CVE-2026-87902.
Rreziku është më i gjerë se një gabim normal i një versioni të vetëm, sepse preket çdo degë deri te WordPress 4.7, të cilën Patchstack e përshkruan si pothuajse një dekadë publikimesh. Nuk kërkohet hyrje në llogari për të tentuar shfrytëzimin. Ky kombinim ka rëndësi për pronarët e faqeve, sepse faqet WordPress të ekspozuara publikisht janë të arritshme nga kushdo në internet, dhe dobësitë që nuk kërkojnë llogari janë më të lehta për t’u kontrolluar në shkallë të gjerë.
Rruga e cenueshme ndodhet te mënyra se si WordPress zgjedh shabllonet e faqeve. Kur WordPress shfaq një faqe, get_page_template() në wp-includes/template.php ndërton emra të mundshëm skedarësh shablloni dhe ia kalon ato ngarkuesit të shablloneve. Një kandidat vinte nga variabla e kërkesës pagename, një vlerë e marrë nga kërkesa. Në versionet e cenueshme, një slug i afërt i shabllonit të faqes kontrollohej me validate_file(), kontrolli vetjak i WordPress për kalim të pasigurt nëpër shtigje skedarësh, por emri i skedarit i ndërtuar nga pagename nuk kontrollohej.
Ky kontroll i munguar nuk e bënte të arritshëm çdo skedar në një server. Emri i skedarit ndërtohej në formën page-{pagename}.php, kështu që shtegu duhej të vazhdonte përmes një drejtorie që realisht fillon me page-, dhe objektivi i përfshirë ende duhej të përfundonte me .php, sepse WordPress ia shtonte atë prapashtesë. Patchstack thotë se parakushti praktik është një temë aktive me një dosje të nivelit të sipërm si page-templates, një model i pranishëm në tema të vjetra të parazgjedhura dhe në një numër temash të njohura nga palë të treta. Një thirrje shtesë urldecode(), e cila i kthen karakteret e koduara në URL në formën e tyre normale, është ajo që mund ta kthente një slug në formë kalimi shtegu në një shteg real. Patchstack thotë se nuk po publikon një kërkesë funksionale.
Kalimi nga përfshirja e skedarit te ekzekutimi i kodit në distancë është i kushtëzuar. Përfshirja e një skedari lokal PHP, ku PHP është gjuha e programimit mbi të cilën funksionon WordPress, ekzekuton çfarëdo që ai skedar bën normalisht. Për të arritur ekzekutim arbitrar kodi, sulmuesit i duhet një skedar .php i lexueshëm në server që sillet në mënyrë të dobishme kur përfshihet. Patchstack identifikon pearcmd.php të PEAR si kandidatin e njohur, por thotë se ai bëhet i dobishëm vetëm kur PHP po ekzekutohet me register_argc_argv të aktivizuar. register_argc_argv është një cilësim i PHP që u bën të disponueshme skripteve argumente të stilit të linjës së komandës.
Ky cilësim nuk është i rrallë në mjediset që përmend Patchstack. Ai është i aktivizuar si parazgjedhje në imazhet zyrtare PHP Docker dhe në mjediset cPanel në PHP nën 8.5. Për pronarët e faqeve, leximi praktik nuk është pra “vetëm serverë të pazakontë janë në rrezik”. Patchstack e përkufizon problemin si përfshirje skedari pa autentikim gjithmonë, dhe ekzekutim kodi kur shtresa e hostimit përputhet me kushtet. Këshilla e tij është ta trajtoni dobësinë si kritike, përveç nëse shtresa e vetë faqes është kontrolluar dhe është konfirmuar se nuk i plotëson ato kushte.
WordPress 7.1.2 solli dy ndryshime përkatëse. I pari zbaton të njëjtin kontroll validate_file() te shtegu i dekoduar pagename që tashmë e kishte dega fqinje. I dyti shton një kontroll më të gjerë kufizimi, _wp_is_template_path_allowed(), për çdo shteg të zgjidhur shablloni, pavarësisht se cili shteg kodi e prodhoi atë. Nëse një shteg skedari ekziston dhe nuk përmban një shenjë kalimi në drejtorinë prind, ai lejohet. Përndryshe, WordPress zgjidh shtegun real dhe kërkon që ai të jetë brenda një vendndodhjeje të lejuar të temës: drejtoria stylesheet, drejtoria template, ose theme-compat.
Ky ndryshim i dytë është i rëndësishëm sepse e trajton zgjidhjen e shablloneve si një klasë më të gjerë rreziku, jo thjesht si një thirrje të vetme validimi të munguar. Një ndryshim validimi me një rresht do ta kishte adresuar shtegun e raportuar. Kërkesa që çdo shteg i zgjidhur shablloni të qëndrojë brenda drejtorive të lejuara të temës shton një kufi sigurie rreth vetë procesit të ngarkimit të shablloneve.
Afati kohor është i ngjeshur. Më 22 shtator 2026, WordPress 7.1.2 u publikua me korrigjime të rikthyera për çdo degë të mbështetur deri në 4.7. Në të njëjtën datë, u publikua këshillimi GHSA-7hp8-65ch-5whp dhe u caktua CVE-2026-87902. Patchstack gjithashtu e shtoi problemin në bazën e vet të të dhënave të dobësive dhe thotë se vendosi një rregull RapidMitigate për faqet e mbrojtura, ndërsa vazhdon të rekomandojë përditësimin në versionin më të fundit të WordPress të disponueshëm.
Pronarët e faqeve mund të përditësojnë përmes WordPress Dashboard te Updates ose ta shkarkojnë publikimin drejtpërdrejt nga WordPress.org. Faqet me përditësime automatike në sfond të aktivizuara duhet ta kenë marrë tashmë korrigjimin. Për shkak se problemi shkon deri te WordPress 4.7, publikime të korrigjuara u botuan për çdo degë për të cilën WordPress ende rikthen korrigjime, duke u lejuar faqeve më të vjetra të marrin korrigjimin e sigurisë pa një kalim në version madhor. Patchstack gjithashtu vëren se vetëm versioni më i fundit i WordPress mbështetet në mënyrë aktive, dhe ai mbetet versioni që faqet duhet të synojnë të përdorin.
Nëse një përditësim i menjëhershëm nuk është i mundur, dy kontrollet që rekomandon Patchstack janë tregues praktikë të rrezikut, jo zgjidhje. Së pari, kontrolloni nëse tema aktive ka një drejtori të nivelit të sipërm që fillon me page-. Së dyti, kontrolloni nëse PHP ka register_argc_argv të aktivizuar. Këto përgjigje i tregojnë pronarit të faqes sa afër është serveri me zinxhirin e rastit më të keq për ekzekutim kodi, por ato nuk zëvendësojnë instalimin e publikimit të korrigjuar të WordPress. Për pronarët e faqeve që preferojnë të mos e menaxhojnë këtë vetëm, AEU Hosting është hostim i menaxhuar WordPress, i siguruar nga fillimi në fund.