WordPress 7.1.4 rregullon 22 dobësi, përfshirë RCE gjatë përditësimit
WordPress 7.1.4 u publikua më 28 tetor 2026 me rregullime për 22 dobësi të trajtuara në 17 njoftime sigurie. Versioni pararendës 7.1.3 kishte trajtuar shtatë dobësi tri javë më parë. Shumica e problemeve të saporregulluara kërkojnë një llogari ekzistuese, zakonisht me akses Contributor ose më të lartë, por një race condition mund të çonte në remote code execution pa autentikim. Një race condition është një dobësi që varet nga kryerja e veprimeve sipas një rendi të ngushtë dhe të paqëllimshëm, ndërsa remote code execution, ose RCE, nënkupton detyrimin e një serveri të ekzekutojë kod të kontrolluar nga sulmuesi.
WordPress publikoi po atë ditë backports, që janë rregullime të përshtatura për degë më të vjetra të software-it, për çdo degë të mbështetur deri te 4.7.39. Versionet e disponueshme përfshijnë 7.0.8, 6.9.11, 6.8.12, 6.7.11, 6.6.11, 6.5.14 dhe 6.4.14, si dhe backports të tjera deri te 4.7.39. Faqet që përdorin WordPress 4.6 ose versione më të vjetra nuk marrin asnjë përditësim. WordPress 7.1.4 është i disponueshëm përmes Dashboard, Updates dhe WordPress.org, ndërsa faqet me përditësime në sfond të aktivizuara duhet ta instalojnë automatikisht.
Analiza e kodit nga Patchstack zbuloi se dobësia me pasojat më të mëdha ndodhej në procesin bazë të upgrade. Gjatë një instalimi ose përditësimi, WordPress nxjerr një paketë në wp-content/upgrade/, një directory që mund të ofrohet publikisht nga web server. Përpara versionit 7.1.4, folder-i i nxjerrë trashëgonte emrin e paketës, duke e bërë vendndodhjen e tij të parashikueshme për paketat e ngarkuara përmes zonës së administrimit. Pastrimi fillestar gjithashtu hiqte gjithçka nga upgrade directory, përfshirë skedarin index.php që pengon vizitorët të shohin një directory listing.
Për ato pak sekonda që nevojiten për të përfunduar një përditësim, skedarët e nxjerrë mund të formonin kështu një instalim të plotë të WordPress në një adresë që mund të hamendësohej dhe potencialisht të shfletohej. Kjo kopje përfshinte wp-admin/setup-config.php, i cili mund të nisej në mënyrë të pavarur pa konfigurimin e faqes aktive. Një sulmues që arrinte tek ai gjatë intervalit të përditësimit mund ta ekzekutonte instaluesin kundrejt një database nën kontrollin e sulmuesit, duke qëndruar brenda document root të faqes viktimë, folder-i i aksesueshëm nga web-i që përmban faqen. Nuk kërkohej asnjë llogari ose ndërveprim nga përdoruesi, megjithëse kërkesat për kohëzgjatjen dhe ekspozimin e bënin të vështirë shfrytëzimin.
WordPress 7.1.4 shton 16 karaktere të rastësishme në emrin e folder-it të përkohshëm, rikthen index.php dhe nuk e fshin më atë skedar. Patchstack identifikoi gjithashtu një ndryshim të veçantë në update-core.php që pengon kopjimin e wp-config.php jashtë working directory. Patchstack e vlerësoi dobësinë si AC:H, që nënkupton kompleksitet të lartë sulmi, dhe tha se shfrytëzimi i saj nuk ishte praktik. Megjithatë, mekanizmi i cenueshëm datonte që nga WordPress 2.8 dhe rishfaqej gjatë çdo përditësimi, përfshirë përditësimet e pambikëqyrura.
Një firewall i implementuar në PHP, gjuha e programimit në të cilën funksionon WordPress, nuk mund ta bllokojë këtë kërkesë të veçantë. Patchstack shpjegon se kopja e nxjerrë ngarkon skedarët e vet të WordPress, ndërsa arkivi zyrtar nuk përmban mu-plugins directory për plugin-et që ngarkohen automatikisht, kështu që PHP firewall i faqes aktive nuk niset kurrë. Masa e rekomanduar mbrojtëse në nivel serveri është të ndalohet aksesi nga web-i në wp-content/upgrade/ dhe të konfirmohet se vizitorët nuk mund të shfletojnë përmbajtjen e tij. Ndërmjet përditësimeve, ai directory duhet të përmbajë vetëm index.php.
Shtatë njoftime kanë të bëjnë me Interactivity API, funksionaliteti i WordPress që u mundëson elementeve të faqes të reagojnë ndaj vizitorëve. KSES, sistemi i filtrimit që kontrollon se cilin HTML mund të ruajnë përdoruesit pa lejen unfiltered_html, lejonte çdo atribut dhe vlerë data-*. Direktivat e Interactivity përdorin këto atribute, kështu që Contributors mund të vendosnin direktiva në postime që i mbijetonin filtrimit dhe më pas ekzekutoheshin nga runtime në anën e shfletuesit kur dikush shihte faqen. Dobësitë që rezultonin përfshinin stored cross-site scripting, ose stored XSS, ku kodi i dëmshëm për shfletuesin ruhet në përmbajtjen e faqes dhe u dërgohet më vonë vizitorëve.
Problemet e Interactivity API përfshinin link-e javascript:, event-handler bindings që refuzoheshin tashmë nga ana PHP, reserved keys si __proto__ që hynin në një context merge, bindings të pasigurta në elemente object dhe një CSS parser që përpunonte vazhdimisht input-in e vet. Rasti me CSS mund ta ngrinte tab-in e shfletuesit të një vizitori, por nuk shteronte burimet e serverit. Njoftime të tjera trajtonin elemente object që ngarkonin faqe administrimi, prototype pollution, si dhe stored XSS së bashku me denial of service në bindings. Versioni 7.1.4 bën që KSES të heqë bindings që mund të ndryshojnë një vlerë të validuar më parë, kufizon bindings e elementit object në PHP directive processor dhe bën që client runtime të refuzojë target-e të pasigurta. Meqë client runtime u shfaq në versionin 6.4 dhe PHP class pasoi në 6.5, WordPress i rendit të dy versionet si të prekura nga i njëjti numër problemesh.
Një dobësi e lidhur me state shadowing lindi sepse Interactivity API përdorte getElementById() për të gjetur një script që përmbante state-in e tij. Ky funksion kthen ID-në e parë që përputhet, pavarësisht llojit të elementit, dhe WordPress e shfaqte script-in e ligjshëm në wp_footer pas përmbajtjes së postimit. Prandaj, një Contributor mund të vendoste në përmbajtjen e ruajtur një element më të hershëm me të njëjtën ID dhe t’i jepte state runtime-it. WordPress 7.1.4 tani verifikon që elementi i zgjedhur është vërtet një script. Një problem tjetër i Interactivity Router lejonte stored XSS përmes skedarëve tekst të ngarkuar dhe kërkonte një llogari të nivelit Author me leje për të ngarkuar skedarë.
U rregulluan gjithashtu dy probleme të Customizer. Selective refresh u besonte atributeve data-customize-partial-* nga përmbajtja e shfaqur në preview dhe i kalonte funksionit $() të jQuery një selector të kontrolluar nga sulmuesi. jQuery e interpreton një string që fillon me shenjën më i vogël se si HTML për t’u krijuar, në vend të një selector për t’u gjetur. WordPress tani përdor .find(), i cili përpunon vetëm selectors. Veçmas, një kërkesë anonime për preview pa një changeset UUID mund të merrte changeset-in më të ri të papublikuar, pavarësisht autorit të tij, duke ekspozuar UUID-në dhe preview-n e renderuar. Ndryshimi i settings vazhdonte të mbrohej nga leje të veçanta. Rregullimi kërkon capability customize.
Disa dobësi të block editor kishin të bënin me interpretimin sërish të përmbajtjes pas filtrimit. Categories block filtronte një etiketë dropdown dhe më pas e përdorte atë si sprintf() format string, duke lejuar që formatting directives të zgjeroheshin më pas. Image dhe Playlist blocks përdornin matched text të ndikuar nga sulmuesi si replacement për preg_replace(), ku PHP mund të zgjeronte backreferences si $0 dhe të fuste markup brenda një atributi. Këto blocks tani përdorin HTML API. Comments Pagination dhe Post Navigation Link blocks nuk i bënin escape atributeve të etiketave të tyre. Një problem i veçantë në Categories block, rregullimi forcues për Image dhe Playlist dhe këto etiketa pa escape kërkonin përkatësisht akses Contributor, Author dhe Contributor.
Parser-at e serverit dhe editor-it të WordPress gjithashtu nuk pajtoheshin për whitespace në block delimiters. PHP parser njihte gjashtë karaktere whitespace, ndërsa JavaScript pranonte gjithashtu non-breaking spaces, disa Unicode spaces dhe një byte order mark.