WordPress 7.1.2: kritikus sebezhetőség a magban, amelyet a támadók már kihasználnak

A WordPress 7.1.2 sebezhetőség, a CVE-2026-87902 kritikus hiba a WordPress magjában, amelyet a WordPress 2026. szeptember 22-én javított a 7.1.2-es verzióban. A támadónak ehhez nem kell bejelentkeznie. Egy hamisított kéréssel rá tudja venni az oldalsablon kiválasztását, hogy egy másik PHP-fájlt töltsön be a szerveren, és ha a szerver és a téma megfelel a feltételeknek, saját kódot futtat. Az érintett verziók a 4.7.0-tól a 7.1.1-ig terjednek, a javítás pedig minden ágra megjelent egészen a 4.7-ig. A Patchstack már aktív kihasználást észlelt, beleértve fájlok lemezre írását is. Frissítsen még ma.

Ez a cikk gyakorlati teendőlista weboldal-tulajdonosoknak és -üzemeltetőknek: mit csinál a hiba, hogyan derítheti ki a verzióját, hogyan frissítsen a weboldal elrontása nélkül, hogyan keresse a támadás nyomait, és mit tegyen, ha a frissítés azonnal nem megy. Az általános védelmi elveket a WordPress weboldal biztonságáról szóló 10 pontos ellenőrzőlistánkban találja, itt csak ezzel a konkrét hibával foglalkozunk.

Mi a WordPress 7.1.2 sebezhetőség, a CVE-2026-87902

Path traversal hibáról van szó az oldalsablon kiválasztásánál, amely helyi PHP-fájl beillesztéséhez (local file inclusion), bizonyos feltételek mellett pedig távoli kódfuttatáshoz (RCE) vezet.

Amikor a WordPress megjelenít egy oldalt, a get_page_template() függvény összeállítja a sablonfájl-jelöltek listáját. A Patchstack technikai elemzése szerint az egyik jelölt a pagename paraméterből állt össze, amely közvetlenül a kérésből érkezik, és a kód szomszédos ágától eltérően nem ment át a validate_file() ellenőrzésen. Így egy kódolt, egy mappával feljebb lépő szekvencia egészen a fájl elérési útjáig eljutott, és a WordPress az aktív téma mappáin kívüli PHP-fájlt is be tudott illeszteni.

A hivatalos GHSA-7hp8-65ch-5whp biztonsági advisory kritikusnak minősíti a hibát, CVSS 4.0 szerinti 9,2-es pontszámmal, és a CWE-98 kategóriába sorolja. Ahhoz, hogy a támadó saját kódot futtasson, két feltételnek kell teljesülnie:

• A témában van page- kezdetű mappa: az aktív szülő- vagy gyermek (child) téma gyökerében van egy mappa, amelynek neve page- előtaggal kezdődik, például page-templates. Az advisory név szerint említi a régebbi alapértelmezett Twenty Twelve és Twenty Fourteen témát, valamint a népszerű külső Neve, Hestia és Sydney témát.
• A szerveren van alkalmas PHP-fájl: a támadók a PEAR csomag jól ismert pearcmd.php fájlját használják, amely kihasználható, ha a PHP-ben be van kapcsolva a register_argc_argv beállítás. Az advisory szerint ez érvényes a hivatalos php Docker image-re és a cPanel alapértelmezett konfigurációjára 8.5-nél régebbi PHP esetén.

Ha a téma teljesíti az első feltételt, a fájlbeillesztés bejelentkezés nélkül működik. Hogy a támadó saját kódot is futtat-e, az a szervertől függ. A Patchstack ezért azt javasolja, hogy kezelje kritikusként a hibát, amíg a saját környezetét nem ellenőrizte. A 7.1.2-es javítás két részből áll: pótolta a hiányzó validate_file() ellenőrzést, és új ellenőrzést vezetett be, amely szerint minden eredő sablonútvonalnak a téma engedélyezett mappájában kell lennie. A Patchstack szerint a biztonsági csapat így nem egyetlen hibát, hanem egy egész problémaosztályt kezelt.

Kiket érint a WordPress 7.1.2 sebezhetőség, és mely verziók javítottak

