WordPress 7.1.4: kódfuttatás a frissítés közben, érintett-e az oldalad?

Október 28-án megjelent a WordPress 7.1.4, és vele együtt minden régebbi ág javított kiadása. A 22 javított hiba közül egy számít igazán: egy támadó bejelentkezés nélkül futtathat kódot a szerveren, de csak abban a pár másodpercben, amíg az oldal frissül. Az amerikai kiberbiztonsági hivatal, a CISA november 3-án felvette a hibát az aktívan kihasznált sebezhetőségek listájára.

A teendő a legtöbb oldalnál egyszerű: meg kell nézni, melyik verzió fut, és ha nem a javított, frissíteni kell. Azért írtam meg mégis, mert a saját mérésemben a cégoldalak között minden ötödik WordPress még a javítás előtti verzión van, és a többségüknél nem pár nap késésről van szó.

A rövid válasz

Mi a hiba, egyszerűen?

Amikor a WordPress frissül, nem közvetlenül az élő fájlokat írja felül. Előbb kicsomagolja a teljes új WordPresst egy átmeneti mappába, a wp-content/upgrade/ alá, és onnan másolja át a helyére. Ez a másolat néhány másodpercig ott van a szerveren, és a 7.1.4 előtt két baj volt vele: a mappa neve kitalálható volt, a WordPress pedig takarítás közben letörölte azt a fájlt, ami megakadályozza, hogy a mappa tartalmát kívülről végig lehessen nézni.

A kicsomagolt másolatban ott van a WordPress telepítője is, ami a saját beállítások nélkül is elindul. Aki pont ebben a pár másodpercben eltalálja a címét, az a te szervereden futtathatja le a telepítőt egy általa megadott adatbázissal, és innen jut el a kódfuttatásig. A hibát Umut Bayram jelentette. A javítás 16 véletlen karaktert fűz a mappa nevéhez, és a védő fájlt sem törli többé.

Az ilyen hibát versenyhelyzetnek hívják, mert a támadó azzal a rövid idővel versenyez, ami a fájlok kicsomagolása és törlése között eltelik. Ezért ismételgetik a kéréseket újra és újra, hátha egyszer elcsípnek egy frissítést.

Mennyire veszélyes?

Ebben a források nem egyeznek, és szerintem mindkét oldalnak igaza van. A Patchstack, egy WordPress-biztonsági cég, a gyakorlatban nehezen kihasználhatónak tartja, hiszen a támadónak pont a frissítés pillanatát kell eltalálnia. A CISA viszont aktívan kihasználtnak jelölte, a Cyber Security News pedig a Wordfence adataira hivatkozva azt írja, hogy a kiadás utáni első 21 órában több mint 18 500 kérés célozta a kicsomagolt telepítő útvonalát.

Ezek blokkolt kérések, nem feltört oldalak. Azt viszont megmutatják, hogy a támadók automata programokkal pásztázzák az oldalakat, és várják, mikor nyílik ki az ablak. Nem az számít tehát, hogy a te oldalad érdekes-e, hanem hogy a javítás előtti verzió fut-e rajta, és mikor frissül legközelebb.

Hány oldal érintett? A saját mérésem

A Sonar nevű mérőrendszeremmel magyar cégek weboldalait mérem, főleg székesfehérváriakat, ezért ez nem országos kép. A november 6-i adatban csak az október 30. utáni méréseket vettem figyelembe, oldalanként a legutolsót, hogy a frissítésre legyen két nap. Így 3 090 olyan WordPress-oldal maradt, aminek a verzióját pontosan látom.

A 192 oldal a legfrissebb ágon van, csak a 7.1.4 nem települt fel rájuk. Ezeket valaki néhány hete még frissítette, így a legtöbbjük valószínűleg pár napon belül utoléri magát.

A 468 a nagyobb gond. A WordPress a régi ágakra is kiadta a javítást, és alapbeállítás mellett ezek a kisebb biztonsági kiadások maguktól települnek. Ha egy 6.4-es vagy 5.x-es oldal ezt sem kapta meg, ott az automatikus frissítés ki van kapcsolva vagy nem működik, és valószínűleg hónapok, akár évek óta senki nem nézett rá. Ezeknél az oldalaknál a mostani hiba csak a tünet, az igazi baj az, hogy nincs gazdájuk.

Melyik verzió számít javítottnak?

Nem kell mindenkinek a 7.1.4-re frissíteni, mert minden ág megkapta a saját javított kiadását. Egy 6.8-as oldalnál tehát a 6.8.12 is rendben van. Ha a te verziód kisebb, mint a táblázatban az ágadhoz tartozó szám, az oldalad érintett.

