WordPress wp2shell pažeidžiamumas: viešas išnaudojimo kodas ir kritinė nuotolinio kodo vykdymo grėsmė

WordPress wp2shell pažeidžiamumas viešas išnaudojimo kodas ir kritinė nuotolinio kodo vykdymo grėsmė

Abiem pažeidžiamumams jau suteikti CVE identifikatoriai, viešai paskelbtas visas jų veikimo principas, nustatyta sąlyga, susijusi su nuolatine objektų podėlio sistema, o internete pasirodė veikiantis pažeidžiamumo išnaudojimo pavyzdys. Toliau pateiktame straipsnyje atsižvelgiama į visus šiuos pokyčius.

Viena anoniminė HTTP užklausa gali leisti įvykdyti programinį kodą WordPress svetainėje. Pažeidžiamumas yra pačioje WordPress branduolio sistemoje, todėl atakai tinka net visiškai naujas diegimas be jokių įskiepių. Iki penktadienio pavojus grėsė visoms svetainėms, naudojusioms WordPress 6.9 arba 7.0 versijas. Tą dieną WordPress išleido 6.9.5 ir 7.0.2 versijas bei per automatinio naujinimo sistemą įjungė vadinamuosius priverstinius naujinimus.

Wp2shell sudaro ne vienas, o du atskiri pažeidžiamumai. Abiem jau priskirti CVE numeriai. CVE-2026-63030 susijęs su WordPress REST API paketinių užklausų maršruto supainiojimu, o CVE-2026-60137 yra SQL injekcijos spraga WordPress branduolyje. Sujungus abu pažeidžiamumus į vieną atakos grandinę, anoniminė užklausa gali baigtis nuotoliniu programinio kodo vykdymu.

Po penktadienio viešai paskelbtas išsamus atakos veikimo mechanizmas. GitHub platformoje taip pat atsirado praktiškai veikiantis koncepcijos įrodymas.

Paketinių užklausų maršruto pažeidžiamumą aptiko Adam Kues iš Assetnote. Ši bendrovė yra Searchlight Cyber padalinys, užsiimantis išorinio atakos paviršiaus valdymu. Apie problemą tyrėjas pranešė per WordPress naudojamą HackerOne pažeidžiamumų atskleidimo programą.

Techniniame aprašyme, paskelbtame wp2shell pavadinimu, nurodoma, kad atakai nereikia jokių išankstinių sąlygų, o pažeidžiamumu gali pasinaudoti neprisijungęs ir tapatybės nepatvirtinęs naudotojas. Apie SQL injekciją atskirai pranešė TF1T, dtro ir haongo.

Kibernetinis saugumas

Searchlight kol kas neviešina savo išsamaus techninio tyrimo ir svetainių savininkams siūlo naudotis wp2shell.com paskelbtu tikrinimo įrankiu. Tačiau toks atsargumas šiuo metu jau nebeturi didelės praktinės reikšmės. Pataisa yra vieša, todėl kiti saugumo tyrėjai galėjo išanalizuoti pakeistą programinį kodą.

Abu pažeidžiamumai veikia skirtingas WordPress versijas. Būtent nuo naudojamos versijos priklauso, kokio pobūdžio ataka gali būti įvykdyta. SQL injekcijos pažeidžiamumas egzistuoja nuo WordPress 6.8. Paketinių užklausų maršruto supainiojimo klaida, leidžianti riboto poveikio SQL injekciją paversti neautentifikuotu nuotoliniu kodo vykdymu, atsirado tik WordPress 6.9 versijoje.

Paveiktų versijų intervalai:

  • WordPress 6.8.0 iki 6.8.5 veikia tik SQL injekcija. Pažeidžiamumas ištaisytas 6.8.6 versijoje.
  • WordPress 6.9.0 iki 6.9.4 galima išnaudoti visą nuotolinio kodo vykdymo grandinę. Ji pašalinta 6.9.5 versijoje.
  • WordPress 7.0.0 iki 7.0.1 taip pat pažeidžiamos visa RCE atakos grandine. Pataisa įtraukta į 7.0.2 versiją.
  • WordPress 7.1 beta2 versijoje jau yra abi pataisos.

WordPress 6.8 svetainėje šia konkrečia grandine negalima pasiekti nuotolinio kodo vykdymo. Dėl šios priežasties 6.8.6 versijoje ištaisyta tik SQL injekcijos spraga.

WordPress nepateikė aiškaus atsakymo, ar priverstinis naujinimas įdiegiamas ir tose svetainėse, kurių administratoriai buvo išjungę automatinius naujinimus. Todėl nereikėtų manyti, kad pataisa jau įdiegta. Būtina patikrinti faktinę svetainėje veikiančią WordPress versiją.

