Uuendasid eelmisel nädalal? Tee seda uuesti
WordPress 7.1.1 tuli välja 17. septembril ja sisaldas 11 turvaparandust. Kui said uuenduse tehtud, tegid õigesti. Aga juba 22. septembril ilmus WordPress 7.1.2 - eraldi turvauuendus, mis parandab ühe kriitilise vea.
Teine uuendus viie päeva jooksul on tüütu, eriti kui sul on e-pood, broneerimisleht või ettevõtte koduleht ja sul on peale WordPressi veel küllalt teha. Seekord ei tasu siiski järgmise hoolduspäevani oodata.
Patchstack nägi 22. septembril kell 17.44 UTC esimesi päringuid, millega otsiti haavatavaid saite - vähem kui viis tundi pärast versiooni avaldamist. Tegu oli haavatavate saitide otsimisega: kinnitust polnud ei pahatahtliku koodi edastamise, serveris koodi käivitamise ega sissemurdmise kohta. Viis tundi jätab reageerimiseks väga vähe aega.
Mida CVE-2026-87902 päriselt tähendab?
CVE-2026-87902 raskusaste on CVSS 4.0 skaala järgi 9,2 punkti. Viga puudutab WordPressi versioone 4.7.0 kuni 7.1.1. WordPress 4.7 tuli välja 6. detsembril 2016, nii et turvaauk püsis koodis peaaegu kümme aastat.
Ründajal pole selle proovimiseks vaja WordPressi kasutajakontot ega sisselogimist. Viga tekib siis, kui WordPress otsib leheküljele sobivat malli. Kindlal viisil kodeeritud päring võib panna WordPressi otsima malli ettenähtud kaustast väljastpoolt - seda nimetatakse inglise keeles path traversal. Kui WordPress kaasab selle tõttu mõne muu serveris oleva PHP-faili, on tulemuseks kohaliku faili kaasamine ehk LFI.
Praktikas on siin üks tähtis tingimus. Aktiivse teema põhikaustas peab olema alamkaust, mille nimi algab page-. Levinud näide on page-templates. Kui sellist kausta pole, siis kirjeldatud viisil kohalikku PHP-faili kaasata ei saa, isegi kui WordPressi versioon kuulub haavatavate versioonide hulka.
Kohaliku PHP-faili kaasamine ei tähenda veel automaatselt, et ründaja saab serveris oma käske käivitada. Et ründaja saaks serveris eemalt koodi käivitada (RCE), peab seal olema sobiv PHP-fail, mida veebiserver saab lugeda. Kirjeldatud ründeviis kasutab PEAR-i faili pearcmd.php ja eeldab, et PHP seade register_argc_argv on sisse lülitatud. See sõltub serveri seadistusest. Seega ei saanud iga vana WordPressiga saiti üheainsa päringuga täielikult üle võtta.
Mõni tund hiljem otsiti juba haavatavaid saite
Patchstacki tuvastatud päringud sihtisid WordPressi tuuma tavalisi PHP-faile. Vastuste põhjal kontrolliti, kas WordPress avas küsitud faili. Selline päring aitab leida võimalikke sihtmärke, kuid üksi ei tõesta sissemurdmist.
Päringutes kasutati täpselt seda kodeeringut, mille WordPressi parandus kinni pani. Patchstack järeldas sellest, et päringute koostaja võrdles avalikult nähtavat vana ja uut koodi ning sai nii aru, mida proovida. See on tugev vihje meetodi kohta, mitte tõend tegija kohta.
AI ei tekitanud ligi kümme aastat vana turvaauku. Samuti pole tõendeid, et AI koostas just need päringud. Küll aga saab AI ja tavalise automatiseerimise abil koodimuudatusi kiiremini võrrelda, päringuvariante koostada ning korraga paljusid saite kontrollida. Just sellepärast on paranduse avaldamise ja esimeste katsete vahe nüüd nii lühike.
Sama kiiresti saavad tegutseda ka kaitsjad. Automatiseerimine leiab vanad WordPressi versioonid, AI aitab sarnaseid logiridu kokku rühmitada ja inimene kontrollib, mida leiud päriselt tähendavad. WordPressi haavatavuste kontroll aitab uuendamata saidid kiiresti üles leida, kuid uuendamist see ei asenda.
Kolm juhtumit, kolm eri viga
Juulis avalikuks tulnud wp2shelli ründeahel oli eraldi juhtum, mille ärakasutamiseks polnud samuti vaja WordPressi sisse logida. Augustis sulges WordPress 7.0.4 teise vea, mis võimaldas serveris koodi käivitada. Seal pidi ründajal olema vähemalt autori rolliga konto ning serveris pidid olema kasutusel Imagick ja Ghostscript.
CVE-2026-87902 töötab teisiti: viga peitub lehekülje malli valimises ja kohaliku PHP-faili avamiseks peavad olema täidetud eespool kirjeldatud tingimused. Neid juhtumeid ei tasu kokku võtta sõnadega “WordPressi murti jälle”. Õige tegutsemine sõltub alati sellest, mida viga võimaldab ja mida selle kasutamiseks vaja on.
Ühine õppetund on lihtne. Kui WordPressi enda kriitilist turvaauku saab ära kasutada ilma sisse logimata, tuleb sellega tegeleda samal päeval. Kui arvasid eelmisel nädalal, et WordPressi uuendamisega on selleks kuuks ühel pool, kontrolli versiooni uuesti. Miks selline harjumus kasulik on, selgitame lähemalt loos sellest, miks WordPressi uuendusi ei tohi edasi lükata.
Mida täna teha?
Ära eelda, et sisselülitatud automaatuuendused tähendavad kindlasti uut versiooni. Failiõigused, teenusepakkuja reeglid, katkenud taustatöö või kinni jäänud hooldusrežiim võivad jätta saidi vanale versioonile, ilma et sa seda märkaksid. Ava juhtpaneel ja kontrolli versiooninumber üle.
- Tee kiire varukoopia või loo hostingu juhtpaneelis saidi taastepunkt.
- Paigalda WordPress 7.1.2 ja vaata pärast uuendust uuesti, millist versiooni juhtpaneel näitab.
- Kontrolli sisselogimist, kontaktivormi ja broneerimist. E-poes vaata üle ostukorv ning kassaleht, tee võimalusel väike testost ja veendu, et klient jõuab pärast makset õigele kinnituslehele ning tellimus saab õige staatuse.
Kui suurem versioonihüpe pole täna tõesti võimalik, paigalda oma praeguse versiooniharu turvauuendus. Näiteks on olemas 7.0.6, 6.9.9 ja 6.8.10. Sama turvaparandus anti välja ka WordPress 4.7 harule versioonina 4.7.37. Kõige uuem WordPress on endiselt parim siht, kuid parandatud vana versioon on parem kui turvaaugu lahti jätmine.
Kui saite on mitu, muutub selline teine uuendusring kiiresti omaette tööpäevaks. Regulaarse WordPressi hooldusega saab versioonid, varukoopiad, uuendused ja oluliste funktsioonide testid ühe korraga üle vaadata.
Kui sait oli enne paranduse paigaldamist avalikult kättesaadav
Vaata üle päringud aadressidele / ja /index.php. Kontrollida tuleb nii URL-i parameetreid kui ka POST-päringu sisu. Kahtlane on juhtum, kus pagename sisaldab topeltkodeeritud jada %252e%252e ja samas päringus olev page_id viitab päriselt olemasolevale lehele.
Kui veebirakenduse tulemüür (WAF) või mõni muu süsteem salvestas ka vastuse sisu, otsi tavalise leheaadressi vastusest ootamatut OPML-väljundit või mõne WordPressi tuumafaili sisu. See võib olla märk, et WordPress avas küsitud faili. Säilita vajalikud logiväljavõtted enne, kui vanad logid automaatselt kustutatakse.
- Pane kirja vana ja uus WordPressi versioon ning uuenduse täpne kellaaeg.
- Salvesta selle ajavahemiku veebiserveri, PHP, tulemüüri ja hostingu logid.
- Kontrolli, kas aktiivse teema põhikaustas on kaust, mille nimi algab
page-. - Kui logid näitavad faili edukat avamist, kahtlast PHP käivitamist, seletamatut failimuudatust või uut administraatorit, uuri võimalikku turvaintsidenti põhjalikumalt.
Üks sellise mustriga päring pole veel sissemurdmine. See võib tähendada ainult seda, et skanner koputas uksele ja kontrollis vastuse põhjal, kas sait on haavatav. Patchstack nägi haavatavate saitide otsimist, kuid mitte pahatahtliku koodi edastamist, serveris koodi käivitamist ega kinnitatud sissemurdmist.
Uus lihtne reegel: tegutse samal päeval
WordPress 7.1.2 on teine uuendus viie päeva jooksul. Ebamugav? Muidugi. Aga avalik parandus näitab nii kaitsjale kui ka ründajale, millist koodiosa muudeti, ja seekord otsiti haavatavaid saite vähem kui viis tundi hiljem.
AI ei muuda iga turvauudist automaatselt AI-rünnakuks. Tegelik muutus on argisem: AI ja automatiseerimine võivad aidata koodimuudatusi kiiremini analüüsida ning korraga suurt hulka saite kontrollida. Seepärast võiks sellise kriitilise WordPressi vea puhul, mille ärakasutamiseks pole vaja sisse logida, olla tegutsemisplaan lihtne ja alati sama - varukoopia, uuendus, versiooni kontroll ning äri jaoks tähtsate funktsioonide testimine veel samal päeval.
Uuendasid eelmisel nädalal? Hea. Tee seda nüüd uuesti.