WordPress 7.0.2 Rregullon Injeksionin Kritik SQL pa Autentifikim

WordPress 7.0.2 rregullon një dobësi kritike të injeksionit SQL pa autentifikim që, kur kombinohet me një defekt konfuzioni të rrugës së REST API, mund t'i lejojë sulmuesit të marrin plotësisht nën kontroll një faqe interneti, sipas firmës së sigurisë Patchstack. Publikimi, i dërguar më 17 korrik 2026, adreson dy çështje të veçanta që së bashku krijojnë një zinxhir ekzekutimi në distancë të kodit. Patchstack verifikoi veçmas se dobësitë e kombinuara mund të çojnë në marrjen e plotë të faqeve dhe tashmë po shikon përpjekje aktive shfrytëzimi në regjistrat e saj.

Dy dobësitë janë gjurmuar si CVE-2026-60137 për injeksionin SQL në WP_Query dhe CVE-2026-63030 për konfuzionin e rrugës/trajtuesit të grupit të REST API. Çështja e parë prek versionet e WordPress 6.8 deri në 7.0.1, ndërsa e dyta u prezantua në 6.9 dhe gjithashtu prek deri në 7.0.1. Ekipi kryesor i WordPress lëshoi rregullime në tre degë: WordPress 7.0.2 rregullon të dyja, 6.9.5 është një backport i të dyjave në degën 6.9, dhe 6.8.6 nuk preket nga konfuzioni i rrugës, por përfshin patch-in e injeksionit SQL. Për shkak se dobësia është pa autentifikim dhe e shfrytëzueshme në masë, WordPress shtyu një përditësim të detyruar për faqet e prekura, megjithëse pronarët e faqeve duhet të konfirmojnë ende se janë në një version të patchuar.

Defekti i injeksionit SQL, i raportuar nga studiuesit TF1T, dtro dhe haongo, qëndron në mënyrën se si WP_Query, klasa e WordPress që ndërton pyetjet e bazës së të dhënave, trajton variablin e pyetjes author__not_in. Në versionet e prekura, kodi sanitizoi hyrjen vetëm kur ajo mbërrinte si një grup. Nëse një sulmues mund ta bëjë vlerën të mbërrijë si një varg, sanitizimi i numrit të plotë anashkalohet plotësisht. Vargu i papërpunuar më pas konvertohet në një grup, bashkohet dhe vendoset direkt në klauzolën SQL WHERE pa escape ose parametrizim të duhur. Vetëm për vete, kjo nuk është normalisht e arritshme sepse REST API vërteton parametrin author_exclude si një grup numrash të plotë. Por dobësia e dytë ndryshon atë rrugë përpunimi.

Defekti kritik i REST API, i raportuar nga Adam Kues i Assetnote / Searchlight Cyber, prek pikën fundore të grupit në WP_REST_Server::server_batch_request_v1(). Kjo pikë fundore i lejon një klienti të grupojë disa kërkesa nën-kërkese në një thirrje të vetme. Trajtuesi ndërton dy grupe: një për të gjitha kërkesat dhe një për trajtuesit e përputhur. Një desinkronizim i indeksit shfaqet sepse hyrjet e gabimit nuk shtohen në grupin e përputhjeve. Një sulmues mund të dërgojë së pari një nën-kërkesë me shtegun http://, e cila dështon në analizimin e URL-së dhe krijon një gabim në indeksin 0 pa një përputhje përkatëse. Pas kësaj, çdo kërkim i mëvonshëm i trajtuesit zhvendoset me një. Duke vendosur një grup të dytë brenda, sulmuesi arrin një kërkesë të tillë si GET /wp/v2/posts?author_exclude= në mënyrë që të vërtetohet kundër një trajtuesi tjetër, trajtuesit POST për krijimin e postimeve, ku author_exclude nuk është një filtër i regjistruar koleksioni dhe vërtetimi i tij normal i grupit të numrave të plotë nuk ekzekutohet kurrë. Pastaj ekzekutohet kundër përputhjes së zhvendosur për rrugën e koleksionit GET, duke thirrur funksionin get_items() pa autentifikim me një author_exclude të pavërtetuar. Rregullimi në 7.0.2 i mban grupet të rreshtuara në indeks duke shtyrë gjithashtu gabimet në grupin e përputhjeve dhe shton një mbrojtje kundër rihyrjes për të parandaluar fillimin e një cikli të ri të nivelit të lartë REST ndërsa një dërgesë është në fluturim.

Zinxhiri i kombinuar është serioz: një sulmues pa autentifikim mund të arrijë injeksionin SQL pa asnjë llogari, dhe Patchstack thotë se zinxhiri mund të çojë në marrjen e plotë të faqes, duke përfshirë ekzekutimin në distancë të kodit, që do të thotë se sulmuesi mund të ekzekutojë kodin e tij në server. Patchstack vendosi menjëherë rregullat e tij virtuale të patchimit RapidMitigate dhe ka parë përpjekje shfrytëzimi në regjistrat e tij. Për shkak të shfrytëzimit aktiv dhe natyrës pa autentifikim, ekipi kryesor i WordPress e trajtoi këtë si çështje me prioritetin më të lartë dhe shtyu një përditësim të detyruar për faqet e prekura. Për lexuesit që menaxhojnë faqet e tyre, hapi i menjëhershëm është të verifikojnë që faqja funksionon me WordPress 7.0.2, ose 6.9.5, ose 6.8.6, në varësi të degës. Është gjithashtu e mençur të rishikoni llogaritë e përdoruesve për çdo llogari administratori ose redaktori të panjohur, pasi sulmuesit që shfrytëzojnë këtë mund të krijojnë ose ngrenë përdorues. Shërbimet e hostimit të menaxhuar të WordPress si AEU Hosting janë ndërtuar për t'i mbajtur instalimet e WordPress të siguruara, gjë që mund të përfshijë përditësime automatike dhe mbrojtje në nivel serveri, por pronarët e faqeve duhet të konfirmojnë përsëri versionin e tyre siç rekomandohet.