WordPress frissítés nélkül: mi történik? Valós esetek

Ha nem végzed el a WordPress frissítést, az oldalad kiszolgáltatottá válik az automatizált támadásoknak. Egy szerveroldali PHP-váltás után leállhat (fehér képernyő), a lassulás miatt pedig romolhat a keresőbeli teljesítménye is. A javítás csak akkor véd, ha telepítve van. Ezért a frissítés biztonsági és üzleti kockázatkezelés, nem technikai apróság.

Az értesítés hetek óta ott van a vezérlőpulton, a bővítmények mellett egyre nagyobb a piros szám, te pedig azt gondolod: az oldal működik, minek bolygassam. Ez a logika hónapokig, néha évekig bejön. Aztán egy reggel a Google figyelmeztetést jelenít meg az oldalad mellett, a webshopod rendelései nem érkeznek meg, vagy a kezdőlapodon váratlanul egy ismeretlen nyelvű reklám jelenik meg.

Ebben a cikkben négy nyilvánosan dokumentált esetből mutatom meg, mi történik egy frissítetlen oldallal. Utána következik a gyakorlati rész: hogyan frissíts úgy, hogy közben nem te teszed tönkre az oldalt. Ha csak a lépések érdekelnek, ugorj a Hogyan frissíts biztonságosan részhez. A cikk végén ellenőrzőlistát, kockázati táblázatot és egy „első 24 óra" tervet is találsz arra az esetre, ha már most gyanús jeleket látsz.

Röviden: mi történik, ha elmarad a frissítés?

Ha nem frissíted a WordPress magját, a témát és a bővítményeket, négy terület romlik fokozatosan:

1. Biztonság. A nyilvánosságra hozott sérülékenységek ismertek, és a támadók automatizált eszközökkel keresik az érintett oldalakat.
2. Sebesség és stabilitás. Az elavult kód hozzájárulhat a lassuláshoz, és előbb-utóbb ütközhet a szerver újabb PHP-verziójával.
3. Kompatibilitás. Az egyik bővítmény frissül, a másik nem, és a kettő egyszer csak nem működik együtt.
4. Bizalom és láthatóság. Egy feltört vagy hibás oldal biztonsági figyelmeztetést kaphat a Google-ben, a látogatók pedig elbizonytalanodnak.

A kockázat nem egyenletes. Hónapokig nem történik semmi, aztán egyetlen nap alatt minden megtörténik. Ezért érdemes a valós esetekkel kezdeni.

A négy eset egy táblázatban

Mit jelent pontosan a WordPress frissítés?

A „WordPress frissítés" három külön dolgot takar, és mindhárom számít:

• WordPress mag. Maga a rendszer. A kisebb, karbantartási és biztonsági kiadások automatikus telepítése a legtöbb oldalon alapértelmezetten be van kapcsolva. A nagyobb verzióváltások kezelése telepítéstől és konfigurációtól függően eltérhet, ezért ne feltételezd, hogy nálad is automatikusan lefutnak.
• Bővítmények. Az űrlaptól a SEO-bővítményen át a webshopmotorig minden, ami nem a mag része. A bővítmények gyakran jelentik a támadási felületet.
• Téma és oldalépítő. A megjelenés és a szerkesztőfelület kódja, például az Elementor vagy a Breakdance.

Az elavult WordPress ezért ritkán jelent csak egy régi magverziót. Gyakoribb, hogy a mag naprakész, de két bővítmény egy éve nem kapott frissítést, és az egyik már nincs is fejlesztés alatt.

Valós esetek: amikor a halogatás komoly kárt okozott

Szándékosan nyilvános, jól dokumentált példákat választottam. Ezek nem elszigetelt balesetek, hanem visszatérő minták. Az adatok forrásait a cikk végén, a „Források" részben találod.

2017: a REST API sérülékenység és a becsült 1,5 millió átírt oldal

2017 elején a WordPress 4.7.0 és 4.7.1 verziójában olyan hiba derült ki, amely lehetővé tette, hogy bejelentkezés nélkül, kívülről módosítsák a bejegyzések tartalmát. A javítás a 4.7.2-es kiadásban érkezett. A részleteket a fejlesztők és a biztonsági cégek a nyilvánosságra hozatal előtt egy hétig titokban tartották, hogy az oldalak addig automatikusan frissülhessenek. A hibát bemutató Sucuri-közlemény és a sajtóbeszámolók szerint a nyilvánosságra hozatal után a támadók napokon belül becslések szerint mintegy 1,5 millió oldalt írtak át.