Érintett minden 4.7.0 és 7.1.1 közötti WordPress weboldal, amely még nem kapta meg a saját ágának javított verzióját. A WordPress minden olyan ágra kiadta a javítást, amely még biztonsági javításokat kap, vagyis egészen a 4.7-ig. Így egy régebbi weboldal is megkapja a javítást új főverzióra ugrás nélkül. A 7.1.2-es kiadás hivatalos bejelentése szerint azonban aktívan csak a legújabb verzió támogatott.

Ág	Sebezhető verziók	Javított verzió
7.1	7.1.0-tól 7.1.1-ig	7.1.2
7.0	7.0.0-tól 7.0.5-ig	7.0.6
6.9	6.9.0-tól 6.9.8-ig	6.9.9
6.8	6.8.0-tól 6.8.9-ig	6.8.10
6.7	6.7.0-tól 6.7.8-ig	6.7.9
6.6	6.6.0-tól 6.6.8-ig	6.6.9
6.5	6.5.0-tól 6.5.11-ig	6.5.12
4.7	4.7.0-tól 4.7.36-ig	4.7.37

A verzióját egy perc alatt kiderítheti:

• Az adminisztrációban: Vezérlőpult > Frissítések. Az oldal megmutatja az aktuális verziót, és felajánlja a frissítést, ha elérhető.
• WP-CLI-vel: a wp core version parancs kiírja a mag verzióját.
• Több weboldal esetén: ellenőrizze mindet, a régi microsite-okat, az aldomaineken futó weboldalakat és a hostingon lévő tesztmásolatokat is. Az automatizált szkenner ugyanúgy átfésüli őket, mint a fő weboldalt.

Ha a weboldalon be vannak kapcsolva a háttérben futó automatikus frissítések, a WordPress bejelentése szerint a frissítés magától elindul. Ne vegye ezt kész ténynek, és ellenőrizze a verziót. Az automatikus frissítéseket a múltban valaki kikapcsolhatta, és ez általában csak egy hasonló incidensnél derül ki.

Hogyan frissítsen még ma a weboldal elrontása nélkül

A mag javított verzióra frissítése az egyetlen valódi javítás, minden más csak átmenetileg csökkenti a kockázatot. A Patchstack szerint a 7.1.2 tisztán biztonsági kiadás egyetlen javítással, így kisebb a kockázata, hogy elrontja a weboldalt, mint egy nagy frissítésnél. Ennek ellenére ebben a sorrendben haladjon:

1. Mentés: a frissítés előtt mentse az adatbázist és a fájlokat is. Ha nincs bevált folyamata, használja az útmutatónkat a WordPress weboldal 3-2-1 szabály szerinti mentéséről.
2. Frissítés: az adminisztrációban Vezérlőpult > Frissítések > Frissítés most, vagy WP-CLI-ben a wp core update paranccsal. Régebbi ágon célzottan telepítheti ugyanannak az ágnak a javított verzióját, például wp core update --version=6.8.10, a legújabb verzióra váltást pedig külön ütemezheti.
3. A verzió ellenőrzése: a frissítés után nézze meg újra, hogy a weboldal valóban a 7.1.2-es vagy a saját ágának javított verzióján fut-e.
4. Funkcionális teszt: járja végig a weboldal kulcsfontosságú pontjait: kapcsolatfelvételi űrlap, bejelentkezés, webáruháznál a kosár és a pénztár.

Webáruháznál vagy sok bővítményt használó weboldalnál biztonságosabb a tesztmásolaton keresztüli folyamat, amelyet a WordPress frissítések staginggel és rollbackkel című cikkben írunk le. Egy olyan hibánál azonban, amelyet a támadók már aktívan próbálgatnak, ne halassza napokkal az éles frissítést. Ha a frissítés után valami elromlik, segít az útmutató arról, mit tegyen, ha a weboldal a WordPress frissítése után nem működik.

Hogyan derítse ki, próbálkoztak-e már a támadók a weboldalán

A támadások a javítás kiadásának napján kezdődtek, ezért nem elég frissíteni, a naplókba és a szerverre is be kell nézni. A Patchstack folyamatos megfigyelése szerint a tűzfaluk 2026. szeptember 22-én, vagyis a 7.1.2 kiadásának napján észlelte az első próbálkozásokat, és még aznap az első kísérletet is arra, hogy a pearcmd.php-n keresztül fájlt írjanak a lemezre. A Patchstack szerint a támadók a javítás kódjának különbségéből építették fel a támadásokat. Szeptember 23. óta nyilvános szkennelőeszközök keringenek, köztük egy névvel ellátott sablon a Nuclei szkennerhez, így ma bárki próbálgatja a hibát, nem csak a támadók egy szűk köre.

