WordPress 7.1.1 frissítés: tizenegy biztonsági hiba javítva. Miért telepítsd még ma?

A WordPress fejlesztőcsapata 2026. szeptember 17-én kiadta a 7.1.1-es verziót, amely tizenegy biztonsági hibát és 36 további programhibát javít, a kiadási közlemény pedig egyértelműen fogalmaz: minden oldaltulajdonos a lehető leghamarabb frissítsen. A WordPress 7.1.1 frissítés elsőre unalmas karbantartásnak tűnik, hiszen a verziószám végén csak egy szerény egyes áll, a javítások listáján viszont ott van egy bejelentkezés nélkül, hozzászóláson keresztül kihasználható XSS-hiba, egy speciális hivatkozással kiváltható tématelepítés és egy fájlútvonal-bejárásos (path traversal) sérülékenység a REST API-ban. Ha a céged honlapja WordPressen fut (a W3Techs 2026. szeptember 21-i adatai szerint a világ összes weboldalának 40,2%-a ilyen), akkor ez a hír rólad szól.

Hogy miért ma kell ezzel foglalkozni és nem a jövő heti fejlesztői egyeztetésen, arra a Patchstack biztonsági cég 2026 februárjában kiadott éves jelentése ad kijózanító választ: a WordPress-ökoszisztémában egy sérülékenység első kihasználásáig eltelt idő súlyozott mediánja mindössze öt óra. A következőkben 2026. szeptember 22-i állapot szerint végigvesszük, mit javítottak pontosan, melyik hiba a legveszélyesebb egy tipikus céges oldalon, hogyan ellenőrizheted, hogy a rendszered magától frissült-e már, végül azt is, hogyan telepítsd a javítást biztonsági mentéssel, nagyjából öt perc alatt. Külön szakaszt kap az a helyzet is, amikor egyedi téma vagy évek óta nem frissített bővítmény fut az oldalon, mert tapasztalatunk szerint a legtöbb halogatás mögött éppen ez a félelem áll.

Röviden

• A WordPress 7.1.1 frissítés 2026. szeptember 17-én jelent meg tizenegy biztonsági javítással, 17 core- és 19 blokkszerkesztő-hibajavítással, a biztonsági javításokat pedig a fejlesztők a 4.7-es ágig visszamenőleg is elérhetővé tették.
• A legsürgősebb javítás a wpautop() függvény tárolt XSS-hibája (CVE-2026-93485, CVSS-pontszám: 7,1), mert ezt bejelentkezés nélkül, egy hozzászóláson keresztül lehet kihasználni, így minden nyitott kommentekkel működő céges blogot érint.
• A Pantheon tárhelyszolgáltató összefoglalója szerint a többi hiba többségéhez bejelentkezett, legalább Közreműködő szerepkörű felhasználó kell, ami a külsős szövegírókkal, több szerzővel vagy regisztrált vásárlókkal működő oldalaknál valós kockázat.
• A WordPress a kisebb javítókiadásokat alapértelmezetten magától telepíti, de ha ezt a tárhely, egy bővítmény vagy a wp-config.php beállítása kikapcsolta, kézzel kell frissítened: mentés, frissítés, majd egy ötperces ellenőrzés a legfontosabb oldalakon.
• Egyedi téma vagy régi bővítmény esetén először tesztkörnyezetben (staging) próbáld ki a frissítést, de ne halogasd napokig, mert a Patchstack szerint a nagy hatású sérülékenységek nagyjából felét 24 órán belül kihasználják.
• A W3Techs 2026. szeptember 21-i adatai szerint a WordPress-oldalak 30,6%-a még a 6-os főverzión fut, ezeknél a biztonsági javítás csak visszaportolt kiadásokon keresztül érkezik, a hivatalos támogatás pedig kizárólag a legújabb ágra vonatkozik.

Mi az a WordPress 7.1.1 frissítés és miért sürgős?

A WordPress 7.1.1 a WordPress tartalomkezelő rendszer 2026. szeptember 17-én kiadott karbantartási és biztonsági kiadása, amely tizenegy sérülékenységet zár be a 7.1-es és a korábbi verziókban. Azért sürgős, mert a javítással együtt a hibák is nyilvánosságra kerültek, a támadók pedig ilyenkor órákon belül elkezdik keresni a frissítetlen oldalakat.

A WordPress verziószámozásában az első két számjegy (7.1) a nagy, funkcióbővítő kiadást jelöli, a harmadik (7.1.1) pedig a karbantartási, más néven minor kiadást, amely nem hoz új funkciót, csak hibajavításokat. A 7.1-es főverzió „Mary Lou” néven jelent meg olyan újdonságokkal, mint a reszponzív stílusállapotok vagy az ikonregisztráció, a mostani 7.1.1 viszont kizárólag javít: a hivatalos közlemény 17 core-, 19 blokkszerkesztő- és 11 biztonsági javítást sorol fel. A kiadást Adam Silverstein, Adrian Duffell, Andrei Draganescu és Aaron Jorbin vezette, a The Repository nevű WordPress-hírlevél szerint pedig több mint 90 közreműködő dolgozott rajta.

