← Vissza a bloghoz

PHP2Shell: kritikus PHP-sebezhetőség – mit tegyen most egy webshop?

2026. október 21-én a PHP kiadta két kritikus hiba javítását (CVE-2026-109618 és CVE-2026-109619, közös nevük PHP2Shell). A hibákkal jelszó nélkül, távolról lehet kódot futtatni a szerveren, és a támadások már elkezdődtek. Ha a webshopod WooCommerce-en, WordPressen, PrestaShopon, Magentón vagy bármilyen más PHP-alapú rendszeren fut, ma nézd meg, milyen PHP-verzión vagy.

Utoljára frissítve: 2026. október 22. A cikket folyamatosan frissítjük, ha új információ jelenik meg.

Mi történt, röviden?

A PHP a weboldalak motorja: a W3Techs 2026. október 21-i mérése szerint azoknak az oldalaknak, ahol ismert a szerveroldali nyelv, 69,3%-a PHP-n fut. Erre épül a WordPress, a WooCommerce, a PrestaShop, a Magento, a Drupal, a Joomla és a Laravel is.

A Wiz és a Calif biztonsági kutatói 2026 augusztusában két súlyos hibát találtak magában a PHP-ban, mesterséges intelligencia segítségével. A Wiz szerint a hiba évtizedek óta benne volt a PHP-ban, a PHP 5.4-től kezdve.

A PHP hivatalos közleménye szerint mindkét hiba CVSS v4.0 szerint 9,2-es, vagyis kritikus. Kihasználásukkal a támadó bejelentkezés nélkül futtathat kódot a szerveren. Nem kell hozzá jelszó, nem kell hozzá rés a webshopodban: a hiba alattuk van, a motorban.

Idővonal: 2026. augusztus 19. a hiba felfedezése, október 17. első támadási kísérlet, október 21. 03:02 Cloudflare-védelem, 14:00 javított PHP-verziók

Miért sürgős?

  • Már támadják. Az Amazon egy csapdaszerveren már október 17-én rögzített egy kihasználási kísérletet, négy nappal a bejelentés előtt. A Cloudflare a nyilvánosságra hozatal napján már támadásokat látott.
  • Szinte minden webes PHP érintett. A javítás előtti összes webes PHP-telepítés: PHP-FPM, Apache mod_php, php-cgi, LiteSpeed. A mod_php a legveszélyesebb, mert ott a támadás az alkalmazás kódja előtt lefut (Help Net Security).
  • A hatóságok is riasztottak. A magyar Nemzeti Kibervédelmi Intézet riasztást adott ki: azonnali frissítést kér, és ha ez nem lehetséges, az érintett rendszer leválasztását vagy ideiglenes leállítását. A brit NCSC is azt írja, hogy amit nem lehet gyorsan javítani, azt érdemes lekapcsolni.

A Telex beszámolója szerint Európában több állami és intézményi oldalt is óvatosságból ideiglenesen lekapcsoltak.

Melyik PHP-verzió biztonságos?

PHP-ágon vagyJavított verzióMit tegyél
8.58.5.12 vagy újabbfrissíts erre
8.48.4.27 vagy újabbfrissíts erre
8.38.3.36 vagy újabbfrissíts erre
8.28.2.35 vagy újabbfrissíts erre; a 8.2 2026. december 31-én kifut
7.4, 8.0, 8.1nincs rendes kiadáscsak forráskódos szükségjavítás van; a valódi megoldás az átállás 8.2+ verzióra
5.4 – 7.3nincs javítássürgős átállás kell

A 7.4–8.1-es ágakhoz a PHP biztonsági csapata minimális forráskód-javítást adott ki, de ezt valakinek le kell fordítania, fel kell tennie és ki kell próbálnia. Egy átlagos tárhelyen ez nem történik meg magától.

Ez a tárhely dolga, nem az enyém?

Részben. A tárhelyszolgáltató felteheti a javított PHP-t, és jó esetben meg is teszi. Itt viszont két csapda van:

  1. A régi webshop nem biztos, hogy elindul az új PHP-n. Ha a boltod évek óta nem kapott frissítést, egy régi bővítmény vagy sablon nem bírja az új verziót, és a frissítés után leállhat az oldal.
  2. Ha régi PHP-ágon vagy, nincs mire frissíteni. Ha a szolgáltató azért hagyott 7.4-en vagy 8.0-n, mert „azon megy a régi kód”, akkor ma rendes javítás nélkül futsz.

Ezért nem elég megvárni, hogy valaki megoldja: tudnod kell, hol tartasz.

Mit tegyél most? Öt lépés

1. Nézd meg, milyen PHP-n fut a webshopod.

  • WordPress és WooCommerce: a vezérlőpulton Eszközök → Webhely egészsége → Infó, a Kiszolgáló résznél ott a PHP-verzió.
  • Bármilyen oldal: a PHP Radar ingyenes ellenőrzője a domain alapján, kívülről megbecsüli a PHP-verziót. Ha a szerver elrejti a verziót, ez nem mindig ad biztos választ.
  • Tárhelyfiók: a legtöbb tárhely kezelőfelületén (cPanel, DirectAdmin, Plesk) látszik, és ott át is lehet állítani.

