WordPress 7.1.3 rregullon shtatë cenueshmëri sigurie
WordPress 7.1.3 rregullon shtatë cenueshmëri sigurie dhe katër gabime software në një release mirëmbajtjeje dhe sigurie të publikuar më 6 tetor 2026. Dobësitë përfshijnë ekspozimin e komenteve në përmbajtje private, dy rrugë cross-site scripting, një denial of service, një problem SQL injection të lidhur me eksportin, leje të pasakta për sticky posts dhe një përplasje mes emrave të brendshëm të veprimeve. Release duhet instaluar pa vonesë, megjithëse qasja dhe ndërveprimi që kërkohen për shumicën e sulmeve bëjnë që ai të mos përshkruhet si një emergjencë e menjëhershme për të cilën duhet lënë çdo gjë tjetër.
Kjo ndryshon nga WordPress 7.1.2, i publikuar dy javë më parë. Ai përditësim rregulloi CVE-2026-87902, një problem që i lejonte një vizitori të paautentikuar, domethënë dikujt pa llogari, të aktivizonte local file inclusion dhe potencialisht ta bënte serverin të ngarkonte një file lokal të pasynuar. Me konfigurimin e duhur të PHP-së, kjo mund të çonte në remote code execution, që do të thotë ekzekutim komandash në server nga një vend tjetër. Në 7.1.3, dy cenueshmëri nisin me një vizitor të paautentikuar, tri kërkojnë një llogari Contributor ose Author, njëra kërkon që një administrator të kryejë një eksport dhe njëra varet nga mënyra se si një plugin i jep të dhënat e postimit.
Njëra nga rrugët pa autentikim është stored cross-site scripting (XSS), ku kod armiqësor për browser ruhet nga një faqe dhe më pas i dërgohet një përdoruesi tjetër. Handler-i i skedës Help në wp-admin/js/common.js ia kalonte vlerën href të një linku funksionit $() të jQuery, i cili mund të ndërtojë HTML kur një string i ngjan HTML-së. Një sulmues mund ta vendoste një link të tillë brenda një komenti në pritje, të mbështjellë në një element që përdorte class contextual-help-tabs. Sulmi ende kërkonte që një Editor ose një moderator tjetër ta klikonte linkun gjatë shqyrtimit të komentit.
Komentet e vizitorëve nuk mund ta përmbanin class-in e kërkuar përpara WordPress 7.1.0. Ai version shtoi mbështetje për span class për përmendjet në shënime dhe e kufizoi vlerën gjatë ruajtjes. Për këtë arsye, shqyrtimi i kodit nga Patchstack e vendos periudhën e sulmit me koment në pritje te versionet 7.1.0 deri në 7.1.2. WordPress 7.1.3 e zëvendëson operacionin e rrezikshëm me .find(), i cili e interpreton vlerën e dhënë vetëm si selector, një model për gjetjen e një elementi ekzistues të faqes. Përditësimet më të vjetra backport forcojnë të njëjtin kod.
Një dobësi e veçantë denial of service prekte WP_Http::make_absolute_url(). Një denial of service e bën një sistem të padisponueshëm ose të papërgjegjshëm. Funksioni përmbante një loop që synonte të bashkonte segmentet e path-it që përmbanin segment/../, por një path relativ si a//../b bënte që rregulli i përputhjes të mos gjente asgjë. Meqë path-i mbetej i pandryshuar, loop nuk përfundonte kurrë. Një përdorues me llogari Contributor mund ta arrinte dobësinë përmes pamjes paraprake të linkut në block editor, duke vendosur një link drejt një faqeje nën kontrollin e atij përdoruesi. Kodi i rregulluar e ndal loop kur një kalim nuk bën asnjë zëvendësim.
Funksioni i eksportit WXR përmbante gjithashtu një problem second-order SQL injection. SQL injection është futja e të dhënave të manipuluara në një komandë të database; second-order do të thotë se vlera e rrezikshme ruhet fillimisht dhe përdoret më vonë. WordPress i merrte identifikuesit e featured image drejtpërdrejt nga metadata _thumbnail_id dhe i bashkonte në një query të database pa u siguruar më parë që ishin numra të plotë. Versioni 7.1.3 aplikon absint(), i cili e shndërron një vlerë në një numër të plotë jonegativ, në tri pika. Kodi i cenueshëm ka ekzistuar që nga 6.5.0 dhe arrihet vetëm kur një administrator eksporton një lloj përmbajtjeje. Eksporti i parazgjedhur All content nuk e përdor atë.
Authors mund t'i shënonin gjithashtu postimet si sticky përmes REST API, një interface nëpërmjet të cilit software i dërgon kërkesa WordPress. Kontrolli i lejeve e refuzonte një kërkesë vetëm nëse përdoruesit i mungonin të dyja capabilities edit_others_posts dhe publish_posts. Authors e kanë publish_posts, prandaj e kalonin atë test. Korrigjimi e ndryshon kushtin logjik nga &&, që do të thotë dhe, në ||, që do të thotë ose, në mënyrë që mungesa e cilësdo leje të kërkuar të mjaftojë për ta ndaluar kërkesën.
Problemi i dytë pa autentikim ekspozonte komentet e bashkëngjitura te postimet private ose të papublikuara. Për një comment feed të një postimi të vetëm, WP_Query i merrte komentet përpara se të konfirmonte se vizitori mund ta shihte postimin. Më pas WordPress e hiqte postimin nga rezultati, por i linte komentet e tij në vend. Meqë feeds nuk kthejnë një përgjigje 404 në këtë situatë, komentet shfaqeshin. Versioni 7.1.3 e kryen query e komenteve vetëm pas kontrollit të dukshmërisë.
Një tjetër dobësi XSS përfshinte embeds të Imgur. WordPress zakonisht e kalon HTML-në nga ofruesit e pabesuar oEmbed përmes një filter që e kufizon atë në një iframe me sandbox, një frame i izoluar brenda faqes. Imgur ishte në listën e ofruesve të besuar, kështu që përgjigjja nga API e tij e anashkalonte atë filter dhe shfaqej drejtpërdrejt. Këto përgjigje mund të përmbajnë tekst të dhënë nga ngarkuesi i një imazhi ose albumi, duke lejuar që përmbajtja nën kontrollin e sulmuesit të arrijë në një faqe pa u filtruar. Rregullimi e heq Imgur nga lista e besuar, që do të thotë se URL-të e tij nuk bëhen më embed pa atë mbrojtje. Shfrytëzimi kërkon një llogari Contributor ose më të lartë dhe një objektiv që e shikon përmbajtjen e prekur.
Përditësimi nuk e heq materialin Imgur oEmbed të ruajtur më parë në cache. Prandaj, metadata ekzistuese _oembed_* të postimeve dhe postimet oembed_cache mund të vazhdojnë të shfaqin një embed keqdashës. Patchstack këshillon pastrimin e cache të faqes pas instalimit të release, në mënyrë që kjo përmbajtje e ruajtur të mos vazhdojë të renderohet.
Ndryshimi i fundit i sigurisë parandalon përplasjet e emrave të action hook. Action hooks janë pika me emër ku plugins mund të ekzekutojnë kodin e tyre. Kur një postim ndryshon status, wp_transition_post_status() ndërton një hook me emër të formuar nga statusi i ri dhe post type, kështu që publikimi i një postimi normal prodhon publish_post. Operacione të tjera të WordPress përdorin emra të ngjashëm, përfshirë delete_post për fshirjen dhe comment_post kur shtohet një koment.
WordPress 7.1.2 nuk verifikonte nëse statusi dhe post type i dhënë ishin regjistruar përpara se ta ndërtonte atë emër. Një plugin që kalonte të dhëna raw në wp_insert_post() mund të ruante një postim me status delete dhe type post, duke bërë që delete_post të ekzekutohej edhe pse nuk kishte ndodhur asnjë fshirje reale. Çdo callback i lidhur me atë action do të sillej më pas sikur një postim të ishte fshirë. WordPress 7.1.3 i aktivizon këto hooks të ndërtuara në mënyrë dinamike vetëm kur janë regjistruar si statusi, ashtu edhe post type.
Në meritat për shtatë rregullimet u renditën Trail of Bits, Anthropic, Patchstack, WordPress Security Team dhe disa hulumtues individualë. WordPress 7.1.3 dhe backports deri te releases 6.6 u bënë të disponueshme më 6 tetor dhe Patchstack i shtoi cenueshmëritë e publikuara në database e vet po atë ditë. Në kohën e publikimit, branches 4.7 deri në 6.5 nuk kishin marrë ende patches.
Administrators mund ta instalojnë WordPress 7.1.3 nga Dashboard, pastaj Updates, ose ta marrin nga WordPress.org. Faqet që përdorin përditësime automatike në background duhet ta marrin automatikisht. Administrators duhet gjithashtu të shqyrtojnë se kush ka rolet Contributor, Author, Editor ose role më të larta, sepse disa prej këtyre dobësive varen nga qasja që ofrojnë ato llogari.