Aki nem fejlesztő, annak elég egyetlen szabályt megjegyeznie: a harmadik számjegyet léptető kiadások javítókiadások, amelyek gyakran biztonsági javítást is tartalmaznak, ezért a WordPress a 3.7-es verzió óta ezeket alapértelmezetten magától telepíti. Ez jó hír, mert a rendesen karbantartott oldalak jelentős része már a megjelenés napján megkapta a javítást. A rossz hír az, hogy az automatikus frissítés sok céges oldalon ki van kapcsolva, amiről a tulajdonos gyakran nem is tud (az okokat lejjebb külön szakaszban vesszük sorra).

A tétet jól mutatja, hogy a W3Techs 2026. szeptember 21-i adatai szerint a WordPress a világ összes weboldalának 40,2%-át, az ismert tartalomkezelőt használó oldalaknak pedig 58,8%-át hajtja. A WordPress-oldalak 62,3%-a a 7-es főverzión fut, 30,6%-a a 6-oson, 4,9%-a az 5-ösön, 2,0%-a a 4-esen, 0,2%-a pedig még mindig a 3-ason, vagyis nagyjából minden harmadik WordPress-oldal nem a legfrissebb főverziót használja.

A fejlesztők a biztonsági javításokat a 4.7-es ágig visszamenőleg is kiadták ott, ahol a hiba az adott ágat is érintette, ami első hallásra megnyugtató, de érdemes pontosan érteni, mit jelent. A WordPress core csapata 2026. január 9-i közleményében leírta, hogy hivatalosan csak egyetlen, a legújabb ág kap biztonsági frissítést, a régebbi ágakra pedig csak gesztusként, a lehetőségekhez mérten portolják vissza a javításokat. Aki tehát egy régi ágon ragadt, az most még kap javítást, a hosszú távú biztonságát viszont nem építheti erre a jóindulatra.

Van a kiadásnak egy kordokumentum-jellegű része is. A tizenegy hibából kettőt, a REST API sablonkezelőjének path traversal hibáját és a Közreműködő szintről végrehajtható bejegyzés-felülírást az Anthropic mesterségesintelligencia-cég jelentette, a speciális URL-lel kiváltható tématelepítést pedig Paulos Yibelo biztonsági kutató és a pwn.ai. A The Repository 2026. szeptember 18-i cikke szerint júliustól kezdve minden WordPress biztonsági kiadás köszönetnyilvánításai között szerepel valamilyen AI-cég.

Ez a védekezők szempontjából jó hír, hiszen ezeket a hibákat jóhiszemű kutatók találták meg és jelentették felelősen, a folyamatnak viszont van egy kellemetlen mellékhatása: ha a gépek gyorsabban találnak hibát, a biztonsági kiadások is sűrűsödnek, a támadók eszközei pedig ugyanilyen tempóban fejlődnek. Az OpenAI 2026. szeptember 3-án bemutatott GPT-6 Astra modellje a cég közlése szerint az ExploitBench kiberbiztonsági teszten 100%-ot ért el és a tesztek alatt két korábban ismeretlen (zero-day) hibát is talált. A tanulság egy KKV számára egyszerű: a „majd negyedévente ránézünk” típusú frissítési rend 2026-ban már nem tartható.

Mit javít a WordPress 7.1.1: XSS a wpautop() függvényben, jogosulatlan tématelepítés és path traversal a REST API-ban

A WordPress 7.1.1 tizenegy biztonsági hibát javít: két tárolt XSS-hibát (a wpautop() függvényben és az egyedi fejlécet támogató témákban), egy HTML API-hibát, egy speciális URL-lel kiváltható tématelepítést, egy path traversal hibát a REST API-ban, egy XML-RPC-megkerülést, továbbá több jogosultsági hibát, amelyek bejegyzések felülírását vagy adatok kiszivárgását tették lehetővé.

Az alábbi táblázat mind a tizenegy hibát felsorolja a WordPress.org hivatalos közleménye alapján, közérthető magyarázattal és a hibát jelentő kutató nevével. A Pantheon 2026. szeptember 18-i összefoglalója szerint a hibák többségéhez bejelentkezett, legalább Közreműködő szerepkörű felhasználó kell, az egyetlen kivétel a wpautop() XSS-hibája, amelyhez nem kell bejelentkezni. CVE-azonosítót (a nyilvános sérülékenységi nyilvántartás egyedi számát) szintén csak ez a hiba kapott, a WordPress a többihez nem rendelt ilyet.

A wpautop() XSS: miért pont a hozzászólás a gyenge pont?

A wpautop() a WordPress egyik legrégebbi segédfüggvénye, amely a szövegben lévő dupla sortöréseket bekezdésekké alakítja, vagyis ez felel azért, hogy egy hozzászólás vagy egy klasszikus szerkesztőben írt bejegyzés szépen tagolt bekezdésekként jelenjen meg. Az XSS (cross-site scripting, webhelyek közötti parancsfuttatás) olyan sérülékenység, amelynél a támadó által bejuttatott kód egy másik felhasználó böngészőjében fut le, a megbízható weboldal nevében. A tárolt változat azért különösen kellemetlen, mert a kártékony tartalom bekerül az adatbázisba, onnan pedig mindenki megkapja, aki megnyitja az érintett oldalt.