A régebbi ágak javított kiadásai: 5.9.20, 5.8.19, 5.7.21, 5.6.23, 5.5.24, 5.4.25, 5.3.27, 5.2.30, 5.1.28, 5.0.31, 4.9.35, 4.8.34 és 4.7.39.

A verziószámot a kezelőfelület Frissítések oldalán és a jobb alsó sarokban is látod. A 4.7 előtti verziókra nem jött javítás. Rájuk ez a hiba a hivatalos leírás szerint nem vonatkozik, de egy ennyire régi WordPressen sok más ismert rés van nyitva, ott már arról kell dönteni, mi legyen az oldallal.

Mit tegyél, ha WordPress-oldalad van?

Ha az oldalad javított verzión van, nincs több teendőd ezzel a hibával. Ha nem, ezt a négy lépést csinálnám végig, ebben a sorrendben:

1. Készíts mentést, és frissíts. Ágon belüli biztonsági kiadásról van szó, ez ritkán okoz gondot. Ha viszont nagyobb verzióugrás is jönne vele, azt előbb egy másolaton próbáld ki, amit a saját gépeden is összerakhatsz.

2. Nézd meg, miért nem frissült magától. Ha a javítás nem jött meg, ki van kapcsolva az automatikus frissítés, vagy valami megakasztja. Ezt is rendbe kell tenni, különben a következő hibánál ugyanitt tartasz.

3. Nézd át a felhasználókat és a bővítményeket. Ha ismeretlen rendszergazdát, bővítményt vagy olyan fájlokat találsz, amiket nem te tettél fel, ott a frissítés kevés, szakember kell. A Cyber Security News a wp-content/upgrade/ alatti PHP-fájlokra érkező szokatlan kérések átnézését is javasolja a szervernaplóban.

4. Töröld a nem használt fiókokat. A többi javított hiba nagy része legalább közreműködő (Contributor) szintű fiókkal használható ki, így minden régi, elfelejtett szerkesztői fiók egy újabb belépési pont.

Ha most nem tudsz frissíteni

Előfordul, hogy egy régi oldal a frissítéstől tönkremenne, például egy rég elhagyott bővítmény miatt. Ilyenkor a Patchstack azt javasolja, hogy a webszerveren tiltsd le a wp-content/upgrade/ mappa elérését kívülről, és ellenőrizd, hogy a tartalma nem listázható. Két frissítés között ott jellemzően csak egy üres index.php van, ezért a látogatóknak semmi nem változik. Biztonsági bővítménnyel ezt nem tudod lezárni, mert a támadás a kicsomagolt másolatban fut, ahol a bővítmény nem töltődik be.

Apache-on a gyökérben lévő .htaccess fájlba ez az egy sor elég:

RedirectMatch 403 ^/wp-content/upgrade/

Nginx alatt a szerverblokkba:

location ^~ /wp-content/upgrade/ { deny all; }

Ez átmeneti megoldás. Egy oldal, ami a saját biztonsági javítását sem bírja el, a következő hibánál ugyanígy elakad, és akkor talán nem lesz ilyen egyszerű kerülőút.

Ezt a hibát a WordPress frissítése javítja, a Brotli-hibát nem

Ez pont fordítva van, mint a múlt heti HTTP2Shell-nél, ahol a WordPress frissítése nem segít, mert a hiba a szerver egyik könyvtárában van, és a tárhelyszolgáltatónak kell javítania. Itt a hiba a WordPressben van, ezért a szolgáltató nem tudja helyetted megcsinálni. A PHP októberi kritikus hibája szintén a szerveren múlt.

A három hibából együtt jól látszik, hogy egy weboldal biztonsága két rétegen múlik: a saját szoftvered frissítésén és a szerverén. Mindkettőre kell, hogy valaki rendszeresen ránézzen, és pont ez a weboldal karbantartás lényege.

Nem tudod, melyik verzió fut nálad?

Küldd el az oldalad címét, és megnézem, melyik WordPress-verzió látszik rajta kívülről, megkapta-e a javítást, és ha nem, mi lehet az oka. Írj nekem.

Források

• WordPress.org: WordPress 7.1.4 (2026. október 28.)

• CVE-2026-119977

• Patchstack: WordPress 7.1.4 Security Release

• Cyber Security News: CISA Warns of WordPress Core Vulnerability Exploited in Attacks

• CISA: Known Exploited Vulnerabilities Catalog