Az érintettek jelentős része nem frissült a javított verzióra. Vagy ki volt kapcsolva náluk az automatikus frissítés, vagy olyan környezetben futott az oldaluk, ahol az nem működött.

A tanulság: a javítás már létezett, mire a tömeges támadás elindult. A kár nem ott keletkezett, hogy nem volt orvosság, hanem ott, hogy a javítás nem került fel.

2020: a File Manager bővítmény

2020 szeptemberében kritikus hibát találtak a File Manager bővítményben. A 6.0–6.8 verziókat érintő sérülékenység (CVE-2020-25213) lehetővé tette a jogosulatlan fájlfeltöltést és kódfuttatást. A hibát a Wordfence elemzése szerint kb. 700 ezer oldalon használt bővítményben aktívan kihasználták, a javítás a 6.9-es kiadásban jelent meg. A támadások a javítás megjelenése körül már zajlottak, vagyis aki nem frissített időben, kitett maradt.

A példa azért tanulságos, mert a bővítmény ártalmatlannak tűnt. Egyszerű fájlkezelő volt, amelyet a legtöbben kényelmi okból telepítettek, és senki nem gondolt rá biztonsági kockázatként.

A tanulság: minden telepített bővítmény támadási felület, akkor is, ha jelentéktelennek tűnik.

2020: a Duplicator és az egymillió érintett oldal

A Duplicator mentési és költöztetési bővítménynek egymillió feletti aktív telepítése volt, amikor kiderült egy sérülékenység (CVE-2020-11738). A hiba lehetővé tette, hogy a támadók tetszőleges fájlt töltsenek le az oldalról. Ez magában foglalta a wp-config.php fájlt is, amely az adatbázis hozzáférési adatait tartalmazza. A javítás az 1.3.28-as verzióban érkezett.

A mentőeszköz maga lett a rés a falban. Aki frissítette, védett maradt. Aki nem, annál az adatbázis-hozzáférés kerülhetett illetéktelen kezekbe.

A tanulság: a „biztonsági" és a „mentő" bővítmények sem mentesek a hibáktól, ezért ezeket is karban kell tartani.

2023: az Elementor Pro és a WooCommerce

2023 tavaszán súlyos hibát találtak az Elementor Pro-ban (CVE-2023-3124). A hiba azoknál az oldalaknál volt veszélyes, ahol az Elementor Pro és a WooCommerce együtt futott. Egy bejelentkezett, alacsony jogosultságú felhasználó, például egy vásárló vagy előfizető módosíthatta a webhely beállításait, és akár adminisztrátori fiókot is létrehozhatott. A hibát aktívan kihasználták, a javítás az Elementor Pro 3.11.7-es kiadásában jelent meg.

Webshopnál ez különösen kellemetlen, mert ott a regisztráció természetes: bárki létrehozhat vásárlói fiókot. A támadónak így nem kellett feltörnie semmit, elég volt regisztrálnia.

Sokan úgy gondolják, hogy a fizetős bővítmény egyben biztonságosabb is. A hibák azonban a prémium termékekben is előfordulnak. A különbség az, hogy a fejlesztő gyorsan reagál-e, és te is gyorsan reagálsz-e.

A tanulság: a prémium licenc nem helyettesíti a frissítést. A javítás csak akkor véd, ha telepíted.

Hogyan néz ki egy elavult WordPress a mindennapokban?

A fenti példák látványosak. A mindennapi kár általában csendesebb.

Biztonsági következmények

Az elavult WordPress első és legnyilvánvalóbb kockázata a feltörés. Egy feltört oldal nem mindig néz ki feltörtnek. Gyakori forgatókönyvek:

• Rejtett spam-oldalak. A támadók több száz idegen nyelvű, gyógyszer- vagy kaszinóreklámot tartalmazó aloldalt hoznak létre a domained alatt. Te nem látod őket, a Google viszont indexelheti.
• Átirányítás. A látogatók egy része, jellemzően a mobilról érkezők, idegen oldalra kerül.
• Hátsó ajtó. A támadó elrejt egy fájlt, amelyen keresztül később bármikor visszatérhet, még akkor is, ha az eredeti hibát közben javítottad.
• Levélküldés. A szerveredről spamet küldenek, és a domained feketelistára kerülhet.