A Patchstack 2026. szeptember 18-i elemzése szerint a hiba a WordPress 7.1-es és minden korábbi verzióját érinti, CVE-2026-93485 azonosítót és 7,1-es CVSS 3.1 pontszámot kapott, a belépési pontja pedig a névtelen hozzászólás. A The Repository hozzáteszi, hogy a kód csak akkor jut a látogatók elé, ha a hozzászólást jóváhagyják, ami elvben védelmet ad, a gyakorlatban viszont egy ártalmatlannak tűnő komment könnyen átcsúszik egy fáradt moderátor keze alatt. A Patchstack ajánlása saját fordításunkban így szól: „a nyilvános hozzászólásokat engedő oldalak ezt kezeljék a kiadás első számú javításaként, különösen ott, ahol a moderálást másra bízták vagy a visszatérő hozzászólók kommentjei automatikusan megjelennek”.

Egy céges oldalon a sikeres XSS-támadás tipikus következménye a látogatók átirányítása csaló oldalakra, rejtett spamlinkek beszúrása, rosszabb esetben pedig műveletek végrehajtása az adminisztrátor nevében, ha éppen ő nyitja meg a fertőzött hozzászólást. A megfertőzött oldalt a Google Biztonságos Böngészés szolgáltatása figyelmeztető oldallal jelölheti meg, ami egy webshopnál vagy egy ajánlatkérő oldalnál gyakorlatilag a forgalom elvesztésével egyenértékű.

Jogosulatlan tématelepítés: mi az a Click2Shell?

A negyedik hiba mögött húzódik a kiadás legérdekesebb története. A Patchstack kutatója, Chazz Wolcott, szeptember 18-án Click2Shell néven írta le azt a hibaláncot, amelyet Paulos Yibelo (pwn.ai) jelentett: egy megfelelően összeállított hivatkozás rávehette a bejelentkezett adminisztrátor böngészőjét, hogy telepítsen és előnézetben megnyisson egy inaktív témát a WordPress.org témakönyvtárából. A lánc egy CSRF-hibára (cross-site request forgery, amikor a támadó a bejelentkezett felhasználó böngészőjével hajtat végre nem kívánt műveletet) és egy úgynevezett szelektorinjektálásra épül, a Patchstack szerint pedig egy sérülékeny témával kombinálva akár távoli kódfuttatásig (RCE) is eljuthat.

A jó hír, hogy ehhez egy bejelentkezett adminisztrátornak ténylegesen meg kell nyitnia a hivatkozást, például egy célzott adathalász e-mailből, vagy az oldalon már lennie kell egy másik XSS-hibának. A Patchstack azt is kiemeli, hogy azokon az oldalakon, ahol a wp-config.php fájlban be van kapcsolva a DISALLOW_FILE_MODS beállítás (ez letiltja a bővítmények és témák telepítését és frissítését az adminfelületről), a kitettség korlátozott. A Patchstack cikke nem tesz említést valós támadásban megfigyelt kihasználásról, a javítás mégis indokolt, mert egy KKV-nál az adminisztrátor gyakran maga a cégvezető, aki naponta több tucat e-mailt nyit meg ugyanabban a böngészőben, amelyben a WordPress-be is be van jelentkezve.

Path traversal a REST API-ban és a jogosultsági hibák

A REST API a WordPress beépített programozói felülete, amelyen keresztül a blokkszerkesztő, a mobilalkalmazások és a külső integrációk adatot kérnek le és módosítanak. A path traversal (fájlútvonal-bejárás) olyan hibatípus, amelynél egy manipulált fájlútvonal segítségével a program a számára kijelölt könyvtáron kívül eső fájlokhoz is hozzáférhet. A 7.1.1 ezt a hibát a sablonokat kezelő REST Templates Controllerben javította, a kihasználásához bejelentkezés kell, a jelentője pedig az Anthropic volt.

Ugyanebbe a csoportba tartoznak a jogosultsági hibák: a Közreműködő szintről elérhető bejegyzés-felülírás, a piszkozatok slugjának kiszivárgása, a privát szülőbejegyzések címének felfedése, a hozzászólások és jegyzetek átszülősítése, amelyhez bármely bejelentkezett felhasználó elég volt, valamint az XML-RPC felületen keresztüli publikálás a CSS-szerkesztési jog ellenőrzése nélkül. Ezek egyenként kevésbé látványosak, együtt viszont jól mutatják, hogy a WordPress szerepkörei csak akkor védenek, ha a core pontosan ellenőrzi őket, ezért minden felesleges felhasználói fiók felesleges kockázat is. A multisite hálózatokat érintő hiba csak a több aloldalt egy rendszerben kezelő telepítéseket érinti, egy átlagos, egyetlen honlapból álló KKV-oldalt nem.

Melyik hiba a legveszélyesebb egy céges oldalon?

Egy tipikus magyar KKV-honlapon a wpautop() tárolt XSS-hibája a legveszélyesebb, mert a kihasználásához nem kell bejelentkezni, elég hozzá egy nyitott hozzászólási mező. Ha az oldalon külsős szerzők, ügynökségi fiókok vagy regisztrált vásárlók is vannak, a bejelentkezéshez kötött jogosultsági hibák és a REST API path traversal hibája kerül a lista élére.

A kockázat tehát nem a hibák elméleti súlyosságán múlik, hanem azon, ki fér hozzá az oldaladhoz és milyen funkciók vannak rajta bekapcsolva. Érdemes ezért néhány képzeletbeli, de nagyon ismerős oldaltípuson végigmenni, mert a legtöbb magyar céges honlap valamelyikre hasonlít.

