Október 21-én, 2026-ban a PHP projekt két kritikus sebezhetőséget javított. Bármilyen PHP-t futtató szerveren – így minden WordPress-oldalon is – a támadók hitelesítés nélkül futtathatnak kódokat távolról. A lényeg egyetlen mondatban: a hiba NEM a WordPressben van, hanem a PHP-ban, ezért a megoldást a szerveres PHP-frissítés jelenti, amit az esetek többségében a tárhelyszolgáltatód végez el. Ellenőrizd, milyen PHP-verziót használ a weboldalad – ez csupán 2 perc, a pontos útmutatót lentebb találod.
| Tény | Részletek |
|---|---|
| Sebezhetőségek | CVE-2026-109618 (RCE memóriasérülésen keresztül) és CVE-2026-109619 (RCE elavult globális állapot miatt). |
| Kockázat (CVSS v4.0) | 9.2 (Kritikus) mindkét hiba esetében. |
| Javított verziók | PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 (kiadás dátuma: 2026-10-21). |
| Érintettek | Minden kiszolgáló oldali PHP-t futtató rendszer (mod_php, PHP-FPM, php-cgi, LiteSpeed, FrankenPHP). |
| Legveszélyeztetettebb vektor | Apache + mod_php alapbeállításokkal. |
| Átmeneti mitigációk | memory_limit=-1, alacsony post_max_size (pl. 8M), session.upload_progress.enabled=0, valamint a workerek újraindítása. PHP 8.5-ön fatal_error_backtraces=0. |
Mi történt röviden?
Két kritikus, távoli kódfuttatást (RCE) lehetővé tevő hibát fedeztek fel a PHP magjában. Ez azt jelenti, hogy minden kiszolgáló oldali PHP-t futtató rendszer érintett lehet. A CVE-2026-109618 esetében a probléma memóriasérülésből fakad: ha egy lekérés pont a legrosszabb pillanatban éri el a memóriakorlátot (memory_limit), a PHP belső állapota sérülhet. A CVE-2026-109619 esetében egy végzetes hiba (fatal error) miatt a futtatófolyamat (worker) memóriája egy már felszabadított adatra mutathat, amit a következő lekérés rosszindulatúan felhasználhat.
A legveszélyeztetettebbek az alapbeállításokkal futó Apache + mod_php szerverek, ahol még a webes alkalmazás kódjának lefutása előtt, egyetlen hitelesítetlen lekéréssel is végrehajtható a támadás. Mivel a sebezhetőségek azonosítói október 20-án kiszivárogtak, a biztonsági frissítést egy nappal előrehozták. Bár demonstrációs (PoC) kódok már keringenek, a javítás kiadásának pillanatában még nem azonosítottak éles, tömeges támadásokat.
Miért érdekel ez téged, ha WordPress-oldalad van?
A WordPress PHP nyelven íródott. Bár a hiba nem magában a WordPressben vagy az általad használt bővítményekben van, minden WP-oldal PHP-t használ, így a weboldalad szerveres környezete is sebezhető lehet.
Fontos árnyalat: magának a WordPressnek (a WP-core-nak) a frissítése itt nem nyújt védelmet. A szerveren futó PHP-t kell frissíteni, ami általában a tárhelyszolgáltató feladata.
Hogyan derítsd ki, milyen PHP-t használsz?
A legegyszerűbben a WordPress adminisztrációs felületén ellenőrizheted:
- Lépj az Eszközök → Webhely egészsége menüpontba.
- Válaszd a Szerver fület, ahol azonnal láthatod az aktuális PHP-verziót.
Ezt a tárhelyed adminisztrációs felületén (pl. cPanel, Plesk) a PHP-választó menüben is megnézheted, vagy egy ideiglenes phpinfo() fájllal, amit az ellenőrzés után azonnal törölni kell.
Mennyire vagy veszélyben?
- Magas kockázat: Saját VPS-t vagy dedikált szervert használsz Apache + mod_php párossal, és te végzed a karbantartást. A helyzetet rontja, ha PHP 8.1-es vagy annál régebbi verziót futtatsz, engedélyezett a fájlfeltöltés, vagy túl magas a post_max_size értéke. Ilyenkor azonnali frissítés szükséges.
- Közepes kockázat: Osztott tárhely (shared hosting) és PHP-FPM használata esetén a frissítés a szolgáltató feladata. Írd meg nekik, hogy megtörtént-e már a javítás.
- Alacsonyabb kockázat: A menedzselt WordPress tárhelyek (mint a Kinsta, WP Engine, Cloudways stb.) jellemzően automatikusan és gyorsan elvégzik a biztonsági frissítéseket. A biztonság kedvéért érdemes tőlük is visszaigazolást kérni.
Mit tegyél most? A lépések:
- Nézd meg a PHP-verziót a fent leírt módon.
- Ütemezd a frissítést: Ha a PHP 8.2-nél régebbi verziót használsz, frissíts minimum a 8.2.35-ös vagy a 8.3-as (pl. 8.3.36) verzióra. A WordPress.org hivatalos ajánlása jelenleg a PHP 8.3, új telepítéseknél pedig a 8.4 vagy a 8.5.
- Keresd fel a szolgáltatódat: Ha menedzselt tárhelyed van, küldj nekik egy rövid üzenetet: „Kérem a tájékoztatásukat, hogy a CVE-2026-109618 és CVE-2026-109619 PHP sebezhetőségek javításai telepítésre kerültek-e a szerveremen?“.
- Alkalmazz átmeneti védelmet (ha nem tudsz azonnal frissíteni): A memory_limit=-1 (ezt php_admin_value direktívával érdemes beállítani, hogy a kód ne tudja felülírni), a session.upload_progress.enabled=0, és a post_max_size alacsony értékre (pl. 8M) állítása, kiegészítve a workerek újraindításával segíthet kivédeni a támadást. Figyelem: ezek nem helyettesítik a frissítést, csupán időt nyernek.
- Tesztelj a frissítés után: Nézz rá újra a Webhely egészsége menüpontra, és végezz el egy gyors tesztet az oldalon (küldj be egy űrlapot, vagy tegyél egy terméket a kosárba).
A PHP 8.1 és a régebbi verziók csapdája
A PHP 8.2 hivatalos támogatása december 31-én lejár, a PHP 8.1 és az annál korábbi verziók pedig már most sem kapnak hivatalos frissítéseket. A jelenlegi javításokat ezekhez a verziókhoz a PHP projekt már nem adja ki telepíthető formában (csak a forráskódból építkezőknek érhető el egy nem hivatalos backport a 7.4, 8.0 és 8.1 verziókhoz). Családi vagy kisvállalkozói tárhelyeken gyakran felejtődnek fent ezek az elavult rendszerek, ami most fokozott biztonsági kockázatot jelent.
Tévhitek és a valóság
- Mit NEM jelent ez: Ez nem egy számítógépes vírus, nem a WordPress saját hibája, és egyáltalán nem kell újraépítened a weboldaladat.
- Mit jelent a valóságban: Az első hetek kritikusak: frissíteni kell a rendszert, még mielőtt a támadók tömegesen elkezdenék kihasználni a hibát. A korábbi esetek (mint a Log4Shell vagy a nagyobb WordPress bővítmény-sebezhetőségek) megmutatták, hogy nem szabad halogatni a patchelést.
Összegzés
Menj végig ezen a gyors ellenőrzőlistán:
- PHP verzió ellenőrizve.
- Tárhelyszolgáltató megkérdezve (ha szükséges).
- Frissítés ütemezve.
- Átmeneti megoldások beállítva (ha a frissítés csúszik).
- Webhely egészsége zöldet mutat a beavatkozás után.
További tippekért olvasd el a kapcsolata a webhellyel nem teljesen biztonságos cikkünket, és a WordPress SEO bővítmények útmutatót.
Gyakran Ismételt Kérdések (FAQ)
Érinti a WordPress-t magát?
A WordPress forráskódját nem érinti, de a futtatókörnyezetet, vagyis a szerveren lévő PHP-t igen, amin a weboldalad is működik.
Ki frissít: én vagy a tárhelyszolgáltató?
Osztott és menedzselt tárhelyeken a tárhelyszolgáltatód végzi el a szerverszintű frissítéseket. Ha saját, menedzseletlen VPS-t használsz, akkor neked kell beállítanod.
Elég, ha lefrissítem a WordPress-t a vezérlőpulton?
Nem. Mivel a hiba magában a PHP-ban van, a WordPress adminisztrációs felületén elvégzett frissítés itt nem jelent megoldást.
Melyik PHP-verzió javasolt jelenleg?
A WordPress.org hivatalos ajánlása a PHP 8.3. (Ennek a legfrissebb, biztonságos verziója jelenleg a 8.3.36.)
Mit tegyek, ha nem tudok azonnal frissíteni?
Alkalmazd az átmeneti megoldásokat (mitigációkat), mint például a memory_limit=-1 és a session.upload_progress.enabled=0 beállítását, de ne feledd, hogy ezek csak időnyerésre szolgálnak.
Hogyan ellenőrizhetem, hogy az üzemeltető tényleg frissített-e?
A WordPress admin felületén az Eszközök → Webhely egészsége → Szerver fül alatt megnézheted a futó verziószámot. Ha ott például a 8.3.36-os (vagy az aktuális javított) verziót látod, akkor a szervered védett.