A hátsó ajtó azért alattomos, mert a tisztítás után sokan úgy érzik, hogy megoldódott a probléma, aztán két hét múlva ugyanaz történik. A feltört WordPress javítása ezért nem merül ki abban, hogy kitöröljük a látható kárt. Meg kell találni a belépési pontot is.

Teljesítmény és Core Web Vitals

A frissítések nemcsak biztonsági javításokat hoznak. A WordPress magja, a témák és a bővítmények folyamatosan változnak, a fejlesztők a kódot optimalizálják az újabb PHP-verziókra. Aki éveken át nem frissít, annak ezek a fejlesztések kimaradnak.

Az elavult kód hozzájárulhat a lassuláshoz, ami ronthatja a Core Web Vitals értékeket. Ez önmagában nem garantált pozícióvesztés, mert a lassulásnak sok más oka is lehet: nagy képek, gyenge tárhely, külső szkriptek, nehéz téma, hiányzó gyorsítótár. A rossz felhasználói élmény és a technikai problémák viszont hosszabb távon ronthatják az oldal teljesítményét. Ha a sebesség a gondod, a WordPress sebességoptimalizálás a következő lépés, a frissítés azonban az alap.

PHP-kompatibilitás: a tárhely előbb lép, mint te

Ez az a pont, amelyet a legtöbben elfelejtenek. A tárhelyszolgáltatók időről időre kivezetik a régi PHP-verziókat, mert azok már nem kapnak biztonsági javítást. A PHP 7.4 támogatása például 2022 végén megszűnt, és a 8.0, majd a 8.1 is követte. Mielőtt bármit beállítasz, nézd meg a php.net támogatott verzióit, mert ez a lista évente változik.

Amikor a tárhely átáll egy újabb verzióra, a régi bővítmények és témák egy része egyszerűen nem fut tovább. A következmény gyakran a WordPress fehér halál (WSOD): üres fehér oldal vagy kritikus hibaüzenet. A PHP verzió frissítés a tárhely vezérlőpultján (például cPanelben vagy a szolgáltatód saját felületén) pár kattintás, de csak akkor biztonságos, ha az oldal kódja követte a környezetet.

A legrosszabb forgatókönyv az, ha a régi PHP-verziót már nem lehet visszakapcsolni, és az elavult bővítmény nem frissíthető. Ekkor vészhelyzetben, sietve kell lecserélni vagy újraépíteni az érintett részt.

Bővítmények közötti ütközés

Egy oldal sok bővítményből áll, és ezek egymásra épülnek. Ha az egyik frissül, a másik nem, előbb-utóbb eltérnek a feltételezéseik. Ilyenkor az űrlap nem küld, a kosár nem frissül, a szerkesztő nem tölt be, vagy a menü eltűnik.

Minél tovább halogatod a frissítést, annál nagyobb az ugrás a jelenlegi és a legújabb verzió között, és annál nagyobb az esély, hogy valami eltörik. Ez a paradoxon: a félelem a frissítéstől pont azt eredményezi, hogy a frissítés egyre kockázatosabb lesz.

SEO-következmények

A feltört vagy hibás oldal közvetve a keresési láthatóságot is érintheti:

• A Google biztonsági figyelmeztetést jeleníthet meg, korlátozhatja a fertőzött oldalak megjelenítését, és a Search Console-ban jelzi a problémát. A helyreállítás után felülvizsgálatot kell kérni.
• A rejtett spam-oldalak rontják az oldal megítélését és a találati képet.
• A lassú vagy hibás oldalt kevesebben látogatják végig, nő a visszafordulási arány.
• Ha az oldal hosszabb ideig vagy ismételten hibás, a Google feltérképezése nehezebbé válhat, és a tartalmak frissítése lassulhat a keresőben. Rövid kiesésnél a Google általában újra próbálkozik.

A helyreállítás után a pozíciók nem biztos, hogy azonnal visszatérnek. Egy komolyabb spamfertőzés után a rendeződés heteket vagy hónapokat vehet igénybe. Ha a kár már a láthatóságot is érinti, a SEO szolgáltatás részeként az állapot újrafelmérése is szóba kerül.

Webshop: itt a legdrágább a hiba

Webshopnál a frissítés elmulasztása a bevételt és a vásárlói adatokat is érinti. A WooCommerce fizetési átjárói, szállítási modulok és számlázóintegrációk rendszeresen frissülnek, mert a szolgáltatók API-ja is változik.

