WordPress 7.1.3 rregullon XSS në komente dhe rrjedhjet e postimeve private
WordPress 7.1.3 u publikua më 6 tetor 2026 si një version mirëmbajtjeje dhe sigurie me shtatë rregullime sigurie dhe katër rregullime gabimesh. Ai vjen pas WordPress 7.1.2, i cili dy javë më parë rregulloi një dobësi të vetme të gjurmuar si CVE-2026-87902 që lejonte një vizitor të paautentikuar të shkaktonte një përfshirje lokale skedari dhe, nën konfigurimin e duhur të PHP-së, mund të çonte në ekzekutim kodi në distancë. Ky version është i një lloji tjetër: dy nga rregullimet fillojnë me një vizitor të paautentikuar, rrjedhja e komenteve në furnizim dhe XSS në komente, e cila gjithashtu kërkon që një moderator të klikojë. Tre kërkojnë një llogari Kontribuesi ose Autori, një kërkon që një administrator të ekzekutojë një eksport, dhe një është forcim i varur nga shtojca. Patchstack, firma e sigurisë që publikoi analizën, e quan përditësimin urgjent por jo një emergjencë që lë gjithçka.
Rregullimi më tërheqës është një e metë e ruajtur e skriptimit ndër-site (XSS) në faqen e administrimit të komenteve të WordPress. XSS lejon një sulmues të vendosë kod keqdashës në një faqe që njerëzit e tjerë do ta shohin më vonë. Mbajtësi i klikimit të skedës Help në `wp-admin/js/common.js` kalonte href-in e një lidhjeje te `$()` e jQuery, e cila ndërton HTML nga çdo varg që duket si HTML. Një lidhje brenda një komenti në pritje mund të mbajë një href të tillë. Mbajtësi dëgjon vetëm brenda elementeve me klasën `contextual-help-tabs`, kështu që lidhja gjithashtu ka nevojë për një mbështjellës me atë klasë. Para WordPress 7.1.0, komentet e vizitorëve nuk mund të mbanin një klasë; 7.1.0 shtoi mbështetje për klasën span për përmendjet e shënimeve dhe e shkurton atë gjatë ruajtjes. Sipas rishikimit të Patchstack, sulmi i komentit në pritje prek versionet 7.1.0 deri në 7.1.2, dhe portimet më të vjetra forcojnë të njëjtin kod. Rregullimi 7.1.3 zëvendëson sjelljen me `.find()`, e cila lexon vetëm selektorë. Dobësia u raportua nga Thomas Chauchefoin i Trail of Bits.
Dy çështje të veçanta prekin zbulimin e informacionit. Për furnizimet e komenteve të postimeve të vetme, `WP_Query` ngarkonte komentet e një postimi para se të kontrollonte nëse një vizitor mund ta shihte postimin. Kontrolli i dukshmërisë pastaj pastronte postimin por jo komentet, dhe për shkak se furnizimet nuk kthejnë kurrë një status 404, furnizimi shtypte komentet e postimeve private ose të papublikuara për këdo. Rregullimi e zhvendos pyetjen e komenteve pas kontrollit të dukshmërisë; kjo u raportua nga Ananda Dhakal i Patchstack. Në rastin e Imgur, WordPress normalisht kalon HTML nga ofruesit e pabesueshëm oEmbed përmes një filtri që e redukton atë në një iframe të sandboxuar. Imgur, megjithatë, ishte në listën e besuar, e cila e anashkalon atë filtër, kështu që çfarëdo që kthehej nga API i Imgur dilte drejtpërdrejt. Ajo përgjigje përfshin tekst nga imazhi ose albumi i vetë ngarkuesit, kështu që çdo gjë e kontrolluar nga sulmuesi zbriste në faqe e pafiltruar. Rregullimi heq Imgur-in si ofrues të besuar, kështu që URL-të e Imgur nuk futen më të pafiltruara. Vlen të përmendet se përditësimi nuk heq përmbajtjen ekzistuese të ruajtur në cache oEmbed të ruajtur në `_oembed_*` post meta dhe postimet `oembed_cache`, kështu që një embed keqdashës ekzistues vazhdon të shfaqet derisa cache-i i faqes të pastrohet. Kjo çështje u raportua nga Zhengyu Liu, Jingcheng Yang dhe Gavin Zhong.
Disa rregullime të tjera kërkojnë një llogari Kontribuesi ose më të lartë. Një mohim shërbimi në `WP_Http::make_absolute_url()` vinte nga një lak që shemb çiftet segment/../ por nuk del kurrë në një shteg relativ si `a//../b`, sepse regex-i i tij nuk përputhet me asgjë dhe shtegu nuk ndryshon kurrë. Një Kontribues mund ta shkaktojë atë përmes parapamjes së lidhjes së redaktorit të bllokut duke e drejtuar atë në një faqe që ata kontrollojnë; 7.1.3 e ndërpret lakun kur një kalim nuk zëvendëson asgjë. Një injeksion SQL i rendit të dytë në eksportin WXR mblidhte ID-të e imazheve të veçuara drejtpërdrejt nga metadata `_thumbnail_id` dhe i bashkonte ato në një varg pyetjeje pa siguruar që ID-ja ishte një numër i plotë. Rregullimi shton `absint()` në tre pika. Kodi i cenueshëm ekziston vetëm që nga WordPress 6.5.0 dhe arrihet vetëm kur eksportohet një lloj i vetëm përmbajtjeje; eksporti i parazgjedhur "Të gjitha përmbajtjet" nuk e prek atë. Autorët gjithashtu mund t'i shënonin postimet si ngjitëse sepse REST API refuzonte një kërkesë ngjitëse vetëm kur përdoruesit i mungonin të dyja aftësitë `edit_others_posts` dhe `publish_posts`. Autorët kanë aftësinë `publish_posts`, kështu që ata kalonin; rregullimi ndryshon `&&` (dhe) në `||` (ose). Si mohimi i shërbimit ashtu edhe injeksioni SQL u raportuan nga Anthropic.
Rregullimi i fundit është një përplasje emri grepi. WordPress ndërton disa emra veprimesh nga të dhënat e vetë postimit. Kur një postim ndryshon statusin, `wp_transition_post_status()` aktivizon `${new_status}_{$post_type}`, kështu që publikimi i një postimi aktivizon `publish_post`. Veprime të palidhura ndjekin të njëjtin model emërtimi: `delete_post` aktivizohet kur një postim fshihet, dhe `comment_post` aktivizohet kur shtohet një koment. Para 7.1.2, WordPress nuk kontrollonte kurrë që statusi dhe lloji i postimit ishin regjistruar para se të ndërtonte emrin. Një postim i ruajtur me statusin `delete` dhe llojin `post` do të aktivizonte `delete_post`, të njëjtin veprim si një fshirje e vërtetë, dhe çdo callback i lidhur me të do të ekzekutohej sikur një postim sapo ishte fshirë. Rregullimi i aktivizon këto grepa vetëm kur statusi dhe lloji i postimit janë regjistruar. Kjo u raportua nga Alex Concha i Ekipit të Sigurisë së WordPress.
WordPress 7.1.3 është i disponueshëm nga Paneli nën Përditësimet ose nga WordPress.org, dhe faqet me përditësime automatike në sfond do ta marrin vetë. Rregullimet janë portuar në degët më të vjetra deri të paktën në versionet 6.6, por në kohën e publikimit të Patchstack, degët 4.7 deri në 6.5 ende nuk ishin rregulluar. Patchstack gjithashtu shtoi dobësitë e publikuara në bazën e të dhënave të tij në të njëjtën ditë. Gjatë përditësimit, pronarët e faqeve duhet të auditojnë se kush mban role Kontribuesi ose më të larta, sepse shumë nga këto rregullime kanë të bëjnë me atë që këto role mund të arrijnë. Për pronarët e faqeve në hostim të menaxhuar WordPress si AEU Hosting, përditësimet automatike të bërthamës, mjediset e testimit dhe forcimi i sigurisë e bëjnë më të lehtë aplikimin e një versioni si 7.1.3, pastrimin e cache-eve pas rregullimit dhe rishikimin se cilat llogari mbajnë role Kontribuesi ose më të larta para se një koment në pritje të arrijë ndonjëherë te një moderator.