WordPress 7.1.4 rregullon RCE në core mes sondimeve aktive të sulmuesve
WordPress 7.1.4 u publikua më 28 tetor 2026, me rregullime për 22 dobësi sigurie, duke përfshirë një dobësi remote code execution (RCE) pa autentikim, e cila mund t’i lejojë një sulmuesi të ekzekutojë kod në një server pa u identifikuar më parë. Wordfence raporton se sulmuesit filluan ta kërkonin dobësinë pak pas publikimit të përditësimit të sigurisë. Pronarët e faqeve duhet të konfirmojnë se WordPress ka instaluar versionin 7.1.4 ose përditësimin përkatës të sigurisë për degën e tyre më të vjetër, në vend që të supozojnë se përditësimi automatik përfundoi me sukses.
Problemi më serioz prek versionet 4.7 deri në 7.1.3 të WordPress Core dhe ka një rezultat CVSS prej 8.1, të vlerësuar High. CVSS, ose Common Vulnerability Scoring System, është një shkallë standarde që përdoret për të përshkruar rrezikshmërinë e një dobësie sigurie. Dobësia është një race condition, që do të thotë se sulmuesi duhet të veprojë gjatë një periudhe të shkurtër kur dy procese mbivendosen. Nuk kërkohet llogari në faqe, por sulmuesi duhet ta kapë WordPress ndërsa po shpaketon një përditësim të plotë të Core.
Gjatë këtij lloji përditësimi, versionet e cenueshme nxjerrin skedarët e rinj të WordPress në një direktori të parashikueshme nën wp-content/upgrade. Kjo staging directory, një vendndodhje e përkohshme që përdoret përpara se skedarët e rinj të aktivizohen, përfshin instaluesin e WordPress. Në shumë serverë, ajo mund të arrihet nga web-i publik. Një sulmues që e gjen ose e parashikon shtegun mund të kërkojë vazhdimisht skedarin e përkohshëm setup-config.php dhe të ndërveprojë me instalimin e përkohshëm përpara se WordPress ta heqë atë. PHP është gjuha e programimit në anën e serverit që përdoret për të ekzekutuar WordPress dhe arritja e këtij skedari të përkohshëm PHP mund të lejojë përfundimisht ekzekutimin e kodit në host.
Duhet të përmbushen disa kushte. WordPress duhet të jetë duke përpunuar një paketë të plotë që përmban skedarët e instaluesit, direktoria e përkohshme duhet të lejojë akses publik përmes web-it dhe akses PHP, shtegu duhet të jetë i parashikueshëm ose të zbulohet dhe sulmuesi duhet të përfundojë përpara pastrimit. Wordfence thotë se testimet laboratorike zbuluan se direktoria e cenueshme zakonisht mbetej e disponueshme vetëm për disa sekonda. Prandaj, një kërkesë e vetme ka pak gjasa të ketë sukses, por kontrollimi automatik i përsëritur mund ta testojë vazhdimisht një faqe në përpjekje për të kapur këtë hapësirë kohore.
WordPress 7.1.4 e ndryshon këtë proces duke e bërë të rastësishme staging directory, duke vendosur në të një mbrojtje index dhe duke bllokuar kalimin e pasigurt të të dhënave të përkohshme të konfigurimit. Rregullimet u përshtatën edhe për versionet e mëparshme, deri te WordPress 4.7. Versionet e korrigjuara janë 4.7.39, 4.8.34, 4.9.35, 5.0.31, 5.1.28, 5.2.30, 5.3.27, 5.4.25, 5.5.24, 5.6.23, 5.7.21, 5.8.19, 5.9.20, 6.0.18, 6.1.16, 6.2.15, 6.3.14, 6.4.14, 6.5.14, 6.6.11, 6.7.11, 6.8.12, 6.9.11, 7.0.8 dhe 7.1.4. WordPress 4.6 dhe versionet më të hershme nuk marrin më përditësime sigurie dhe duhet të kalojnë në një version që mbështetet.
Sondimi aktiv filloi shpejt. Wordfence vendosi një rregull të ri firewall në orën 20:30 UTC më 28 tetor, afërsisht tri orë pas publikimit të përditësimit të sigurisë të WordPress. Një firewall filtron kërkesat që mund të jenë keqdashëse përpara se ato të arrijnë në faqe. Klientët e Wordfence Premium, Care dhe Response e morën rregullin menjëherë, ndërsa përdoruesit e Wordfence Free pritet ta marrin më 27 nëntor 2026, pas vonesës standarde prej 30 ditësh.
Wordfence regjistroi përputhjen e parë me atë rregull nëntë minuta pas vendosjes së tij. Gjatë 21 orëve të para, telemetria e kompanisë, domethënë të dhënat për ngjarjet e sigurisë të mbledhura nga faqet e mbrojtura, numëroi më shumë se 18,500 kërkesa të drejtuara ndaj shtigjeve të përkohshme setup-config.php. Dy nga burimet më të mëdha kontrolluan vazhdimisht grupe të vogla faqesh për rreth 14.5 orë. Burime të tjera provuan kombinime të shumta të staging directory dhe emrave të versioneve. Wordfence vëren se jo çdo kërkesë përdori shtegun e saktë të cenueshëm, por thotë se kontrollimi i vazhdueshëm dhe strukturat e sakta të direktorive tregojnë se sulmuesit e kishin kuptuar dhe kishin filluar të synonin dobësinë që lidhet me kohën. Raporti nuk deklaron se çdo përpjekje ishte e suksesshme.
Rregulli firewall ka një kërkesë të rëndësishme për vendosjen. Kërkesa keqdashëse shkon drejtpërdrejt te një skedar i përkohshëm PHP pa ngarkuar më parë WordPress. Prandaj, faqet që përdorin Wordfence kanë nevojë për modalitetin e tij Extended Protection, i cili e aktivizon firewall përpara se kërkesat e drejtpërdrejta PHP të arrijnë te skedari i kërkuar. Një rregull firewall mund ta zvogëlojë ekspozimin, por nuk e heq sjelljen e cenueshme të Core dhe nuk zëvendëson instalimin e një versioni të korrigjuar.
Rregullimet e tjera në WordPress 7.1.4 mbulojnë disa kategori sigurie. Dobësi të shumta stored cross-site scripting (XSS), ku kodi i dëmshëm i shfletuesit ruhet në një faqe dhe më pas i shfaqet një përdoruesi tjetër, përfshinin kufizuesit e block, block Categories, etiketat Comments Pagination dhe Post Navigation, rifreskimin përzgjedhës të Customizer, kërkesat për fshirjen e të dhënave personale, emrat e përdoruesve të krijuar posaçërisht dhe përpunimin e block Image dhe Playlist. Disa kërkojnë një llogari Contributor, Author ose Editor dhe disa varen gjithashtu nga hapja e përmbajtjes së kontrolluar nga sulmuesi prej një përdoruesi me më shumë privilegje. Këto kërkesa e kufizojnë ekspozimin krahasuar me RCE pa autentikim, por stored XSS mund të shkaktojë përsëri marrjen nën kontroll të llogarisë ose ndryshime të paautorizuara në faqe.
Publikimi korrigjon gjithashtu probleme të Interactivity API që përfshijnë lidhje të pasigurta URL, event-handler, internal-property dhe object. Një API është një mënyrë e përcaktuar për shkëmbimin e udhëzimeve ose të të dhënave ndërmjet komponentëve software. Rregullime të tjera mbulojnë prototype pollution, ku input ndryshon vetitë e trashëguara nga objekte të tjera software, mbivendosjen e të dhënave të Script Module, përpunimin e skedarëve tekst të ngarkuar në Interactivity Router dhe një gjendje të vazhdueshme denial of service, e cila mund ta mbajë një shërbim të padisponueshëm duke shteruar ose bllokuar burimet e tij.
Përditësime të tjera trajtojnë zbulimin pa autentikim të changesets të papublikuara të Customizer dhe një dobësi autorizimi në Notes REST API. Ky problem me lejet prekte rolet e personalizuara që lejoheshin të moderonin komentet, por jo të redaktonin postimin që përmbante një shënim. U përditësuan gjithashtu root certificates të përfshira, të cilat e ndihmojnë software të vendosë se cilave lidhje të enkriptuara t’u besojë, pas revokimit të eMudhra.
Pronarët, faqet e të cilëve mbetën të pakorrigjuara, duhet të shqyrtojnë kërkesat ndaj skedarëve PHP nën wp-content/upgrade dhe të kontrollojnë për llogari të panjohura administratori, plugins të papritura ose skedarë PHP që nuk i kanë shtuar vetë. Wordfence rekomandon gjithashtu kryerjen e një skanimi pas përditësimit për të identifikuar skedarë të ndryshuar të Core, skedarë keqdashës ose prova të tjera që kërkojnë hetim. Për pronarët e faqeve që po shqyrtojnë se ku qëndron përgjegjësia për sigurinë e WordPress, AEU Hosting ofron managed WordPress hosting të siguruar nga fillimi në fund.
Përparësia e menjëhershme është të hapni Dashboard > Updates dhe të verifikoni versionin e instaluar. Përditësimet automatike në sfond duhet t’ua shpërndajnë rregullimin shumicës së faqeve, por një përditësim i dështuar ose i vonuar do ta linte në fuqi sjelljen e cenueshme të upgrade. Konfirmimi i versionit, kontrollimi për veprimtari të dyshimta dhe hetimi i ndryshimeve të papritura janë të nevojshme, sepse sulmuesit aktivë tashmë po përpiqen të kapin intervalin e shkurtër të përditësimit.