Ha egy integráció elavul, a fizetés nem megy át, vagy a számla nem generálódik. Ezeket a hibákat sokszor a vásárló veszi észre elsőként, nem te. Ha emellett vásárlói adatok is érintettek, az adatvédelmi, például GDPR-hez kapcsolódó felelősséged is felmerül. Ha most építenél webshopot, vagy újraépítenél egy régit, a WooCommerce webshop készítés során már az elején érdemes a karbantarthatóságot is megtervezni.

Hogyan frissíts biztonságosan? Lépésről lépésre

A frissítés kockázata kontrollálható. Az alábbi sorrendet követem a gyakorlatban.

1. Készíts friss mentést

Mentsd az adatbázist és a fájlokat is. Ellenőrizd, hogy a mentés tényleg visszaállítható-e. Egy meg nem próbált mentés csak remény, nem biztonság. A WordPress biztonsági mentés bővítmény választásánál a lényeg, hogy a mentés külső helyre, például felhőtárhelyre kerüljön, ne csak ugyanarra a szerverre. Elterjedt megoldás például az UpdraftPlus, de a tárhelyszolgáltatód saját mentése is megfelelő, ha tudsz belőle visszaállítani. Ha van napi automatikus mentés, a frissítés előtt akkor is csinálj egy kézi pillanatfelvételt.

2. Használj tesztkörnyezetet (staging)

A legbiztonságosabb módszer, ha a frissítést először az oldal másolatán végzed el. Ha a tárhelyed kínál staging funkciót, használd. Webshopnál ez különösen fontos, mert ott a hiba pénzbe kerül. A tesztkörnyezetben kiderül, ha egy bővítmény eltörik, és az éles oldal közben érintetlen marad.

3. Tartsd be a sorrendet

Én általában ezt a sorrendet követem:

1. A bővítmények frissítése, egyenként vagy kisebb csoportokban, nem mindet egyszerre.
2. A téma frissítése (gyermektéma esetén ügyelj az egyedi módosításokra).
3. A WordPress mag frissítése.
4. Végül a PHP-verzió váltása, ha szükséges, külön lépésben.

Az „egyszerre mindent" megközelítés hibakeresésnél nehéz helyzetbe hoz, mert nem tudod, melyik elem okozta a problémát.

4. Olvasd el a változásnaplót

Nagyobb verzióugrás előtt érdemes átfutni a bővítmény changelogját. Ha olyan kifejezés szerepel benne, mint „breaking change" vagy „megszűnt támogatás", ott különös óvatosság kell.

5. Ellenőrizd a kritikus funkciókat

Frissítés után ne csak a kezdőlapot nézd meg. Végigmegyek a következőkön:

• az űrlapok elküldése és az értesítő e-mail megérkezése,
• a menü és a mobilnézet,
• webshopnál a teljes vásárlási folyamat, a fizetéssel együtt,
• a SEO-beállítások: a title, a meta leírás és az átirányítások a helyükön vannak-e,
• a hibanapló, ha van hozzáférésed.

6. Tudd, hogyan léphetsz vissza

Ha valami eltörik, két lehetőséged van: a bővítmény előző verziójának visszaállítása, vagy a mentés visszatöltése. A lényeg, hogy ezt még a frissítés előtt eldöntsd, ne akkor, amikor már tűzoltás zajlik.

Automatikus frissítés: mikor érdemes, mikor nem?

A WordPress a legtöbb oldalon alapértelmezetten automatikusan telepíti a kisebb, karbantartási és biztonsági frissítéseket. A bővítmények és témák automatikus frissítését külön be kell kapcsolni. A nagyobb verzióváltások beállítása telepítéstől és konfigurációtól függően eltérhet, ezért ellenőrizd a saját oldaladon. A részleteket a WordPress hivatalos dokumentációja tartalmazza.

Az automatikus frissítés mellett szól, ha:

• az oldal egyszerű bemutatkozó oldal, kevés bővítménnyel,
• nincs egyedi fejlesztés,
• naponta készül mentés,
• a frissítés után valaki rendszeresen ellenőrzi az oldalt.

Óvatosabb megközelítést érdemel, ha:

• webshopról vagy foglalási rendszerről van szó,
• sok egymásra épülő bővítmény fut,
• egyedi kód van az oldalban,
• az oldal bevételt termel.

Az automatikus frissítés tehát nem „vagy-vagy" kérdés. Sok oldalon az a legjobb megoldás, ha a biztonsági javítások automatikusan települnek, a nagyobb verzióváltásokat pedig kontrolláltan végzik el.