Searchlight publikacijoje apskaičiuota, kad WordPress naudoja daugiau kaip 500 mln. svetainių. Šis skaičius apima visą WordPress diegimų bazę, o ne tik pažeidžiamas svetaines. Visa nuotolinio kodo vykdymo grandinė egzistuoja tik nuo 6.9 versijos, išleistos 2025 m. gruodžio 2 d. Vadinasi, visos šiuo kodo vykdymo būdu pažeidžiamos svetainės naudoja mažiau nei prieš aštuonis mėnesius išleistą WordPress versiją. Nė viename saugumo pranešime nepateikiama informacija, kiek tokių svetainių iš tikrųjų yra.

Atakos grandinę sudaro dvi iš pirmo žvilgsnio nedidelės programinio kodo klaidos. SQL injekcija yra WP_Query parametro author__not_in apdorojimo mechanizme. Kai šiam parametrui vietoje masyvo perduodama tekstinė eilutė, masyvui skirta patikra nėra pritaikoma. Dėl to neapdorota reikšmė tiesiogiai patenka į duomenų bazės užklausą.

Anoniminiam naudotojui pasiekti šį parametrą leidžia paketinių užklausų galinis taškas. WordPress maršrutas /wp-json/batch/v1 viena užklausa įvykdo kelias vidines užklausas ir jų informaciją saugo dviejuose lygiagrečiuose masyvuose. Kai vienoje vidinėje užklausoje įvyksta klaida, masyvų elementų pozicijos pasislenka viena vieta. Dėl šios priežasties viena užklausa gali būti įvykdyta naudojant kitai užklausai priskirtą apdorojimo funkciją.

Naudojant įdėtines užklausas, toks neatitikimas leidžia apeiti galinio taško leidžiamų operacijų sąrašą ir perduoti užpuoliko pateiktus duomenis pažeidžiamai duomenų bazės užklausai. Prisijungti prie sistemos tam nereikia. Pats paketinių užklausų galinis taškas WordPress sistemoje naudojamas nuo 5.6 versijos, išleistos 2020 m., tačiau jo išnaudojimą leidžianti supainiojimo klaida atsirado tik 6.9 versijoje.

Pažeidžiamumų pavojingumo balus verta vertinti atidžiai. WordPress savo saugumo pranešime visą nuotolinio kodo vykdymo grandinę priskiria kritinio pavojingumo kategorijai. Tačiau atitinkamame CVE įraše jai suteiktas 7,5 balo įvertinimas, reiškiantis aukštą, bet ne kritinį pavojingumą. Poveikio rodikliuose įvertinama tik galimybė pasiekti duomenis. Neatsižvelgiama į duomenų vientisumo ar sistemos pasiekiamumo praradimą, kuris paprastai siejamas su programinio kodo vykdymu. SQL injekcijos pažeidžiamumas įvertintas daugiau kaip 9,1 balo ir priskirtas kritinei kategorijai.

Taigi pažeidžiamumas, dažniausiai apibūdinamas kaip kritinis nuotolinio kodo vykdymas, pagal jam suteiktą balą laikomas mažiau pavojingu iš šių dviejų. Vertinimo sistema tiesioginę SQL injekcijos prieigą prie duomenų bazės laiko reikšmingesne, o atskirai vertinamą maršruto supainiojimą traktuoja kaip užklausos apdorojimo klaidą. Dėl to būtina sekti abu CVE numerius, o ne pasikliauti vieno iš jų pavojingumo kategorijos pavadinimu.

Atakos poveikį riboja viena papildoma sąlyga. Cloudflare duomenimis, nuotolinio kodo vykdymo grandinė veikia tik tada, kai svetainėje nenaudojama nuolatinė objektų podėlio sistema. Cloudflare kartu su informacijos apie pažeidžiamumą paskelbimu išleido ir žiniatinklio programų ugniasienės taisykles. Standartiniame WordPress diegime nuolatinio objektų podėlio nėra, todėl įprastai įdiegtos svetainės išlieka pažeidžiamos.

WordPress svetainė, naudojanti Redis arba Memcached kaip nuolatinį objektų podėlį, gali būti apsaugota nuo šio konkretaus nuotolinio kodo vykdymo kelio. Vis dėlto tai yra tik šalutinis techninės konfigūracijos poveikis, o ne pažeidžiamumo pataisa. Tokia konfigūracija taip pat neapsaugo nuo SQL injekcijos.

