WP2Shell: spraga, kuri bet ką pavertė jūsų svetainės administratoriumi
Liepos 17 dieną paaiškėjo, kad WordPress kelias savaites turėjo spragą, leidžiančią bet kam iš interneto tapti svetainės administratoriumi. Be slaptažodžio. Be prisijungimo. Be jokio veiksmo iš jūsų pusės.
Ji vadinasi wp2shell. Oficialiai — CVE-2026-63030 ir CVE-2026-60137. Pavojingumo įvertinimas — 9.8 iš 10 galimų.
Šis tekstas ne apie tai, kaip veikia įsilaužimai. Jis apie tris dalykus, kurie svarbūs jums kaip verslo savininkui: ar jūsų svetainė buvo pažeidžiama, kaip tai patikrinti šiandien, ir kodėl atnaujinimo vieno neužtenka.
Kodėl ši spraga kitokia
Kasmet randama tūkstančiai WordPress spragų. Didžioji dalis jų — įskiepiuose. Kažkas parašė prastą kodą kalendoriaus ar formos priede, tai ištaisoma, gyvenimas teka toliau.
Wp2shell kitokia dėl trijų priežasčių.
Pirma, ji buvo ne įskiepyje, o pačioje WordPress šerdyje. Tai reiškia, kad pažeidžiamos buvo net „švarios“ svetainės, kuriose nėra nė vieno papildomo priedo. Argumentas „mes naudojame tik patikimus įskiepius“ čia negelbėjo.
Antra, jai išnaudoti nereikėjo jokios paskyros. Ne silpno slaptažodžio, ne pavogtų prisijungimų — tiesiog interneto adreso.
Trečia, ji neprašė vartotojo nieko daryti. Niekam nereikėjo paspausti nuorodos ar atidaryti priedo. Serveris pats atsakė į užklausą ir įsileido svečią.
Kai šie trys dalykai sutampa, saugumo pasaulyje tai vadinama blogiausiu įmanomu scenarijumi. Todėl JAV kibernetinio saugumo agentūra CISA liepos 21 d. įtraukė šią spragą į privalomų taisyti sąrašą ir davė federalinėms institucijoms tris dienas. Ne mėnesį. Tris dienas.
Kaip dvi klaidos tampa viena katastrofa
Įdomiausia, kad nė viena iš dviejų klaidų atskirai nebuvo katastrofiška.
Pirmoji buvo WordPress sąsajoje, kuri leidžia atlikti kelis veiksmus vienu kreipimusi. Ji nepakankamai griežtai tikrino, kam tie veiksmai iš tikrųjų priklauso.
Antroji buvo duomenų bazės užklausų sluoksnyje — tam tikromis aplinkybėmis į užklausą buvo galima įterpti savo turinį.
Atskirai — dvi nemalonios, bet ne mirtinos klaidos. Sujungus jas grandine, užpuolikas galėjo prasibrauti pro leidimų patikrą, pasiekti duomenų bazę, susikurti administratoriaus paskyrą ir galiausiai paleisti savo kodą jūsų serveryje.
Nuo „nieko baisaus“ iki „svetainė nebe jūsų“ — penki žingsniai.
Ir čia svarbi detalė, kurią verta įsidėmėti: pirmoji klaida atsirado kartu su WordPress 6.9 versija. Tai buvo naujas, patogus funkcionalumas. Ne aplaidumas, o patobulinimas, kurio šalutinio poveikio niekas nepastebėjo.
Patikrinkite savo svetainę per 30 sekundžių
Nereikia nei specialisto, nei įrankių.
- Prisijunkite prie svetainės administravimo — jūsų-svetainė.lt/wp-admin
- Kairėje pasirinkite „Valdymo skydas“, tada „Atnaujinimai“
- Pažiūrėkite versijos numerį viršuje
Saugu: 6.9.5 arba naujesnė, arba 7.0.2 arba naujesnė. Pavojinga: 6.9.0–6.9.4 arba 7.0.0–7.0.1.
Jei matote pavojingą versiją — atnaujinkite dabar. Ne po pietų, ne rytoj. Veikiantys įsilaužimo įrankiai internete pasirodė per kelias valandas nuo paskelbimo, ir jie iki šiol ieško neatnaujintų svetainių automatiškai. Niekas jūsų nesirinko asmeniškai — tiesiog skenuojamas visas internetas iš eilės.
Ir čia dauguma sustoja. Nereikėtų
Atnaujinimas užkiša skylę sienoje. Bet jis nepašalina to, kas per ją jau įlindo.
Jei jūsų svetainė kelias savaites stovėjo su pažeidžiama versija, vien versijos numerio pakeitimo nepakanka. Reikia patikrinti dar tris dalykus.
- Vartotojų sąrašas. Administravimo skydelyje atsidarykite „Vartotojai“ ir peržiūrėkite visus, kurie turi administratoriaus teises. Ar pažįstate kiekvieną? Ar kuris nors sukurtas per pastarąjį mėnesį be jūsų žinios?
- Failai. Ar svetainėje neatsirado failų, kurių niekas nekėlė — ypač įkėlimų aplanke, kur paprastai guli tik paveikslėliai ir dokumentai.
- Google Search Console. Jei ten pasirodė įspėjimų apie kenkėjišką turinį ar nesaugius puslapius — tai reiškia, kad Google jau pamatė tai, ko jūs dar nepastebėjote.
Radote bent vieną iš šių dalykų? Tada tai jau ne atnaujinimo, o valymo darbas. Ir jį verta daryti rimtai: užpuolikai beveik visada palieka bent vieną atsarginį įėjimą, kad galėtų grįžti po to, kai spraga bus užtaisyta.
Kas iš tikrųjų išgelbėjo didžiąją dalį svetainių
Atsakymas nemalonus: ne svetainių savininkai.
WordPress komanda, suprasdama masto rimtumą, įjungė priverstinius automatinius atnaujinimus. Tai reiškia, kad milijonai svetainių buvo pataisytos be jokio savininko sprendimo. Tiesiog vieną naktį.
Tai geros naujienos. Bet jose slypi nemalonus klausimas.
Jei jūsų svetainė šįkart išsisuko, ji išsisuko todėl, kad kažkas kitas priėmė sprendimą už jus. Kitą kartą taip gali ir nenutikti — priverstiniai atnaujinimai įjungiami tik ypatingais atvejais, o dauguma spragų taisomos įprasta tvarka ir laukia, kol kas nors paspaus mygtuką.
Klausimas, kurį verta sau užduoti, yra ne „ar mano svetainė atnaujinta“. Klausimas yra: kas ir kada tai tikrina.
Jei atsakymas yra „na, kai prisimenu“ arba „turbūt hostingas kažką daro“ — tai ne saugumo strategija. Tai viltis.
Ką daryti šią savaitę
Trys darbai, kurie užtruks mažiau nei valandą.
- Patikrinkite WordPress versiją visose savo svetainėse. Ne tik pagrindinėje — dažnai pamirštamos senos akcijų svetainės, testiniai adresai ir subdomenai. Būtent jos paprastai ir būna neatnaujintos.
- Peržiūrėkite administratorių sąrašą. Pašalinkite paskyras žmonių, kurie pas jus nebedirba, ir buvusių rangovų prieigas.
- Išsiaiškinkite, kas atsakingas už atnaujinimus. Jei niekas — tai ir yra jūsų didžiausia spraga, nepriklausomai nuo to, kokia CVE bus kita.
Šįkart WordPress įjungė automatinius atnaujinimus ir uždengė daugumą. Kitą kartą gali tekti spėti patiems.
O kokia WordPress versija veikia jūsų svetainėje? Jei nesate tikri — parašykite mums, padėsime išsiaiškinti.