Eelmisel kuul kirjutasime WordPressi turvaaugust, mis lubas ründajatel ilma paroolita sisse pääseda. See puudutas versioone 7.0.0 ja 7.0.1 ning rünnakut hakati kutsuma wp2shelliks. Botid otsisid internetist värskelt uuendatud veebilehti ja proovisid neid automaatselt üle võtta.
Seekord on turvaauk teine. WordPress 7.0.4 ilmus 12. augustil ja meie paigaldasime selle eile kõigile hoolduses olevatele veebilehtedele. Mitte sellepärast, et mõni neist oleks juba pihta saanud. Just vastupidi – turvauuenduse mõte on jõuda ette enne, kui algab järgmine rünnakulaine.
Kui jätad sellest loost meelde ainult ühe asja, siis selle: uuenda WordPress kohe. Allpool selgitan, mille poolest erinevad 7.0.3, 7.0.4 ja juulikuine turvaauk.
Kaks tõsist turvaparandust kuue päeva jooksul
WordPress 7.0.3 ilmus 6. augustil. See parandas CVE-2026-64638 turvaaugu, mille pwn.ai uurijad nimetasid XSS2Shelliks. Tegemist oli peegeldatud XSS-iga WordPressi sisselogimislehel wp-login.php. Turvaaugu käivitamiseks polnud kontot vaja, kuid serveris PHP-koodi käivitamiseks pidi ründaja meelitama juba sisse logitud administraatori avama spetsiaalselt koostatud linki.
Wordfence ja Patchstack kirjutasid sellest kiiresti ning järgmiseks hommikuks oli teema juba kõikjal. Põhjusega. Eduka rünnaku korral võis ründaja administraatori sessiooni abil luua rakenduse parooli, paigaldada pahatahtliku plugina ja jõuda lõpuks serveris koodi käivitamiseni.
Kuus päeva hiljem tuli WordPress 7.0.4 koos järgmise parandusega. CVE-2026-65640 lubab autori või suuremate õigustega kasutajal laadida üles pahatahtliku PostScript-faili. Kui server kasutab korraga Imagicki ja Ghostscripti, võib faili töötlemine lõppeda ründaja koodi käivitamisega serveris.
See pole teoreetiline sõnamäng. WordPress annab üles laaditud faili Imagickile töötlemiseks, Imagick kasutab teatud failide puhul Ghostscripti ning just selles ahelas tekib oht. Tulemus võib olla täielik kontroll veebilehe failide ja andmete üle.
Kas sinu server on üldse ohus?
Kui server kasutab piltide töötlemiseks ainult GD-teeki, siis see konkreetne rünnak ei toimi. Paljudes odavamates jagatud majutustes Imagicki polegi. VPS-ides ja suurema võimekusega majutuspakettides on Imagicki ning Ghostscripti kooslus aga üsna tavaline.
Enamik veebilehe omanikke ei tea, millist pilditöötlusteeki server kasutab. Ega peagi teadma. Seda ei näe WordPressi tavaseadetes ühe selge sisse-välja lülitina. Võid küsida majutajalt või vaadata PHP seadistust, kuid uuendamisega ei tasu vastust ootama jääda. Paigalda turvaparandus kohe. Hiljem võid täpsustada, kas sinu server kuulus selle turvaaugu sihtrühma.
Parandused tehti kättesaadavaks ka vanematele WordPressi harudele kuni versioonini 4.7. Kui sinu veebileht töötab veel 6.8 või 6.9 peal, paigalda sellele versioonile mõeldud turvaväljalase. Reede õhtul pole mõistlik paanikas 7.0 peale hüpata, kui suurem versiooniuuendus oli niikuinii eraldi testimist vajav töö.
Miks see pole sama mis juulikuine rünnak?
Juulikuine turvaauk ei nõudnud kasutajakontot. Seepärast levis see nii kiiresti. Puhastasime selle laine järel Eesti kosmeetika e-poe, tööstusettevõtte veebilehe ja veel ühe WooCommerce’i poe, kus pahavara oli jõudnud tegutseda 12 päeva. Samasse lainesse jäi ka Läti kütteettevõtte veebileht. Kõigi puhul oli sisenemistee wp2shell ning probleem sai alguse versioonide 7.0.0 ja 7.0.1 turvaaugust.
Versiooni 7.0.4 parandatud auk vajab vähemalt autori õigustega kontot. See vähendab võimalike ründajate hulka, kuid ei tee probleemi tähtsusetuks. Paljudes e-poodides saavad töötajad tootepilte üles laadida. Sama kehtib külalisautorite, sisuloojate ja praktikantide kohta. Kui konto satub valedesse kätesse, võib ründaja proovida turvaauku kasutada.
Siin aitab õiguste korrastamine. Kui inimene peab ainult mustandeid kirjutama, piisab WordPressi kaasautori rollist. Failide üleslaadimise õigus peaks jääma neile, kes seda päriselt vajavad. Aga rollide muutmine ei asenda turvaparandust. Kõigepealt uuendus, seejärel kasutajakontode ülevaatus.
Ükski meie hoolduses olev veebileht selle turvaaugu tõttu kannatada ei saanud. Me ei jäänud ka ootama, kuni esimene juhtum tekib.
Mida me eile tegime?
Paigaldasime 7.0.4 kõigile hoolduses olevatele veebilehtedele. Uuendus sisse, kontroll, et uus versioon jäi tööle, ja järgmine leht. See ongi WordPressi hoolduse igav pool. Ausalt öeldes meeldib see mulle palju rohkem kui häkitud veebilehe puhastamine.
Kui sinu veebileht käitub pärast juulikuist rünnakulainet endiselt imelikult ja seda pole korralikult puhastatud, on tuuma uuendamine vaid esimene samm. Kausta wp-content/uploads jäänud pahavara ei kao versiooninumbri muutmisega. Sellisel juhul on vaja häkitud veebileht põhjalikult puhastada: kontrollida faile, kasutajaid, andmebaasi ja võimalikke tagauksi.
Esimesed sammud on samad, millest kirjutasime loos mida teha kohe, kui kahtlustad veebilehe kompromiteerimist. Ära hakka suvaliselt faile kustutama. Tee koopia, kaardista kahjustused ja alles siis puhasta.
Kahtlane PostScript-fail meediakaustas on täpselt selline muutus, mille peaks avastama failide terviklikkuse jälgimine. See ei pööra rünnakut tagasi, kuid annab vähemalt märku, et veebilehele on ilmunud fail, mida seal olema ei peaks.
XSS2Shell lühidalt, et kaks CVE-d segamini ei läheks
Versioon 7.0.3 parandas sisselogimislehe XSS-i. Ründaja saatis pahatahtlikult koostatud wp-login.php lingi ning lootis, et administraator avab selle brauseris, kus ta on juba WordPressi sisse logitud. Sealt võis rünnak edasi liikuda rakenduse parooli loomise ja pahatahtliku plugina paigaldamiseni.
Kaheastmeline autentimine ei paranda XSS-i ega asenda WordPressi uuendamist. Küll aga vähendab see varastatud parooli väärtust ja teeb konto kuritarvitamise raskemaks. Üks kaitsekiht rohkem. Mitte imevahend.
Tee need kolm asja täna ära
- Ava WordPressis Töölaud → Uuendused ja paigalda 7.0.4 või sinu WordPressi harule mõeldud turvaväljalase.
- Kontrolli pärast uuendamist versiooninumbrit. Ära eelda, et automaatne uuendus kindlasti õnnestus.
- Vaata üle kasutajad, kellel on failide üleslaadimise õigus. Kui nad seda ei vaja, vähenda õigusi.
Automaatsed uuendused päästavad paljud veebilehed õigel ajal, kuid need võivad ka ebaõnnestuda. Põhjuseks võib olla kirjutuskaitsega failisüsteem, pooleli jäänud hooldusrežiim või majutaja piirang. Vaata versiooninumber ise üle. Kui seal pole 7.0.4 või sinu versioonile mõeldud turvaparandust, siis uuendus ei läinud läbi.
Juulikuine auk töötas ilma paroolita. 6. augusti parandus sulges sisselogimislehe XSS-i. 12. augusti parandus sulges autoriõigustega kasutaja kaudu toimiva PostScripti ründe. Me uuendasime kõik hoolduslehed eile. Sina võiksid oma veebilehe üle vaadata täna.