Vegyünk először egy balatoni panziót, amelynek a honlapján programajánló blog is fut, a bejegyzések alatt pedig nyitva vannak a hozzászólások, mert a tulajdonos szerint ez jót tesz a vendégkörnek. Itt a wpautop() hiba jelenti a legnagyobb veszélyt: a támadónak nem kell fiók, csak egy hozzászólás, a moderálást pedig főszezonban a recepciós végzi két vendég érkezése között a telefonján. Ha a rosszindulatú komment átcsúszik, a benne rejlő kód minden olyan látogatónál lefuthat, aki megnyitja az adott bejegyzést, ami egy szobafoglalásból élő oldalnál egyenesen üzleti kockázat.

Tegyük fel ezután, hogy egy budapesti könyvelőiroda honlapján három külsős szövegíró dolgozik Közreműködő szerepkörrel, a tavalyi ügynökségi együttműködésből pedig két aktív fiók is maradt. Itt a bejegyzés-felülírás és a piszkozatok slugjának kiszivárgása a valós kockázat: egy feltört vagy rossz kezekbe került szövegírói fiókkal át lehetett írni olyan bejegyzést is, amelyhez a fióknak semmi köze, a még nem publikált szolgáltatásoldalak címe pedig idő előtt kiderülhetett. A REST API path traversal hibája szintén bejelentkezett felhasználót igényel, így ugyanez a fiókkör jelent kitettséget.

Egy képzeletbeli debreceni webshopnál, ahol a vásárlók regisztrálnak és be is jelentkeznek, a bejelentkezett felhasználó fogalma akár több ezer embert is jelenthet. A hozzászólások átszülősítéséhez a hivatalos közlemény szerint bármely bejelentkezett felhasználó elég volt, vagyis elvben egy vásárlói fiók is. Mivel a WooCommerce termékértékelései technikailag szintén hozzászólásként tárolódnak, egy webshopnál az értékelések moderálását is érdemes a blogkommentekkel azonos szigorral kezelni, legalább addig, amíg a frissítés fel nem kerül.

Végül ott van egy kecskeméti asztalosüzem bemutatkozó oldala öt aloldallal, kikapcsolt hozzászólásokkal és egyetlen adminisztrátorral, aki maga a tulajdonos. Itt a hibák többsége egyszerűen nem tud érvényesülni, a kockázat a Click2Shell-típusú láncokban rejlik, amelyekhez egy rosszkor megnyitott hivatkozás is elég lehet. Ez a legalacsonyabb kockázatú eset, a frissítést mégsem érdemes kihagyni, mert öt perc munka áll szemben egy esetleges teljes újratelepítéssel.

Egy sikeres támadás ára ritkán áll meg a honlapnál. Ha a támadó spamlinkeket vagy átirányításokat helyez el, a Google Search Console Biztonsági problémák jelentésében megjelenhet a figyelmeztetés, a keresési láthatóság pedig a takarítás és a felülvizsgálati kérelem elbírálásáig sérülhet. Ha pedig az ajánlatkérő űrlapok vagy a vásárlói fiókok személyes adatai is érintettek, az már adatvédelmi incidens: a GDPR 33. cikke szerint ezt indokolatlan késedelem nélkül, lehetőség szerint 72 órán belül be kell jelenteni a felügyeleti hatóságnak, Magyarországon a NAIH-nak, kivéve ha az incidens valószínűleg nem jár kockázattal az érintettekre nézve.

Miért órákban mérjük a frissítés határidejét?

Azért, mert egy biztonsági kiadás egyben térkép is: a javításból kiolvasható, hol volt a hiba, az automatizált szkennerek pedig rövid időn belül elkezdik keresni azokat az oldalakat, amelyek még a régi verziót futtatják. A Patchstack mérései szerint a WordPress-ökoszisztémában az első kihasználásig eltelt idő súlyozott mediánja öt óra.

A WordPress nyílt forráskódú, ezért minden javítás nyilvános: bárki összehasonlíthatja a 7.1 és a 7.1.1 kódját, így azt is láthatja, mely sorok változtak. Ezt a biztonsági szakma patch diffingnek, vagyis a javítások összevetésének nevezi, a módszert pedig a jóhiszemű elemzők ugyanúgy használják, mint a támadók. A különbség annyi, hogy a támadóknak nem kell megvárniuk, amíg mindenki frissít, nekik éppen a lemaradók kellenek.

A Patchstack 2026. február 25-én megjelent, State of WordPress Security in 2026 című jelentése szerint 2025-ben összesen 11 334 új sérülékenységet találtak a WordPress-ökoszisztémában. Ennek 91%-a bővítményekben, 9%-a témákban volt, a WordPress core-ban pedig egész évben mindössze 6 hibát jelentettek. A jelentés szerint a nagy hatású sérülékenységek nagyjából felét 24 órán belül kihasználják, az első kihasználásig eltelt idő súlyozott mediánja pedig, ahogy fent is írtuk, öt óra.

Ebből két gyakorlati következtetés adódik. Az első, hogy a core ritkán jelenti a gyenge pontot, ezért kiugró esemény, amikor egyetlen javítókiadás tizenegy core-hibát zár be: ha a két számot egymás mellé tesszük, a 7.1.1 majdnem kétszer annyi core-sérülékenységet javít, mint amennyit 2025-ben egész évben jelentettek. A második, hogy a bővítmények frissítése legalább olyan fontos, mint a core-é, hiszen a 91%-os arány azt jelenti, hogy egy átlagos oldalon a kockázat oroszlánrésze a bővítményekben lapul.