A Patchstack szerint a támadás három fázisban zajlik: annak ellenőrzése, hogy a fájlbeillesztés működik-e (ártalmatlan magfájlokon keresztül), annak ellenőrzése, hogy elérhető-e a pearcmd.php, és egy PHP-fájl lemezre írása. A hozzáférési naplókban (access log) ezeket a jeleket keresse:

• %2e%2e vagy %252e%252e szekvenciát tartalmazó pagename paraméter a címben és a POST kérés törzsében is,
• templates%2f előtaggal vagy egy másik page- mappa nevével kezdődő pagename érték,
• a pagename és a page_id paraméter együtt, egyetlen kérésben a weboldal gyökerére vagy a /index.php-ra,
• a pearcmd, +config-show vagy +config-create karakterlánc bármilyen előfordulása.

A szerveren ellenőrizze a /tmp és a /var/tmp mappát. Az ott található váratlan .php fájlok a Patchstack szerint azt jelentik, hogy az írás sikerült, és a szervert kompromittáltnak kell tekinteni, nem csak szkenneltnek. A második jel a naplókban van: ha egy szokásos oldalcímre OPML vagy RSS tartalmú 200-as válasz érkezik, az azt jelenti, hogy a fájlbeillesztés az Ön szerverén megtörtént. Osztott hostingon ezekbe a mappákba gyakran nem lát bele, ilyenkor kérje a hostingszolgáltató ellenőrzését.

Ha ilyen nyomokat talál, a frissítés önmagában nem elég. Változtassa meg az adminisztrátorok jelszavát és a hosting hozzáféréseit is, újítsa meg a biztonsági kulcsokat a wp-config.php-ban, ellenőrizze az adminisztrátor szerepkörű felhasználók listáját, és fontolja meg a visszaállítást egy támadás előtti mentésből.

Mit tegyen, ha nem tud azonnal frissíteni

A kockázatot átmenetileg csökkenteni lehet, de ezek közül semmi sem helyettesíti a frissítést. Ezek a lépések csak áthidalásra szolgálnak, amíg a frissítést elő nem készíti:

• Nézzen bele a téma mappájába: nyissa meg a wp-content/themes mappát, és az aktív témában, valamint a szülőtémájában is keressen a gyökérben olyan mappát, amelynek neve page- előtaggal kezdődik. Ha van ilyen, a kihasználás első feltétele teljesül.
• Ellenőrizze a register_argc_argv beállítást: az értéket a webes PHP phpinfo() kimenetében találja, vagy kérdezze meg a hostingszolgáltatót. A Patchstack szerint a kikapcsolása nem javítja a fájlbeillesztést, de megszakítja a pearcmd-n keresztüli láncot, amely az információszivárgásból kódfuttatást csinál.
• Szabály a tűzfalban (WAF): utasítsa el azokat a kéréseket, amelyekben a pagename paraméter egy mappával feljebb lépő szekvenciát tartalmaz. Egy valódi oldal slugja ilyet soha nem tartalmaz, így a Patchstack szerint ez a normál forgalmat nem korlátozza.
• Ne hagyatkozzon IP-címek blokkolására: a Patchstack több száz címről érkező támadásokat tart nyilván, és a kérések többsége szokásos böngészőnek adja ki magát.

A gyakorlatban: mit mutat ez a hiba a weboldal karbantartásáról

A mag hibája azokat a weboldalakat is érinti, amelyeknél a bővítmények rendben vannak, ezért a karbantartás nem állhat csak a bővítmények ellenőrzéséből. Szlovák céges weboldalaknál a gyakorlatban azt látjuk, hogy leginkább a „változtatás nélküli” weboldalakról feledkeznek meg: egy kampány microsite-járól, egy aldomainen futó régi weboldalról, egy tesztmásolatról a hostingon. Éppen ezek futnak évekig régi ágon, és senki sem figyeli őket. Ennél a hibánál ráadásul a téma szerkezete is döntő, amit a sebezhető bővítmények szokásos áttekintése nem mutat meg.