Suteikus pažeidžiamumams CVE numerius, juos pagaliau gali aptikti automatiniai pažeidžiamumų skaitytuvai. Rapid7 pranešė, kad autentifikuotos InsightVM ir Nexpose patikros bus išleistos liepos 20 d. Pažeidžiamumai dar nėra įtraukti į JAV Kibernetinio saugumo ir infrastruktūros saugumo agentūros CISA žinomų išnaudojamų pažeidžiamumų katalogą KEV. Į šį sąrašą pažeidžiamumas įtraukiamas tik gavus patvirtinimą apie realų jo naudojimą atakose. Iki liepos 18 d. apie patvirtintus išnaudojimo atvejus nebuvo pranešta. Vis dėlto tai suteikia mažiau pagrindo jaustis saugiai, nei gali pasirodyti.

Masinis WordPress pažeidžiamumų išnaudojimas

Plataus masto WordPress svetainių pažeidžiamumų išnaudojimas jau tapo atskira nusikalstama veiklos sritimi. Dar prieš birželį įvykusį jų serverio duomenų nutekėjimą WP-SHELLSTORM grupuotė teigė per vieną podėlio įskiepio pažeidžiamumą patekusi į daugiau kaip 17 tūkst. svetainių. Tuo metu naudota spraga jau buvo viešai žinoma ir ištaisyta, be to, ją buvo galima išnaudoti tik įjungus nestandartinį nustatymą. Wp2shell pažeidžiamumo informacija taip pat jau paskelbta ir pataisa išleista, tačiau šiuo atveju ataka veikia esant numatytiesiems nustatymams.

Ką daryti, jeigu šiandien atnaujinti nepavyksta

Visos Searchlight siūlomos laikinos apsaugos priemonės grindžiamos tuo pačiu principu: anoniminiams naudotojams turi būti užkirstas kelias pasiekti paketinių užklausų galinį tašką. Šie sprendimai tinka tik iki WordPress atnaujinimo ir gali sutrikdyti teisėtai veikiančias integracijas.

  • Žiniatinklio programų ugniasienėje būtina blokuoti tiek /wp-json/batch/v1, tiek rest_route=/batch/v1. Reikia uždrausti abu adresavimo būdus, nes taisyklė, apimanti tik /wp-json kelią, neužblokuoja per užklausos parametrą pasiekiamo maršruto. Cloudflare skelbia, kad jos valdoma WAF sistema jau blokuoja šią atakos grandinę svetainėse, kurių srautas nukreipiamas per Cloudflare.
  • Galima išjungti WordPress REST API. Tokiu atveju visiškai panaikinama neautentifikuota prieiga prie REST sąsajos.
  • Searchlight taip pat paskelbė nedidelį papildomą įskiepį, kuris naudojant rest_pre_dispatch mechanizmą atmeta anonimines /batch/v1 užklausas.

WordPress branduolio programinis kodas yra atviras, o naujos versijos apraše nurodyti pakeisti failai. Vien šios informacijos pakako pažeidžiamumui atkurti. Searchlight savo techninio tyrimo nepaskelbė, tačiau per vieną dieną kiti tyrėjai išanalizavo pataisą, aprašė visą veikimo mechanizmą ir GitHub platformoje paskelbė išnaudojimo kodą. Būtent tokio scenarijaus buvo bandoma išvengti kontroliuojant informacijos paskelbimo laiką.

Neįmanoma išplatinti pataisos kartu neatskleidžiant, kurioje programinio kodo vietoje yra pažeidžiamumas. Vienintelė likusi galimybė yra kuo greičiau įdiegti pataisą svetainėse, kol užpuolikai dar nespėjo išanalizuoti pakeitimų. Penktadienį WordPress šį procesą paspartino priverstiniais naujinimais.

Dabar veikiantis pažeidžiamumo išnaudojimo kodas jau yra viešas, o naujinimo diegimas svetainėse vis dar tęsiasi. WordPress versijų statistika parodys, kiek svetainių įdiegė pataisą. Tuo metu užklausų į batch/v1 maršrutą stebėsena atskleis, kiek užpuolikų pradėjo ieškoti pažeidžiamų sistemų. Šio incidento pasekmes nulems tai, kuri iš šių dviejų kreivių kils greičiau.

Apie autorių

Mantas Jankauskas
Mantas Jankauskas SeoRocket.lt

Specializuojasi techniniuose web sprendimuose, svetainių greitaveikoje ir SEO reikalavimų įgyvendinime. Jis dirba su techniniu SEO, migracijomis, struktūriniais pakeitimais ir kitais darbais, kurie turi tiesioginę įtaką svetainių indeksavimui, stabilumui ir naudotojų patirčiai.

Autoriaus straipsniai
Kitas straipsnis CyberPanel ar Cloudpanel: Kuris geresnis pasirinkimas? Skaityti