A WordPress 7.0.2 biztonsági frissítés 2026. július 17-én jelent meg, és két súlyos hibát zár le. Ha az oldalad a 6.8–7.0.1 sávban van, érintett vagy: a javítás a 7.0.2, a 6.9.5 és a 6.8.6 verzióban érkezett. Az első támadási kísérletek 90 perccel a kiadás után befutottak — ezért nem halasztható.
Tartalomjegyzék
- Mi történt július 17-én, és miért érint téged is?
- Miért nem elég a „majd jövő hónapban”?
- Milyen WordPress-verziót futtatok, és hol nézem meg?
- Melyik verzió javítja a hibát? Verzió-mátrix
- Hogyan kapcsolom be a biztonsági automatikus frissítéseket?
- Mit ellenőrizzek, ha napokig nem frissítettem?
- Mit tud a virtuális javítás, amíg te frissítesz?
- Mennyire vagy egyedül ezzel a problémával?
- Gyakori kérdések
Mi történt július 17-én, és miért érint téged is?
A WordPress fejlesztői aznap rendkívüli biztonsági kiadást tettek közzé. A hivatalos bejelentés szerint a 7.0.2 „egy kritikus és egy magas súlyosságú” hibát javít, és a WordPress.org csapata a súlyosság miatt kényszerített automatikus frissítést indított az érintett verziókon futó oldalakra (WordPress.org).
Ez a mondat két dolgot jelent. Az egyik jó hír: sok magyar oldal aznap éjjel magától megkapta a javítást, és a tulajdonos csak egy e-mailt látott róla reggel. A másik kevésbé jó: a kényszerített frissítés csak ott fut le, ahol az automatikus frissítés egyáltalán működik. Ahol valaki évekkel ezelőtt kikapcsolta „nehogy elrontson valamit”, ott semmi nem történt.
Mit tud a két hiba, laikusan? Az egyik esetben egy nyilvános kérésen keresztül olyan adatbázis-lekérdezés indítható, amilyet nem lenne szabad. A másik esetben a WordPress beépített programozói felületén a bejövő kérések nem oda kerülnek, ahova kellene. Külön-külön egyik sem adja oda az oldalt, összekapcsolva viszont a támadó adminisztrátori hozzáférésig és kódfuttatásig juthat egy védtelen oldalon (Patchstack). Technikai részleteket szándékosan nem írunk le — nem is kellenek ahhoz, hogy megvédd magad.
Az érdekes az, hogy honnan jött a hiba. A 7.0.2-ben javított láncot a Searchlight Cyber kutatói találták meg úgy, hogy egy nyelvi modellt engedtek rá a WordPress forráskódjára: a működő támadási lánc tíz óra alatt, nagyjából 25 dollárból állt össze (Patchstack). Ugyanez az irány látszik a WordPress hibabejelentő programjának forgalmán is: kilenc éven át havi néhány tucat bejelentés érkezett, 2026 júliusában viszont 450 (Patchstack). Több szem, gyorsabban — ez hosszú távon jó a WordPressnek. Rövid távon viszont azt jelenti, hogy a „majd a következő karbantartáskor” egy olyan világ szokása, ami már nincs meg.
Miért nem elég a „majd jövő hónapban”?
Mert a támadók nem hónapokban gondolkodnak. A Patchstack telemetriája szerint a javítás a WordPress fejlesztői ágába nagyjából másfél órával a 7.0.2 kiadása előtt került be — és ez a commit maga a nyilvánosságra hozatal, hiszen bárki megnézheti, mi változott.
Az első valódi támadási kísérletek nagyjából 90 perccel a 7.0.2 megjelenése után, három órával a javítás közzététele után érkeztek be. Ennyi ideje volt a védekezőknek. (Forrás: Patchstack)
Ami utána következett, az nem egyetlen szervezett botnet volt, hanem egyszerre érkező, egymástól független próbálkozók tömege.
A kiadást követő napokban a Patchstack több mint 65 000 támadási kísérletet blokkolt e két hiba ellen, több mint 1500 különböző IP-címről — és minden egyes kísérlet olyan oldal ellen ment, ami tényleg sérülékeny verzión futott. (Forrás: Patchstack)
Ez nem egyedi eset, hanem az általános ritmus. A Patchstack 2026-os iparági jelentése szerint a legtámadottabb sérülékenységeknél a nyilvánosságra hozataltól a tömeges kihasználásig eltelt idő súlyozott mediánja öt óra, a nagy hatású hibák nagyjából felét 24 órán belül, 70%-át egy héten belül támadják (Swif összefoglaló a Patchstack-adatokból). Eközben a Verizon 2026-os adatvédelmi incidensjelentése azt méri, hogy a szervezetek javítási mediánja 32 napról 43 napra nőtt.
Öt óra a támadók mediánja, 43 nap a védekezőké. Ebben a résben él a legtöbb feltört WordPress-oldal. (Forrás: Swif / Patchstack és Verizon DBIR 2026)
És van még egy adat, ami sokakat meglep: a kihasznált sérülékenység a Verizon jelentésének 19 éves történetében először lett a betörések első számú belépési pontja, a támadások 31%-ával — megelőzve a lopott jelszavakat (Swif). Erről a fordulatról részletesen írtunk a 2026-os WordPress támadási trendekről szóló cikkünkben: ma már nem a jelszavadat találgatják, hanem a publikált hibákat próbálják.
Milyen WordPress-verziót futtatok, és hol nézem meg?
Két perc, és tudni fogod. Nem kell hozzá se fejlesztő, se FTP.
• 1. Lépj be az adminba a saját oldaladon (`azoldalad.hu/wp-admin`). • 2. Vezérlőpult → Kezdőlap. Jobb oldalt vagy alul találsz egy „Egy pillantásra” nevű dobozt. Az alján ez a mondat áll: „WordPress 7.x.x verzió … témával”. Ez a te verziószámod. • 3. Ha nem látod: menj a Vezérlőpult → Frissítések menüpontba. A lap tetején kiírja, hogy melyik verziót futtatod, és hogy van-e elérhető újabb. • 4. Biztosra mennél? Eszközök → Oldal állapota → Információ fül, és nyisd le a WordPress szekciót. Itt a verzió mellett azt is látod, hogy be van-e kapcsolva a hibakeresés, és milyen PHP fut alattad. • 5. Ha be sem tudsz lépni: a tárhelyszolgáltatód vezérlőpultja (cPanel WP Toolkit, Plesk WordPress menü) is kiírja a telepített verziót.
Amit ne csinálj: ne az oldal forráskódjából próbáld kitalálni. Az ott szereplő adat sok telepítésen szándékosan el van rejtve vagy hamis, és semmit nem árul el arról, hogy a bővítményeid frissek-e.
Egyik szolgáltató ügyfelünknél pontosan ez okozott hetekig tartó félreértést: az admin felület szerint minden rendben volt, „nincs elérhető frissítés” — miközben a wp-config.php fájlban évekkel korábban egy fejlesztő teljesen letiltotta a frissítéskeresést. Az oldal nem azért nem frissült, mert nem volt mit frissíteni, hanem mert meg sem kérdezte.
Melyik verzió javítja a hibát? Verzió-mátrix
A WordPress a javítást három párhuzamos ágra adta ki. Keresd meg a saját verziószámodat a bal oszlopban.
| A te verziód | Érinti ez a két hiba? | Javított verzió az ágon | Mit tegyél most |
|---|---|---|---|
| 7.0.0 – 7.0.1 | Igen, mindkettő | 7.0.2 | Frissíts azonnal, lehetőleg egyből a legfrissebb kiadásra. Utána fusd le az alábbi ellenőrzőlistát. |
| 6.9.0 – 6.9.4 | Igen, mindkettő | 6.9.5 | Frissíts azonnal. Ha a 7-es ágra még nem mersz lépni, legalább a 6.9.5-öt tedd fel ma. |
| 6.8.0 – 6.8.5 | Igen, az egyik | 6.8.6 | Frissíts. A kockázatod kisebb, de nem nulla — és a 6.8-as ág amúgy is elavul. |
| 6.7 vagy régebbi | Nem, ez a kettő nem | – | Megnyugodni nem érdemes: évekkel vagy le a támogatott verziótól, tucatnyi más javítás hiányzik. Tervezz frissítést. |
| 7.0.2 / 6.9.5 / 6.8.6 vagy újabb | Nincs érintve | – | Jó. Most nézd meg, hogy a 7.0.3 (2026. aug. 6.) 12 további javítása is megvan-e nálad. |
A verziómátrix a WordPress.org hivatalos kiadási dokumentációján alapul, amely kimondja: a 6.9-es ág mindkét hibában érintett, a 6.8-as ág csak az elsőben, a 6.8 előtti verziókat pedig egyik sem érinti (WordPress.org 7.0.2 dokumentáció).
Fontos, hogy július 17. nem a történet vége. 2026. augusztus 6-án megjelent a 7.0.3, ami egyetlen kiadásban 12 további sérülékenységet javított — köztük egy bejelentkezés nélkül elérhető hibát és négy olyat, amihez elég egy szerzői jogosultságú fiók (Patchstack). 2026. augusztus 19-én pedig kijött a WordPress 7.1 „Mary Lou” (WordPress.org). Vagyis ha most azt látod a mátrixban, hogy „7.0.2, minden rendben”, akkor is van dolgod.
Frissítés előtt egy dolgot mindig kérünk az ügyfeleinktől: legyen friss, visszatölthető mentés. Nem elég, hogy készül — ki is kell próbálni. Erről szól a 3-2-1 mentési szabályról írt cikkünk, és őszintén szólva ez a lépés az, ami a frissítést stresszmentessé teszi: ha van hova visszalépni, nem kell félni a Frissítés gombtól.
Hogyan kapcsolom be a biztonsági automatikus frissítéseket?
A WordPress 3.7 óta a karbantartási és biztonsági (minor) frissítések alapértelmezetten automatikusak, és a fejlesztők ezt kifejezetten úgy tervezték, hogy senkinek ne kelljen hozzányúlnia — a kikapcsolásukat a hivatalos dokumentáció is „határozottan ellenjavallja” (WordPress fejlesztői kézikönyv). A gyakorlatban mégis rengeteg olyan magyar oldal van, ahol ez le van tiltva.
Így ellenőrizd és kapcsold vissza:
• 1. Vezérlőpult → Frissítések. A lap tetején van egy mondat arról, hogy az oldalad automatikusan frissül-e minden új verzióra, vagy csak a karbantartási és biztonsági kiadásokra. Mellette egy link, amivel átkapcsolhatod. Ha itt megtalálod, kész is vagy. • 2. Ha nincs ott ilyen kapcsoló, akkor a beállítást a `wp-config.php` fájlban felülírták. Ilyenkor a `WP_AUTO_UPDATE_CORE` értékét kell legalább `’minor’`-ra állítani (ez a minor frissítéseket engedélyezi, a nagy verzióváltást nem), és ellenőrizni kell, hogy az `AUTOMATIC_UPDATER_DISABLED` nincs-e `true`-ra állítva. Ehhez már kell egy kis technikai magabiztosság vagy egy szakember — de ez egy egyszeri, tízperces munka. • 3. Nézd meg, hogy friss telepítés vagy régi. A WordPress 5.6-tól kezdve az új telepítések alapból a nagy verziókat is automatikusan kapják; a régebbi oldalak viszont megtartják a korábbi, csak minor frissítést engedő viselkedést, amíg valaki át nem állítja (WordPress fejlesztői kézikönyv). • 4. Bővítmények és sablonok. A Bővítmények képernyőn minden sor mellett ott van az „Automatikus frissítések bekapcsolása” link. A bővítmények alapból nem frissülnek automatikusan — pedig a 2025-ös új sérülékenységek 91%-a bővítményekben volt (Swif / Patchstack). Erről bővebben a biztonságos pluginválasztásról szóló cikkünkben írtunk. • 5. Ellenőrizd az admin e-mail-címet. A WordPress a sikeres és sikertelen automatikus frissítésekről levelet küld. Ha ez a cím egy régi kollégáé vagy egy nem olvasott postafiók, akkor a rendszer szól — csak nem neked. Beállítások → Általános, felül a „Adminisztrációs e-mail cím” mező.
Kézi, automata vagy felügyelt frissítés?
| Szempont | Kézi frissítés | Beépített automatikus minor frissítés | Felügyelt frissítés |
|---|---|---|---|
| Mikor fut le | Amikor eszedbe jut, vagy amikor ráérsz | A kiadás napján, magától, éjszaka is | Ütemezetten, tesztkörnyezetben ellenőrizve |
| Biztonsági kiadásnál | Órák vagy napok csúszás | Órákon belül lefut | Órákon belül, ellenőrzött módon |
| Nagy verzióváltás (pl. 7.0 → 7.1) | Rajtad múlik | Régi oldalakon alapból nem fut le | Előre tesztelve, visszaállítási ponttal |
| Bővítmények, sablonok | Kézzel, egyesével | Csak ha külön bekapcsolod | Csoportosan, kompatibilitás-ellenőrzéssel |
| Ha elszáll az oldal | Te veszed észre, ha észreveszed | Te veszed észre, ha észreveszed | Monitorozás jelez, mentésből visszaáll |
| Kinek való | Egyetlen egyszerű oldal, fegyelmezett tulajdonos | Mindenkinek — ez a minimum | Webshop, ügyfélportál, bevételt termelő oldal |
A táblázat közepső oszlopa a legfontosabb: ez az a szint, ami alatt ma már nem érdemes WordPress-oldalt üzemeltetni. A jobb szélső oszlop pedig arról szól, hogy valaki más figyeli helyetted, mi történt frissítés után.
Mit ellenőrizzek, ha napokig nem frissítettem?
Tegyük fel, hogy nyaraltál, vagy egyszerűen elszaladt az idő, és a frissítés csak napokkal később futott le. Ilyenkor a frissítés bezárja a hibát, de nem takarít ki utána — ha valaki már bejutott, ott is marad. Ez a lista végigmegy azokon a pontokon, ahol a nyom általában látszik. Egyik pont sem igényel fejlesztői tudást.
• Ismeretlen adminisztrátor. Felhasználók → Összes felhasználó, szűrj az „Adminisztrátor” szerepkörre. Ismersz minden nevet és e-mail-címet a listán? Egyetlen idegen fiók is elég ok a riasztásra. • Új vagy idegen bővítmény. Bővítmények → Telepített bővítmények. Nézd át a kikapcsolt bővítményeket is, nemcsak az aktívakat — az odacsempészett kód gyakran inaktívan pihen. Ha egy bővítmény neve semmit nem mond, keress rá. • Idegen PHP-fájl a feltöltések között. A `wp-content/uploads` mappában képek és dokumentumok laknak. PHP-fájl ott soha nem indokolt. Ha a tárhelyed fájlkezelőjében ilyet találsz, az önmagában gyanús. • A mu-plugins könyvtár. A `wp-content/mu-plugins` mappa tartalma automatikusan betöltődik, és nem jelenik meg a Bővítmények képernyőn. Pont ezért kedvelt rejtekhely. Nézd meg, van-e ilyen mappád, és ha igen, mi van benne. • Ütemezett feladatok. A WordPress belső ütemezője (WP-Cron) rendszeresen futtat feladatokat. Egy ismeretlen bejegyzés itt azt jelentheti, hogy valami magától újraindul. Laikusként a WP Crontrol bővítménnyel lehet a legegyszerűbben ránézni. • Kimenő spam. Kérdezd meg a tárhelyszolgáltatód, nőtt-e a domainedről kimenő levelek száma. Árulkodó jel az is, ha a saját, korábban működő céges leveleid hirtelen elkezdenek spambe esni vagy visszapattanni. • Nem várt tartalom. Új, általad nem írt bejegyzések vagy oldalak, idegen nyelvű szövegek, furcsa átirányítások mobilon.
Ha a lista bármelyik pontján megakadtál, a feltört oldal 8 árulkodó jeléről szóló cikkünk részletesen végigveszi, mi számít valódi jelnek és mi csak ijesztő látszatnak.
Egy fontos figyelmeztetés: ne csak töröld, amit találsz. Egy ügyfelünknél a talált idegen fájl törlése után az oldal két napig rendben volt, majd újra megjelent ugyanaz — mert a valódi belépési pont máshol maradt. Ilyenkor a helyes sorrend: mentés az aktuális (fertőzött) állapotról bizonyítéknak, jelszavak cseréje, teljes átvizsgálás, és csak utána takarítás.
És igen, van olyan is, hogy a lista végigfut, és semmi nincs. Egy magyar szolgáltató ügyfelünknél a késve lefutott frissítés után teljes átvizsgálást kértünk, és tisztán jött ki minden pont. Ez is eredmény — a bizonyosság megéri a fél órát.
Mit tud a virtuális javítás, amíg te frissítesz?
Itt jön a rész, ami a 90 percre válaszol. A virtuális javítás (angolul virtual patching) egy olyan tűzfalszabály, ami az alkalmazás módosítása nélkül blokkolja azokat a kéréseket, amelyekről tudni lehet, hogy egy konkrét ismert hibát próbálnak kihasználni (WP Umbrella). A hiba a kódban ott marad — de a kérés nem jut el hozzá.
Ennek az a haszna, hogy másodpercek alatt élesíthető, míg a valódi frissítés tesztelést, ütemezést, esetenként fejlesztői egyeztetést kíván. A júliusi kampány alatt a Patchstack a saját ügyfeleinél a blokkolt kísérletek 99,9%-át a két hibához tartozó célzott szabállyal fogta meg, még mielőtt az első próbálkozás megérkezett volna.
Két józan megjegyzés hozzá. Az egyik: a virtuális javítás nem helyettesíti a frissítést, csak áthidalja az időt, amíg odaérsz. A másik pedig egy tanulság, amit a Patchstack maga is nyíltan leírt: az első órákban kiadott tűzfalszabályok szinte az egész iparágban ugyanazt a vakfoltot tartalmazták, és megkerülhetők voltak, amíg mindenki nem frissítette őket. Vagyis a védelem is karbantartást igényel — ez nem egy kapcsoló, hanem egy szolgáltatás.
Érdemes tudni azt is, hogy a tárhelyszintű védelem önmagában kevés. A Patchstack 2025-ös, népszerű tárhelyszolgáltatókon végzett tesztjei szerint a szokásos hoszting-védelmek a sérülékenység-kihasználási kísérletek mindössze 26%-át fogták meg, a kifejezetten WordPress ellen irányuló támadásoknak pedig csak a 12%-át (Swif / Patchstack). Ez nem a tárhelyek hibája: a hálózati tűzfal nem ismeri a WordPress belső logikáját, ezért a jól formázott, „szabályosnak látszó” kéréseket átengedi.
Mennyire vagy egyedül ezzel a problémával?
Egyáltalán nem. A WordPress a webhelyek 41,5%-át hajtja, és a felismerhető tartalomkezelővel működő oldalak nagyjából 59%-át (W3Techs adatai a Swif összesítésében). Ez a koncentráció az, amiért egyetlen működő core-hiba azonnal az egész internetre kilőhető.
A jó hír, hogy a WordPress-alapok ma sokkal frissebbek, mint tíz éve: a telepítések nagyjából 92%-a a 6-os vagy újabb ágon fut. És pont ezért volt olyan éles ez a júliusi eset: a hibás kód csak a 6.8-as verziótól létezett, vagyis a legfrissebb oldalak voltak a legveszélyeztetettebbek (Swif). Aki évek óta nem frissített, azt ez a konkrét hiba nem érintette — de tucatnyi másik igen.
A kockázat súlypontja amúgy régóta nem a WordPress magjában van. A 2025-ben felfedezett 11 334 új sérülékenység 91%-a bővítményekben volt, és a nyilvánosságra hozott hibák 46%-ához egyáltalán nem létezett javítás a bejelentés pillanatában (Swif / Patchstack). Ez az a majdnem fele az eseteknek, ahol a „frissíts mindig” tanács önmagában nem működik — mert nincs mire frissíteni. Ilyenkor marad a virtuális javítás és a monitorozás.
Nem tudod, melyik verzión futsz? Nézzük meg együtt
Nálunk a WP Pajzsnál a karbantartási csomag pontosan ezt a rést zárja be: a biztonsági kiadásokat felügyelt módon, órákon belül tesszük fel, mentéssel a hátunk mögött — és ha valami mégis félremegy, van hova visszalépni. Ha pedig a baj már megtörtént, a feltört oldal helyreállítása is nálunk van.
Kezdd a legegyszerűbb lépéssel: kérd az ingyenes biztonsági gyorsellenőrzésünket. Megnézzük, milyen WordPress-verzió fut az oldaladon, be van-e kapcsolva az automatikus biztonsági frissítés, és van-e olyan nyom, ami utólagos átvizsgálást indokol. Tizenöt perc, és tudni fogod, hol állsz.
*Források: WordPress.org — WordPress 7.0.2 Release (2026. július 17.); WordPress.org — Version 7.0.2 dokumentáció; WordPress.org — WordPress 7.1 „Mary Lou” (2026. augusztus 19.); WordPress fejlesztői kézikönyv — Upgrading WordPress / Configuring Automatic Background Updates; Patchstack — Ninety minutes: watching attackers weaponize the WordPress core RCE (2026. július 22.); Patchstack — WordPress 7.0.3 Released: 12 Vulnerabilities Found and Fixed (2026. augusztus 6.); Swif — WordPress Security Statistics for 2026 (Patchstack, W3Techs, Verizon DBIR 2026 adataival); WP Umbrella — What is Virtual Patching in WordPress?.*
Gyakori kérdések
Milyen WordPress-verziót futtatok, és hol nézem meg?
Lépj be az adminba, és nézd meg a Vezérlőpult „Egy pillantásra” dobozát: ott szerepel a pontos verziószám. Ugyanezt megtalálod a Vezérlőpult → Frissítések képernyőn, illetve az Eszközök → Oldal állapota → Információ menüpont WordPress fülén. Ha nem tudsz belépni, kérdezd meg a tárhelyszolgáltatód vezérlőpultján, mert a legtöbb panel is kiírja a telepített verziót.
Érintett vagyok-e a WordPress 7.0.2-ben javított hibák által?
Ha az oldalad a 6.8-tól 7.0.1-ig terjedő verziók valamelyikén fut, akkor igen. A WordPress.org hivatalos közlése szerint a 6.9-es ág mindkét hibában érintett, a 6.8-as ág csak az egyikben, a 6.8-nál régebbi verziókat pedig ez a két hiba nem érinti. Ha a verziószámod 7.0.2, 6.9.5 vagy 6.8.6, illetve ezeknél újabb, akkor ez a két hiba nálad már be van foltozva.
Melyik verzió javítja a hibát?
A javítás három ágon érkezett: 7.0.2, 6.9.5 és 6.8.6. Mindhárom 2026. július 17-én jelent meg. A legjobb megoldás azonban nem ezekre a verziókra állni meg, hanem a legfrissebb kiadásra frissíteni, mert azóta megjelent a 7.0.3 (2026. augusztus 6., 12 további javított sérülékenység) és a 7.1 „Mary Lou” (2026. augusztus 19.) is.
Mit ellenőrizzek, ha napokig nem frissítettem?
Nézd át a felhasználók listáját ismeretlen adminisztrátor után kutatva, a bővítménylistát új vagy idegen tételekért, az uploads mappát PHP-fájlokért, és a wp-content/mu-plugins könyvtárat, ami nem jelenik meg a Bővítmények képernyőn. Ellenőrizd az ütemezett feladatokat és azt is, hogy nem megy-e kimenő spam a domainedről. Ha bármit találsz, ne csak töröld: kérj szakértői átvizsgálást, mert a hátsó kapu ritkán jár egyedül.
Hogyan kapcsolom be a biztonsági automatikus frissítéseket?
A WordPress 3.7 óta a karbantartási és biztonsági (minor) frissítések alapból automatikusak, de sok oldalon ezt valaki kikapcsolta. Menj a Vezérlőpult → Frissítések képernyőre, és nézd meg a lap tetején lévő automatikus frissítési sort — ott tudod bekapcsolni. Ha nincs ott ilyen kapcsoló, a wp-config.php fájlban felülírták a beállítást; ilyenkor a WP_AUTO_UPDATE_CORE értékét kell legalább „minor”-ra állítani, és ellenőrizni, hogy az AUTOMATIC_UPDATER_DISABLED nincs bekapcsolva.
Mi az a virtuális javítás, és kiváltja-e a frissítést?
A virtuális javítás egy tűzfalszabály, ami már a WordPress előtt kiszűri azokat a kéréseket, amelyek egy ismert hibát próbálnak kihasználni — az oldal kódjához hozzá sem kell nyúlni. Ez a védelem másodpercek alatt élesíthető, ezért képes áthidalni a kiadás és a te frissítésed közötti órákat. Nem váltja ki a frissítést, hanem időt vesz neked hozzá.