A jelentés két további adata különösen tanulságos egy KKV számára. A sérülékenységek 46%-ára a nyilvánosságra hozatal pillanatában még nem létezett javítás, vagyis ilyenkor frissíteni sem lehet, csak lekapcsolni vagy lecserélni az érintett bővítményt. A prémium, azaz fizetős komponensekben talált sérülékenységek 76%-a volt ténylegesen kihasználható, ráadásul ezekben háromszor több ismerten kihasznált sérülékenységet (angol rövidítéssel KEV) találtak, mint az ingyenes társaikban, így a „fizetős, tehát biztonságos” logika sajnos nem működik.

A Patchstack azt is mérte, mennyit fognak meg a tárhelyszolgáltatók beépített védelmei: a vizsgált támadásoknak mindössze 26%-át blokkolták. Vannak persze gyorsan reagáló szolgáltatók, a Pantheon például a hivatalos kiadás előtt hálózati szintű ideiglenes védelmet, úgynevezett virtuális javítást (virtual patching) telepített a teljes platformjára, saját közleményében ugyanakkor maga is hangsúlyozza, hogy az ügyfeleknek ettől függetlenül telepíteniük kell a hivatalos frissítést. A tárhely védelme tehát jó biztonsági öv, a féket viszont nem helyettesíti.

Sokan abban bíznak, hogy ha elrejtik a WordPress verziószámát, a támadó nem tudja, mit futtatnak. A verzió azonban a nyilvános fájlokból, a betöltött szkriptek és stíluslapok verziójelöléseiből is jó eséllyel kikövetkeztethető, a tömeges szkennerek pedig sokszor nem is vesznek fáradságot, egyszerűen minden oldalon kipróbálják az ismert hibát. A verziószám elrejtése így legfeljebb kozmetika, az egyetlen valódi védelem maga a frissítés.

Hogyan ellenőrizd, hogy az oldalad magától frissült-e már?

Lépj be a WordPress adminfelületére, majd nyisd meg a Vezérlőpult menü Frissítések oldalát: ha itt a 7.1.1-es verziót látod, a javítás fent van. Ha régebbi szám szerepel, az automatikus háttérfrissítés valamiért nem futott le, ezért kézzel kell frissítened, az okát pedig érdemes kideríteni.

A verziószámot az adminfelület jobb alsó sarkában és a vezérlőpult áttekintő dobozában is megtalálod, a részletesebb diagnózishoz pedig az Eszközök menüben található Site Health (webhelyállapot) oldal ad támpontot, amely külön ellenőrzi, hogy a háttérfrissítések működnek-e. Érdemes a postafiókodban is rákeresni a frissítésről szóló értesítésre, mert a WordPress sikeres automatikus frissítés után e-mailt küld az oldal adminisztrátori címére. Ha ilyen levél nem érkezett, nézd meg, kinek a címe szerepel adminisztrátori e-mailként, mert tapasztalatunk szerint ez meglepően gyakran egy régen távozott kolléga vagy egy korábbi ügynökség címe.

Az automatikus frissítés elmaradásának tipikus okait az alábbi táblázat foglalja össze. Egy részük tudatos fejlesztői döntés, ami rendben van, ha van helyette működő frissítési folyamat. A probléma ott kezdődik, amikor a kikapcsolás megmaradt, a folyamat viszont nem.

Külön eset, ha a vezérlőpulton egy régebbi ág verzióját látod, például egy 6.9-es számot. Ilyenkor az automatikus frissítés az adott ágon belül maradt, vagyis a rád vonatkozó javításokat jó eséllyel visszaportolt formában megkaptad, a 7.1.1-re viszont a rendszer nem lépett át. A WordPress core csapata 2026. január 9-én jelentette be, hogy a WordPress 7.0 megjelenésével megszűnik a PHP 7.2 és 7.3 támogatása, az új minimum a PHP 7.4.0, az ajánlott verzió pedig továbbra is a PHP 8.3. A közlemény szerint a PHP 7.2-t vagy 7.3-at futtató szervereken az oldalak a 6.9-es ágon maradnak, így náluk a valódi megoldás a PHP-frissítés, csak utána jöhet a WordPress főverzió-váltása.

Hogyan frissíts biztonsági mentéssel öt perc alatt?

Ha a biztonsági mentésed automatizált, a WordPress 7.1.1 frissítés valóban nagyjából öt perc: friss mentés, a frissítés elindítása a Vezérlőpult Frissítések oldalán, a gyorsítótár ürítése, végül egy rövid ellenőrzés a legfontosabb oldalakon. Mentés nélkül viszont soha ne frissíts, mert egy váratlan hibánál csak a mentés hozza vissza gyorsan az oldalt.

Az alábbi lépések egy átlagos, néhány tucat bővítménnyel működő céges oldalra vonatkoznak. Az öt perc a core frissítésére és az alapellenőrzésre értendő. Ha a bővítményeket is frissíted (és érdemes), inkább 15 és 30 perc közötti idővel számolj.