2. Kérdezd meg a tárhelyszolgáltatót írásban. Elég egy mondat: „Melyik PHP-verzión fut a [domain], és telepítettétek-e a 2026. október 21-i biztonsági javítást (CVE-2026-109618, CVE-2026-109619)?”

3. Frissíts, de előbb ments. Készíts teljes mentést (fájlok és adatbázis). Ha lehet, egy tesztpéldányon (staging) próbáld ki az új PHP-t, és csak utána állítsd át az éles oldalt.

4. Ha nem tudsz azonnal frissíteni, tegyél elé védelmet. A Cloudflare ingyenes csomagban is bekapcsolta a PHP2Shell elleni szabályokat. Ez csak átmeneti védőháló, és csak a Cloudflare-en átmenő forgalomra hat.

5. Nézd meg, nem történt-e már baj. Gyanús jel lehet a sok váratlan 500-as hiba, a furcsa új fájl a szerveren, vagy egy ismeretlen adminfelhasználó. Ha bármi ilyet látsz, ne csak frissíts, hanem vizsgáltasd is át az oldalt.

Rendszergazdáknak: átmeneti beállítások

Ha a frissítés néhány órát vagy napot csúszik, a PHP és a Tenable az alábbi ideiglenes beállításokat írja (Tenable):

  • CVE-2026-109618 ellen: memory_limit=-1, úgy, hogy az alkalmazás ne tudja felülírni;
  • CVE-2026-109619 ellen: session.upload_progress.enabled=0, PHP 8.5-ön fatal_error_backtraces=0 is;
  • utána minden PHP-folyamatot újra kell indítani.

Ezek csökkentik a kockázatot, de nem teszik biztonságossá a rendszert. A teljes megoldás a frissítés. Laravel Forge-felhasználók figyelmébe: a Forge automatikus biztonsági frissítései nem frissítik a PHP-t, ezt szerverenként kézzel kell elvégezni.

Idén ez a harmadik nagy eset a WordPress körül

Aki WordPressen vagy WooCommerce-en fut, annak 2026 különösen nehéz év:

  • Július – WP2Shell: két WordPress-hiba láncolásával bejelentkezés nélkül lehetett kódot futtatni. A támadások a javítás után szinte azonnal elkezdődtek.
  • Szeptember – CVE-2026-87902: a WordPress 7.1.2-ben javított, 9,2-es hiba kihasználása a bejelentés után órákon belül megindult.
  • Október – PHP2Shell: ez már nem a WordPress hibája, hanem az alatta futó PHP-é. WordPress-frissítéssel nem javítható.

Az első kettőnél még az volt a tanács, hogy frissítsd a WordPresst. Most ez nem elég, a szerver PHP-ját is frissíteni kell.

Mit írt erről Vidovics Gábor?

Kollégánk, Vidovics Gábor weboldal-biztonsággal foglalkozik. A hiba másnapján cikket írt róla a LinkedInen. A fő üzenete: a régi kódú oldalaknál két rossz közül kell választani. Vagy frissül a PHP, és leállhat az oldal, vagy nem frissül, és nyitva marad. Ezért kell valaki, aki átviszi a kódot az új verzióra.

Gyakori kérdések

Mi az a PHP2Shell? Két kritikus PHP-sebezhetőség (CVE-2026-109618 és CVE-2026-109619) közös neve. Bejelentkezés nélküli, távoli kódfuttatást tesznek lehetővé a PHP-t futtató webszervereken. A javítás 2026. október 21-én jelent meg.

Érinti a WooCommerce-webshopomat? Igen, ha a szervered javítás előtti PHP-verziót futtat. A WooCommerce és a WordPress PHP-n fut, a hiba pedig magában a PHP-ban van, így a bővítmények és a sablon frissítése nem védi ki.

Shoprenter vagy UNAS boltom van. Nekem kell tennem valamit? Ezeknél a zárt platformoknál a szervert a szolgáltató üzemelteti. Nézd meg, kiadott-e közleményt, vagy kérdezz rá írásban, hogy a te boltod szerverei frissültek-e.

Elég, ha frissítem a WordPresst? Nem. A PHP2Shell a WordPress alatti PHP-ban van. A szerver PHP-verzióját kell frissíteni.

Honnan tudom, hogy már feltörték-e az oldalamat? Egy külső ellenőrzés ezt nem tudja biztosan megmondani. Ha furcsa fájlokat, ismeretlen felhasználót vagy sok váratlan hibát látsz, vizsgáltasd át az oldalt szakemberrel.

Segítünk

Ha nem tudod, milyen PHP-n fut a webshopod, vagy félsz, hogy a frissítés után leáll, írj a hello@wednesday.agency címre, a tárgyba elég a domained és annyi: „PHP2Shell”. Megnézzük, hol tartasz, és megmondjuk, mi a következő lépés. Az első gyors ellenőrzéshez használd a PHP Radart.

Források

Minden forrást 2026. október 22-én ellenőriztünk.

A cikk elkészítését mesterséges intelligencia (AI) is segítette.