A második tanulság a gyorsaság. Ha a támadók a javítás kiadásának napján próbálgatják a hibát, a havi frissítési ciklus a biztonsági kiadásokhoz nem elég. A staginggel ellenőrzött folyamatnak nagy verzióknál van értelme, a mag biztonsági kiadásának viszont még aznap a weboldalra kell kerülnie. Hogy ebbe hogyan illeszkedik a karbantartás egész éve, azt a WordPress weboldal karbantartásának teljes útmutatójában írjuk le.

Hogyan oldjuk meg a Denvánál: amikor egy weboldalt támogatásra és karbantartásra átveszünk, először megnézzük a verziókat, a bővítményeket, a mentéseket, a hostingot és a biztonsági állapotot. A rendszeres karbantartás során folyamatosan figyeljük az ismert sebezhetőségeket, és minden frissítés után ellenőrizzük, hogy a weboldal valóban működik, például hogy elküldhető az űrlap, és betölt a pénztár. Olyan weboldalakat is gondozunk, amelyeket valaki más épített.

Mikor boldogul egyedül, és mikor velünk

Egyedül is boldogul, ha:

• egy weboldala van az aktuális ágon, és be vannak kapcsolva a mag automatikus frissítései,
• ellenőrizni tudja a verziót, és olyan mentést tud készíteni, amelyből már állított vissza,
• a hosting kérésre elküldi a hozzáférési naplókat, és ellenőrzi a /tmp mappákat.

Érdemes minket bevonni, ha:

• a naplókban kódolt szekvenciákat tartalmazó pagename paramétert vagy pearcmd karakterláncot lát,
• a weboldal régi ágon fut, vagy page- mappát tartalmazó módosított témája van,
• több weboldalt üzemeltet, és nincs áttekintése arról, milyen verziókon futnak,
• nincs olyan mentése, amelyből megbízhatóan vissza tudná állítani a weboldalt.

Összegzés

Ha a WordPress weboldala sem a 7.1.2-es, sem a saját ágának javított verzióján nem fut, frissítsen még ma, majd nézzen bele a naplókba és a /tmp mappákba. A hiba CVSS 4.0 szerinti értékelése 9,2, a javítás a 4.7-től minden ágra létezik, és a Patchstack szerint a támadások a kiadás napja óta zajlanak. A page- mappát tartalmazó téma és a bekapcsolt register_argc_argv a fájlbeillesztésből kódfuttatást csinál, ezért mindkét feltételt a frissítés után is ellenőrizze. Ha nem biztos benne, mit talált a naplókban, írjon nekünk, és megnézzük együtt.

GYIK

Gyakori kérdések.

Biztonságban van a weboldalam, ha be vannak kapcsolva az automatikus frissítések?

Valószínűleg igen, de ellenőrizze. A WordPress bejelentése szerint a háttérben futó automatikus frissítésekkel rendelkező weboldalakon a frissítés magától elindul. Az adminisztrációban a Frissítések oldalon nézze meg, hogy a weboldal a 7.1.2-es vagy a saját ágának javított verzióján fut-e.

Át kell térnem a WordPress 7.1-re, ha régebbi verzióm van?

E hiba miatt nem. A WordPress minden ágra kiadta a javítást egészen a 4.7-ig, például a 6.8.10-es vagy a 4.7.37-es verziót. Aktívan azonban csak a legújabb verzió támogatott, ezért ütemezze be a váltást.

Honnan tudom, hogy a témám teljesíti-e a kihasználás feltételét?

Nézzen bele az aktív téma és a szülőtémája mappájába a wp-content/themes alatt. Ha a gyökerében van olyan mappa, amelynek neve page- előtaggal kezdődik, például page-templates, a feltétel teljesül. A frissítést ez azonban nem helyettesíti.

Mi a teendő, ha a naplókban pearcmd karakterláncot tartalmazó kéréseket találok?

Ez azt jelenti, hogy a támadó a kódfuttatáshoz vezető láncot próbálgatta. Ellenőrizze a /tmp és a /var/tmp mappát váratlan .php fájlok után kutatva. Ha vannak ilyenek, tekintse a szervert kompromittáltnak, változtassa meg a hozzáféréseket, és fontolja meg a visszaállítást mentésből.

Elég egy tűzfal vagy biztonsági bővítmény a frissítés helyett?

Nem. A pagename paraméterben a mappával feljebb lépő szekvenciákat elutasító szabály a Patchstack szerint hatékony átmeneti védelem. Az egyetlen valódi javítás a mag frissítése a javított verzióra.