• Nézd meg a kiinduló állapotot. A Vezérlőpult Frissítések oldalán jegyezd fel a jelenlegi WordPress-verziót és a frissítésre váró bővítmények listáját, a PHP-verziót pedig a Site Health oldal információs fülén találod. Ha később valami elromlik, ebből tudod majd, mi változott.
• Készíts teljes biztonsági mentést. A mentés a fájlokat (témák, bővítmények, feltöltött képek) és az adatbázist is tartalmazza, készülhet a tárhely pillanatkép-funkciójával vagy egy mentőbővítménnyel. Ellenőrizd, hogy a mentés ténylegesen letölthető, egy példánya pedig ne ugyanazon a szerveren legyen, ahol az oldal fut.
• Válassz jó időpontot. Webshopnál kerüld a rendelési csúcsidőt, kampányoldalnál a hirdetések legaktívabb óráit, egy bemutatkozó oldalnál viszont nyugodtan frissíthetsz bármikor, akár most azonnal.
• Indítsd el a core frissítését. A Vezérlőpult Frissítések oldalán kattints a frissítés gombjára (angol felületen Update Now), fejlesztői környezetben ugyanez a wp core update WP-CLI paranccsal is elvégezhető. A frissítés alatt az oldal néhány másodpercig karbantartási üzenetet mutathat, ami teljesen normális.
• Frissítsd a bővítményeket és a témát is. Egyenként haladj, ne tömegesen, így ha valamelyik hibát okoz, azonnal tudod, melyik volt a ludas. A Patchstack adatai szerint a sérülékenységek 91%-a bővítményekben található, ezért ez a lépés legalább olyan fontos, mint az előző.
• Ürítsd a gyorsítótárat. Ha gyorsítótár-bővítményt vagy CDN-t (tartalomkézbesítő hálózatot) használsz, ürítsd mindkettőt, különben a látogatók a régi, gyorsítótárazott változatot láthatják, a saját ellenőrzésed pedig félrevezető lehet.
• Végezz ötperces füsttesztet. A füstteszt (smoke test) gyors alapellenőrzés: nyisd meg a főoldalt, egy szolgáltatásoldalt és egy blogbejegyzést, küldj be egy próbaüzenetet a kapcsolatfelvételi űrlapon, webshopban pedig tegyél egy terméket a kosárba és menj el a fizetési oldalig. Nyisd meg a blokkszerkesztőt egy bejegyzésen, végül nézd meg, jelez-e hibát a Site Health oldal.
• Nézd át a friss hozzászólásokat. A jóváhagyásra váró és a frissítés előtti napokban érkezett kommentek között keress furcsa kódrészleteket, értelmetlen karaktersorokat vagy gyanús hivatkozásokat, a kétes tételeket pedig töröld.
• Dokumentálj. Egy egyszerű táblázatba írd fel a dátumot, az új verziószámot, a frissített bővítményeket és azt, hogy ki végezte a munkát, a sikeres mentést pedig tartsd meg legalább a következő frissítésig.

Mi a teendő, ha valami elromlik a frissítés után?

Javítókiadásnál ez ritka, mert a 7.1.1 nem hoz új funkciót, egy régi bővítmény vagy egy egyedi téma azonban néha mégis megbotlik a szigorúbb ellenőrzéseken. Ha súlyos PHP-hiba lép fel, a WordPress 5.2 óta elérhető helyreállítási mód (recovery mode) e-mailben egy különleges belépési hivatkozást küld az adminisztrátori címre, amellyel a hibás bővítmény kikapcsolható. Ha az adminfelület el sem érhető, a hibás bővítmény mappáját a tárhely fájlkezelőjében vagy FTP-n átnevezve lehet leállítani, végső esetben pedig a friss mentésből néhány perc alatt visszaállítható a korábbi állapot.

Ha visszaállítasz egy 7.1-es mentést, az oldal ismét sérülékeny lesz. A visszaállítás ezért csak időt vásárol a hibás bővítmény javítására vagy cseréjére, végleges megoldásnak semmiképp ne tekintsd.

Mit tegyél, ha egyedi téma vagy régi bővítmény fut az oldalon?

Ne hagyd ki a frissítést, hanem próbáld ki először egy tesztkörnyezetben (staging), amely az éles oldal pontos másolata. Egyedi témánál főleg a hozzászólások megjelenítését, az egyedi fejlécet és a REST API-t használó kódot érdemes ellenőrizni, régi bővítménynél pedig azt, hogy fejlesztik-e még egyáltalán.

A staging olyan elkülönített másolata az éles weboldalnak, amelyen a látogatók és a keresőrobotok elől elzárva lehet frissíteni és tesztelni. Sok tárhelyszolgáltató egy kattintással létrehozza, ha pedig a tiéd nem kínál ilyet, egy fejlesztő rövid idő alatt beállítja. A lényeg a sorrend és a tempó: előbb tesztkörnyezet, ellenőrzés, utána éles frissítés, mindez ugyanazon a napon, mert a hét végére halasztott teszt a gyakorlatban gyakran hetekig tartó sebezhetőséget jelent.

Egyedi téma: hol érintheti a 7.1.1 a kódodat?

Egy javítókiadás a nyilvános függvények működését ritkán változtatja meg, a biztonsági javítások viszont időnként szigorúbb ellenőrzést vezetnek be ott, ahol egy egyedi kód korábban lazább viselkedésre épített. A 7.1.1 hibalistája alapján az alábbi területeket érdemes a tesztkörnyezetben célzottan végignézni:

• a hozzászólások egyedi megjelenítése, különösen ha a téma saját szűrőkkel módosítja a wpautop() működését vagy saját kommentsablont használ;
• az egyedi fejléc (custom header) támogatása, mert az egyik XSS-hiba éppen az ezt támogató témákat érintette;
• a blokktémák sablonjai és minden olyan egyedi kód, amely a REST API sablonvégpontjaira épít;
• az XML-RPC felületet használó integrációk, például régi mobilalkalmazások vagy távoli publikálóeszközök;
• az egyedi jogosultságkezelés, ha a téma vagy egy bővítmény saját szerepköröket vagy módosított képességeket (capabilities) használ.

Ha az oldalad egy szülőtémára épülő gyermektémát (child theme) használ, a szülőtémát is frissítsd, mert a gyermektéma csak a módosításokat tartalmazza, a szülőtéma sérülékenységeit nem javítja. Ha pedig a témát évekkel ezelőtt egy azóta elérhetetlen fejlesztő írta és senki sem tudja pontosan, mit csinál, az egyértelmű jel arra, hogy ideje egy kódátvilágításnak.

Régi, elhagyott bővítmények

Egy bővítmény akkor tekinthető elhagyottnak, ha a WordPress.org bővítménytárában évek óta nem frissült, nem tesztelték az aktuális WordPress-verzióval vagy a tárból eltávolították. Ezeknél a 7.1.1 telepítése önmagában nem old meg semmit, mert ha a bővítményben ismert hiba van, arra nem fog javítás érkezni. A Patchstack jelentése szerint a sérülékenységek 46%-ánál a nyilvánosságra hozatalkor sem volt még javítás, egy elhagyott bővítménynél pedig javításra már nem is lehet számítani. Hasonló a helyzet a nem hivatalos forrásból, feltört licenccel letöltött prémium bővítményekkel, amelyek nem kapnak frissítést, nem ritkán pedig már a letöltéskor kártékony kódot tartalmaznak.

A régi bővítmények sokszor a PHP-verzión keresztül tartják fogva az oldalt: ha egy bővítmény nem fut PHP 8-on, a tárhely PHP-verziója nem frissíthető, a régi PHP pedig megakadályozza a WordPress főverzió-váltását. A WooCommerce-t használó webshopoknál ez a kérdés hamarosan még élesebb lesz, mert a WooCommerce a 11.5-ös verziótól, 2027 januárjától már nem támogatja a PHP 7.4-et és a 8.0-t (erről külön cikkben írunk részletesen).

Mennyibe kerül, ha elmarad a frissítés?

A frissítés maga néhány perc munka, egy feltört oldal helyreállítása viszont napokig tarthat, közben pedig kieső forgalommal, takarítási díjjal, sérülő keresési láthatósággal, adatvédelmi incidensnél bejelentési kötelezettséggel is jár. Egy kis webshopnál a kár saját becslésünk szerint könnyen megközelítheti az egymillió forintot.

A számítás menete egy képzeletbeli debreceni webshopon keresztül a következő. Tegyük fel, hogy a bolt naponta átlagosan 25 rendelést teljesít 16 000 Ft-os átlagos kosárértékkel, ami napi 400 000 Ft forgalmat jelent. Ha egy fertőzés miatt az oldalt két napra le kell állítani, a kieső forgalom 800 000 Ft. Tegyük fel azt is, hogy a takarítás, a hátrahagyott hátsó ajtók felkutatása és a biztonságos újratelepítés 10 fejlesztői órát vesz igénybe, amely 12 000 Ft-os feltételezett óradíjjal további 120 000 Ft. A két tétel együtt 920 000 Ft, amely még nem tartalmazza a Google figyelmeztető oldala miatt elmaradó forgalmat és a vásárlói bizalom csorbulását, ahogy azt sem, hogy a Google Ads a feltört, kártevőt terjesztő oldalakra mutató hirdetéseket jellemzően letiltja.

Ehhez képest a megelőzés ára töredék. Ha a rendszeres karbantartás havi két-három fejlesztői órát jelent, ugyanazzal a feltételezett óradíjjal számolva ez havonta 24 000 és 36 000 Ft közötti összeg, vagyis egy teljes év karbantartása is kevesebbe kerül, mint a fenti kétnapos leállás. Egy bemutatkozó oldalnál a forgalomkiesés persze kisebb, egy B2B cégnél viszont egyetlen elveszett ajánlatkérés is többet érhet a frissítésre fordított negyedóránál.

Hogyan védd a WordPress-oldalt a következő biztonsági hiba előtt?

A legjobb védelem a rendszeresség: bekapcsolt automatikus javítókiadások, heti bővítményfrissítés, kevés és szűk jogosultságú felhasználói fiók, kétlépcsős azonosítás az adminisztrátoroknak, valamint friss, a szervertől elkülönítve tárolt biztonsági mentés. Ezek a lépések együtt jelentősen csökkentik annak esélyét, hogy a következő tömeges támadási hullám éppen a te oldaladat találja el.

A 7.1.1 hibalistájából és a Patchstack adataiból a következő gyakorlati lépések adódnak, amelyeket egy nem fejlesztő cégvezető is számon kérhet a honlapját kezelő szakembertől:

• Automatikus javítókiadások: hagyd bekapcsolva a core kisebb kiadásainak automatikus telepítését, a megbízható bővítményeknél pedig kapcsold be a bővítményenkénti automatikus frissítést, amely a WordPress 5.5 óta elérhető a bővítménylistában.
• Felhasználói fiókok: negyedévente nézd át a felhasználókat, töröld a volt munkatársak és a korábbi ügynökségek fiókjait, a szövegírók pedig Közreműködő vagy Szerző szerepkört kapjanak, adminisztrátorit soha.
• Kétlépcsős azonosítás: minden adminisztrátori és szerkesztői fiókra kapcsold be, bővítménnyel vagy a tárhely beépített megoldásával.
• Hozzászólások: ha nincs rájuk szükség, kapcsold ki őket, ha igen, a Beállítások menü hozzászólásokra vonatkozó oldalán állítsd be a kötelező moderálást és a régi bejegyzések kommentjeinek automatikus lezárását.
• XML-RPC: ha semmi nem használja (például a Jetpack vagy egy régi mobilalkalmazás), kapcsold ki, mert ez egy ritkán figyelt, mégis támadható felület.
• Fájlmódosítás tiltása: a DISALLOW_FILE_EDIT beállítás letiltja a témák és bővítmények kódjának szerkesztését az adminfelületről, a DISALLOW_FILE_MODS pedig a telepítést és a frissítést is, ezért ez utóbbit csak akkor kapcsold be, ha a frissítéseket egy másik, működő folyamat végzi.
• Külön böngészőprofil: az adminmunkát olyan böngészőprofilban végezd, amelyben nem olvasol e-mailt és nem kattintasz ismeretlen hivatkozásokra, ez a Click2Shell-típusú láncok ellen olcsó, de hatékony védelem.
• Sérülékenységi riasztások: iratkozz fel egy sérülékenységi adatbázis értesítéseire (például a Patchstack, a Wordfence vagy a WPScan adatbázisáéra), hogy ne a hírekből értesülj a saját bővítményeid hibáiról.
• Webalkalmazás-tűzfal: a tárhely vagy egy külső szolgáltató WAF-ja virtuális javítással áthidalhatja a frissítésig tartó időt, de a Patchstack 26%-os blokkolási adata alapján ne ez legyen az egyetlen védvonal.

A mentésekre a klasszikus 3-2-1 szabály a jó kiindulópont: legyen három példány, két különböző tárolón, amelyek közül egy fizikailag is máshol van, mint a szerver. Egy mentés pedig csak akkor ér valamit, ha a visszaállítását legalább évente egyszer ki is próbáltad, különben könnyen éppen a baj napján derül ki, hogy a mentőbővítmény hónapok óta hiányos fájlokat gyártott.

Mit hoz a WordPress 7.2 decemberben és miért ne várj rá?

A WordPress 7.2 végleges kiadása a tervek szerint 2026. december 8. és 10. között érkezik, az első bétaverzió október 20. és 22. között. Ez nagyjából tizenegy hét, ezért a 7.1.1 javításait semmiképp ne halaszd a következő főverzióig, hiszen addig az oldalad nyitva állna a most nyilvánosságra került hibák előtt.

A Gutenberg Times beszámolója szerint a 7.2-es kiadást Matt Mullenweg vezeti, a koordinációért David Baumwald felel, a technikai vezetők pedig George Mamadashvili és Peter Wilson. Hogy mit hoz a 7.2 az oldaltulajdonosoknak és a fejlesztőknek, arról külön cikkben írunk részletesen. Biztonsági szempontból itt annyi a lényeg, hogy a nagy kiadás előtt érdemes rendbe tenni a tesztkörnyezetet és a frissítési rendet, mert ami a 7.1.1-nél öt perc, az egy főverzió-váltásnál könnyen egy egész délután.

Ha a mostani frissítésnél kiderült, hogy nincs tesztkörnyezeted, nem tudod, kinek a címére mennek az adminisztrátori értesítések, vagy egy régi bővítmény miatt nem mersz hozzányúlni az oldalhoz, akkor a 7.2-ig hátralévő hetek pont elegendők ezek rendbetételére. Az AI-alapú hibakeresés terjedésével ráadásul valószínűleg a biztonsági kiadások is sűrűbben érkeznek majd, így a jól begyakorolt, dokumentált frissítési folyamat ma már alapfelszereltség.

Miben segít a Convergo?

A Convergo support, üzemeltetés és tárhely szolgáltatása pontosan az ilyen helyzetekre készült: a Support csomag havi 30 000 Ft-ért három fejlesztői órát tartalmaz, amelyből a WordPress-frissítések, a mentések ellenőrzése és a bővítmények karbantartása rendszeresen elvégezhető. Ha nem tudod, milyen állapotban van az oldalad, IT audit és digitális tanácsadás keretében átnézzük a verziókat, a felhasználói fiókokat, a bővítményeket és a frissítési folyamatot. Ha pedig az oldal annyira elavult, hogy a foltozgatás már nem éri meg, webdesign és weboldalkészítés szolgáltatásunkkal biztonságos, karbantartható alapra építjük újra. Az első lépés egy ingyenes egyeztetés, ahol közösen megnézzük, mi fut most az oldaladon.