Mennyi időnként frissíts? Kockázati mátrix oldaltípusonként

Ha egy bővítményről nyilvános biztonsági javítás jelenik meg, ne várd meg a következő ütemezett ellenőrzést. A WordPress frissítés fontossága pont itt látszik: a támadók a közzététel után gyorsan reagálnak, neked is gyorsnak kell lenned.

Döntési szempontok: magad csinálod, vagy szakemberre bízod?

Nem mindenkinek kell szakember a frissítéshez. Az alábbi szempontok segítenek eldönteni.

Megoldhatod magad, ha:

• egyszerű, kevés bővítményes oldalról van szó,
• van működő mentésed és staging környezeted,
• nem fizetnek be az oldalon keresztül, és nincs vásárlói adatbázis,
• hajlandó vagy időt szánni az ellenőrzésre.

Érdemes szakemberre bízni, ha:

• webshopod van, és a leállás közvetlen bevételkiesés,
• az oldalt valaki más építette, és nem tudod, mi van benne,
• korábban már eltört tőle az oldal,
• több éve nem frissült, és nagy a verziókülönbség,
• az oldal már mutat gyanús jeleket (lassulás, ismeretlen felhasználók, furcsa átirányítások).

Ha a második listából legalább kettő igaz rád, a külső segítség általában olcsóbb, mint a saját kísérletezés. Ez különösen igaz akkor, ha az oldal jelenleg is elavult állapotban van, mert ott a frissítés nem rutinfeladat, hanem kockázatos művelet.

Ellenőrzőlista: elavult-e az oldalad?

Az alábbi jelek közül bármelyik arra utal, hogy ideje foglalkozni a témával:

• A vezérlőpulton több mint egy-két frissítés vár.
• A bővítmények között olyan van, amelyet több éve nem fejlesztettek.
• Nem tudod, melyik PHP-verzión fut az oldalad.
• Az oldalt nem te építetted, és nincs róla dokumentáció.
• Az adminban ismeretlen felhasználókat találsz.
• Az oldal lassabb, mint egy éve.
• A Google Search Console biztonsági vagy indexelési figyelmeztetést jelez.
• Nem tudod, mikor készült az utolsó működő mentés.

Ha a lista legalább két pontjára igent mondasz, érdemes egy átfogó ellenőrzéssel kezdeni. A legfontosabb: ne a következő riasztásra várj.

Az első 24 óra: mit tegyél, ha már gyanús jeleket látsz?

Ha az oldalad szokatlanul viselkedik, a sorrend számít:

1. Ne frissíts mindent azonnal, vakon. Egy feltört oldalon a frissítés nem tünteti el a hátsó ajtót.
2. Készíts aktuális mentést az éppen fennálló állapotról, még ha a tartalom gyanús is. Szükség lehet rá a vizsgálathoz.
3. Változtasd meg az összes jelszót: admin, FTP, adatbázis, tárhely.
4. Ellenőrizd az ismeretlen adminfelhasználókat, és töröld azokat, amelyeket nem te hoztál létre.
5. Nézd meg a Google Search Console biztonsági jelentését, és keress rá az oldalad nevére a Google-ben idegen tartalmak után.
6. Kérj szakembert, ha hátsó ajtóra vagy adatszivárgásra gyanakszol.
7. Csak a tisztítás és az ellenőrzés után frissíts kontrolláltan, a fenti lépések szerint.

A Google hivatalos útmutatója, a Google Search Console Biztonsági problémák jelentése lépésről lépésre végigvezet a tisztítás és a felülvizsgálat kérése folyamatán.

Mit érdemes még tenni a frissítés mellett?

A frissítés fontos, de nem az egyetlen védelmi réteg. Mellette érdemes beállítani:

• Erős jelszavak és kétlépcsős belépés minden adminfelhasználónak.
• Fölösleges bővítmények és témák törlése. A kikapcsolt bővítmény is kockázat, ha a kódja ott van a szerveren.
• Rendszeres, külső helyre mentett biztonsági mentés.
• Megbízható forrásból származó bővítmények. A „feltört" prémium bővítmények ingyenes másolatai gyakran kártékony kódot hordoznak.
• Biztonsági napló és figyelés, hogy a gyanús tevékenységről értesülj. Erre léteznek biztonsági bővítmények (például a Wordfence), de önmagukban nem pótolják a frissítést.

