WordPress 7.1.4 ilmus 28. oktoobril 2026. See on turvauuendus ja WordPress.org soovitab selle kohe paigaldada. Kui su lehel on automaatsed taustauuendused, võib see juba tehtud olla. Võib. Just seda kontrolliksin enne kõike muud.
Uuendus, 30. okt: ründajad on hakanud upgrade-kausta viga ära kasutada proovima. Täpsemalt allpool uues lõigus.
Üle tasub vaadata ka üks serveri seadistus: kas külastaja pääseb brauseriga ligi kaustale wp-content/upgrade/. Üks parandustest puudutab seda, mis seal uuenduse ajal toimub. Tehnilise poole hoian lühikese ja siis vaatame, mida väikeettevõtte lehel täna ette võtta.
Mida see versioon parandab?
Patchstacki järgi parandab 7.1.4 kokku 22 turvanõrkust, mida käsitletakse 17 turvateates. Seda on ühe versiooni kohta palju: kolm nädalat varem ilmunud 7.1.3 parandas seitse. Number kõlab ehmatavalt, aga see ei tähenda, et 22 suvalist inimest saaks tänavalt su lehele sisse murda.
Peale kahe erandi vajab ründaja kõigepealt vähemalt Contributor-tasemel kontot. Lihtsalt öeldes: inimene, kes saab postitusi kirjutada, võis peita sisusse skripti, mis käivitub siis, kui haldur või külastaja selle avab. Seitse turvateadet puudutavad Interactivity API salvestatud XSS-vigu: teatud data-* atribuudid pääsesid sisufiltrist läbi. Parandusi said ka plokkide märgistus, Customizer, kommentaaride lehekülgede plokid, Author-taseme üleslaadimine ning kohandatud rollide Notes-õigused.
- Sisuloomisega seotud vead on põhjus kasutajakontod üle vaadata, mitte põhjus postitamisega lõpparve teha.
- Üks väiksem viga lubas kontota külastajal avastada avaldamata Customizeri muudatuste komplekte. Nüüd nõuab ligipääs customize-õigust.
- Uuendus vahetab välja ka juursertifikaadid pärast eMudhra tühistamist.
Ei Patchstack ega WordPress.org-i väljalasketeade ütle, et neid vigu oleks päriselt rünnakutes kasutatud. See ei tõesta, et keegi pole proovinud. Sellist järeldust ma ei teeks.
Miks vajab upgrade-kaust eraldi tähelepanu?
Serveri poolel tegeleksin esimesena WordPressi uuendusprotsessi ajastusveaga, millest teatas Umut Bayram. Selle jaoks pole kontot vaja. Kui WordPress midagi paigaldab või uuendab, pakib ta failid kausta wp-content/upgrade/. Veebiserver võib seda kausta külastajale näidata nagu teisigi lehe kaustu.
Enne 7.1.4 versiooni sai ajutise kausta nime paketi nime järgi ära arvata. Koristus võis eemaldada ka faili index.php, mis takistab kausta sisu loetlemist. Nii võis uuenduse ajal mõneks sekundiks olla arvata saadaval aadressil nähtav terve WordPressi koopia, sealhulgas wp-admin/setup-config.php. See koopia käivitub ilma saidi tavapärase seadistuseta. Õigel hetkel sinna jõudes võinuks ründaja käivitada su lehe kaustas paigaldaja oma kontrolli all oleva andmebaasiga.
Ajaaken on kitsas. Patchstack hindab ärakasutamise keeruliseks ega peaks seda praktiliseks ründeviisiks. Samas avaneb sama aken iga uuendusega uuesti, ka automaatsega, ja nõrk koht on pärit juba WordPress 2.8 ajast. Sisselogimist ega lehe omaniku tegevust pole vaja. Lühike ajaaken pole minu meelest põhjus seda tähelepanuta jätta.
Uuendus, 30. okt: rünnakud on alanud
Päev pärast väljalaset teatas Wordfence, et ründajad juba proovivad uuenduse ajaakna viga ära kasutada. Esimene tabamus nende tulemüüri reeglile tuli üheksa minutit pärast reegli lisamist. Esimese 21 tunniga loendasid nad üle 18 500 päringu, mis olid suunatud ajutise setup-config.php paigaldaja aadressidele.
Muster on selline, nagu ajastusvea puhul oodata võib: mõned allikad pommitasid väikest hulka lehti umbes 14,5 tundi järjest, lootes tabada neid paari sekundit, kui uuendus parasjagu käib. Teised proovisid läbi palju kaustanimede ja versioonide variante. Kõik päringud ei kasutanud täpselt haavatavat teed ja ükski allikas, mida lugesime, ei teata veel kinnitatud sissemurdmisest.
Soovitused jäävad samaks, lihtsalt kiiremaks:
- Kontrolli
Dashboard > Updatesalt, et leht päriselt jookseb versioonil 7.1.4 (või oma haru parandatud versioonil). - Blokeeri veebist ligipääs kaustale
wp-content/upgrade/, nagu allpool näidatud. - Kui leht jäi uuendamata, otsi logidest päringuid PHP-failidele kaustas
wp-content/upgrade, uusi adminikasutajaid, tundmatuid pluginaid või PHP-faile, mida sa sinna ei pannud.
Kui kasutad Wordfence’i: rünne kutsub PHP-faili otse välja ilma WordPressi laadimata, seega on Wordfence’i sõnul selle vastu vaja tulemüüri Extended Protection režiimi. Tulemüüri reegel ei asenda uuendust.
Mis WordPressis muutus?
Versioon 7.1.4 lisab ajutise kausta nimele 16 juhuslikku märki. Samuti loob WordPress faili index.php uuesti ega kustuta seda enam ning takistab faili wp-config.php kopeerimist töökaustast välja. Need on WordPressi enda parandused.
Patchstacki versiooniloendi järgi jõudsid parandused tagasi ka vanematesse harudesse kuni 4.7-ni, muu hulgas versioonidesse 7.0.8 ja 4.7.39. WordPress.org-i teate avaldamise ajal olid need parandused veel valmimas ja pidid ilmuma jooksvalt. Seega kontrolli oma haru uusimat saadaolevat uuendust, ära otsusta ainult ühe versiooninumbri põhjal. WordPress 4.6 ja vanemad parandust ei saa. Aktiivselt toetatakse ainult uusimat WordPressi versiooni; vana haru turvaparandus pole hea põhjus sinna lõputult jääda. WordPress 7.2 on plaanis 8. detsembriks.
Tee need asjad täna ära
- Kontrolli, kas uuendus jõudis kohale. Ära eelda, et automaatne update läks lõpuni. Ava
Dashboard > Updatesja otsi teadet „You have the latest version of WordPress.” Versiooninumbrit näed ka haldusvaate jaluses või kohasTools > Site Health > Info > WordPress. Kui keegi teie tiimist kasutab WP-CLI-d, annabwp core versionkiire vastuse. Vanema haru puhul otsi selle haru uusimat turvaparandust, näiteks 7.0 harul 7.0.8. Sa ei pea seal nägema numbrit 7.1.4. - Keela veebist ligipääs upgrade-kaustale. See kaitse toimib ka uuenduse ajal. PHP-põhine tulemüür või turvaplugin ei pruugi siin aidata: lahti pakitud koopia laadib oma WordPressi failid ja sinu lehe tulemüür selle päringu jaoks ei käivitu. Apache puhul pane järgmine rida lehe juurkaustas olevasse peamisse
.htaccessfaili, WordPressi plokist kõrgemale. Ära pane seda kaustawp-content/upgrade/, sest WordPress koristab seda.RedirectMatch 403 ^/wp-content/upgrade/Nginxi puhul peab serveri seadistuses serveriploki sees olema see:
location ^~ /wp-content/upgrade/ { deny all; }Seejärel ava brauseris
https://yoursite/wp-content/upgrade/. Soovitud vastus on 403 Forbidden, mitte failide nimekiri. Uuenduste vahel peaks selles kaustas olema ainultindex.php. Uuendused töötavad edasi, sest WordPress kirjutab sinna PHP kaudu, mitte külastaja brauseripäringuga. Kui sul pole hallatud majutuses serveri seadistusele ligipääsu, palu majutajal see aadress blokeerida ja tulemus kinnitada. Meie WordPressi veebimajutuse puhul tegeleme serveri seadistusega ise. - Vaata üle, kes saab sisu kirjutada. Mine vaatesse
Users > All Usersning filtreeri Contributor-, Author- ja Editor-rolliga kasutajad. E-poes kontrolli ka Shop manager’i ja muid poerolle. Eemalda endiste töötajate, vabakutseliste ja agentuuride kontod, mida enam ei kasutata. Kui inimene vajab kontot edasi, aga mitte avaldamisõigust, vähenda tema õigusi. Vähem kirjutajaid tähendab vähem kontosid, mille kaudu need sisuga seotud vead ohtu tekitavad. Kui kaasad uut abilist, loe ka, kuidas anda arendajale ligipääs nii, et kontroll jääb sulle. - Pane uuenduste kontroll kalendrisse. Automaatsed uuendused aitavad, aga keegi peab märkama, kui uuendus ebaõnnestub, ning pärast lehe üle vaatama. Kui sa ei taha seda ise teha, kuulub see meie WordPressi hoolduse juurde. Ligipääse kontrollides vaata üle ka vanad ühendused: rakenduse paroolide 10 minuti kontroll aitab sellega alustada. Endise kirjutaja konto kustutamine ei näita veel, millised muud ligipääsud alles jäid.
Alusta kontrollist, mille vastust näed ise
Ava kõigepealt Dashboard > Updates ja vaata siis brauseris upgrade-kausta aadressi. Mõlemad annavad konkreetse vastuse, millega saad täna midagi peale hakata. Kui kaust ei tagasta 403 vastust, palu serveri haldajal see korda teha enne, kui selle punkti nimekirjast maha tõmbad.