A további beállításokról a WordPress biztonsági beállítások cikkemben írok részletesebben. A platform biztonsági szemléletét a WordPress.org biztonsági oldala foglalja össze.

Mit látok a gyakorlatban?

A legtöbb problémás oldalon nem egyetlen hatalmas hiba okozza a gondot, hanem több hónapos halogatás. Elavult PHP, nem frissített bővítmények, régi mentés és ismeretlen egyedi kód van jelen egyszerre. Ilyenkor a frissítés nem tízperces feladat, hanem állapotfelmérés és kontrollált helyreállítás. Ezért tartom jobbnak, ha a frissítés rutin, nem mentőakció.

Mennyibe kerül a nem frissítés?

Általános összeget nem mondok, mert minden oldal más. Inkább a költségek típusait sorolom fel:

• Helyreállítás. A feltört oldal megtisztítása, a hátsó ajtók felkutatása, a jelszavak és kulcsok cseréje.
• Kiesett bevétel. Minden óra, amikor a webshop nem működik, vagy a látogató nem bízik meg az oldalban.
• SEO-kár. Az elvesztett pozíciók visszaszerzése hosszabb folyamat, mint maga a tisztítás.
• Hírnév. Ha az ügyfeleid spam-átirányítást vagy figyelmeztetést látnak, a bizalom nehezen áll helyre.
• Újraépítés. Ha a régi technológiát már nem lehet fenntartani, a költség többszöröse a rendszeres karbantartásénak.

A WordPress karbantartás ára ehhez képest előre tervezhető, havi vagy negyedéves tétel. Egyetlen komolyabb incidens ára általában jóval magasabb, és nem te választod meg, mikor érkezik. A WordPress frissítés fontossága ezért elsősorban kockázatkezelési kérdés, nem technikai részlet.

Miért nem frissítenek az emberek? Négy gyakori ok

Értem az ellenállást, mert a legtöbb mögött valós tapasztalat áll.

„Egyszer már tönkrement tőle az oldal." Ez a leggyakoribb ok, és jogos. De az oldalt általában nem a frissítés tette tönkre, hanem az, hogy mentés és tesztelés nélkül, túl nagy lépésben történt. A megoldás a biztonságos folyamat, nem a halogatás.

„Egyedi fejlesztés van benne." Ha az oldalon testreszabott kód fut, a frissítés valóban kockázatosabb. De épp ezért kell rendszeresen, kis lépésekben csinálni, és szükség esetén a testreszabást a frissítésekhez igazítani.

„Nincs időm rá." A rendszeres frissítés összességében kevesebb időt visz el, mint a hirtelen helyreállítás. Egy tíz perces havi karbantartás kiváltja a több napos mentőakciót.

„Az oldal jól működik, minek nyúljak hozzá?" Ez a gondolkodás hasonlít a gépjármű műszaki vizsgájának kihagyásához. Működik, amíg nem működik. A sérülékenységek nem látszanak kívülről.

Gyakran ismételt kérdések

Zárszó: a frissítés nem költség, hanem biztosítás

A fenti esetekben egy közös dolog van: a javítás mindig létezett, mielőtt a kár bekövetkezett. A különbséget az jelentette, hogy az oldal tulajdonosa mikor telepítette.

Ha most azt érzed, hogy az oldalad frissítése régóta késik, ne a teljes átépítésben gondolkodj, hanem az első lépésben: mentés, állapotfelmérés, majd kontrollált frissítés. Ha ebben szeretnél segítséget, a WordPress karbantartás szolgáltatásomon keresztül megnézem az oldalad állapotát, és megmondom, mire van szükség. Ha pedig új oldalt vagy webshopot terveznél, a weboldalkészítés és a webshopkészítés során már az elején úgy építem fel a rendszert, hogy a későbbi frissítések ne okozzanak meglepetést. A WordPress karbantartásáról, biztonságáról és sebességéről további gyakorlati cikkeket találsz a blogomon.

Források és további olvasnivalók

• Sucuri: Content Injection Vulnerability in WordPress REST API
• Wordfence: File Manager zero-day vulnerability
• NIST NVD: CVE-2020-25213 (File Manager)
• NIST NVD: CVE-2020-11738 (Duplicator)
• NIST NVD: CVE-2023-3124 (Elementor Pro)
• WordPress.org: Automatikus háttérfrissítések beállítása
• WordPress.org: Biztonság
• Google Search Console Súgó: Biztonsági problémák jelentés
• PHP: Támogatott verziók