PHP2Shell: mit kell most tennie egy magyar cégnek? Útmutató WordPress- és webshoptulajdonosoknak
Kritikus PHP-hiba (CVE-2026-109618, CVE-2026-109619): így deríti ki, érintett-e a weboldala, kinek a dolga a javítás, és mit kérjen a tárhelyszolgáltatótól.
Islam Zoukhaiev··4 perc olvasás
Ha a cége weboldala vagy webshopja saját tárhelyen, PHP-n fut (WordPress, WooCommerce, Drupal, Joomla, Magento, PrestaShop, Laravel), akkor most ellenőriznie kell a PHP-verziót. A PHP2Shell néven ismert két hiba (CVE-2026-109618 és CVE-2026-109619) miatt egy támadó bejelentkezés nélkül futtathat kódot a szerveren. A javítás 2026. október 21. óta elérhető: a PHP 8.5.12, 8.4.27, 8.3.36 és 8.2.35 már védett. Ha bérelt webshopplatformot (Shoprenter, Unas, Shopify) használ, a javítás a szolgáltató dolga.
Az oldalunkon ingyen ellenőrizheti, érintett-e a weboldala. Ez az útmutató azt mutatja meg, mit tegyen a nem technikai cégvezető, lépésről lépésre.
Mi történt pontosan?
- október 21-én a PHP — a világ weboldalainak nagyjából 70%-át kiszolgáló programozási nyelv — rendkívüli biztonsági frissítést adott ki két kritikus hibára. A hibák a PHP memóriakezelésében vannak, abban, ahogyan a végzetes hibákat (főleg a memória elfogyását) kezeli. A felfedező kutatók (Calif, Wiz és mások) a WordPress, a Drupal, a Joomla és a Magento friss verzióin is bemutatták, hogy bejelentkezés nélkül átvehető a szerver.
Néhány fontos tény:
- Súlyosság: kritikus, CVSS 9.2 pont mindkét hibára.
- Érintett verziók: a PHP 5.4-től kezdve gyakorlatilag minden verzió, ami az elmúlt tíz évben megjelent.
- Érintett futtatási módok: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, LiteSpeed — vagyis minden PHP, ami weboldalt szolgál ki.
- Kihasználás: a részletek a tervezett közzététel előtt kiszivárogtak; a Cloudflare és a watchTowr támadási kísérleteket jelentett.
- Memóriaszivárgás: a hiba kódfuttatás nélkül is kiolvashat jelszavakat, API-kulcsokat és munkamenet-azonosítókat a szerver memóriájából.
Érintett az én weboldalam?
Az egyszerű válasz: ha a weboldala PHP-n fut, és a PHP-verzió régebbi a javítottnál, igen. A WordPress vagy a bővítmények verziója ebből a szempontból nem számít, mert a hiba magában a PHP-ban van.
| Az Ön helyzete | Érintett? | Kinek a dolga a javítás? |
|---|---|---|
| WordPress / WooCommerce megosztott tárhelyen | Valószínűleg igen | A szolgáltató frissíti a PHP-t, de a verziót gyakran Ön választja ki |
| Saját VPS vagy szerver (bármilyen PHP-alkalmazás) | Igen, ha nincs frissítve | Az Öné vagy a fejlesztőé |
| Ügynökség által üzemeltetett oldal | Igen, ha nincs frissítve | Az ügynökségé — de kérdezzen rá |
| Shoprenter, Unas, Shopify, Wix | A platform szerverei igen, de… | …a szolgáltató javítja; Önnek nincs teendője a PHP-val |
| Statikus oldal, Next.js, Astro (PHP nélkül) | Nem | — |
Hogyan nézhetem meg a PHP-verziót?
Három egyszerű módszer, a legkönnyebbtől a legtechnikaibbig:
- Tárhely vezérlőpult: a cPanelben jellemzően a „Select PHP Version” vagy „MultiPHP Manager” menüpont alatt, más vezérlőpultokon a PHP-beállításoknál látja, melyik verziót használja az oldala.
- WordPress admin: az Eszközök menü Site Health oldalán, az Info fülön, a Szerver szakaszban szerepel a PHP-verzió.
- Parancssor: a szerveren a
php -vparancs mutatja. Figyelem: ez a parancssori PHP verziója, ami eltérhet attól, amelyik a weboldalt kiszolgálja.
Ha megvan a szám, írja be az ellenőrző eszközünkbe — azonnal megmondja, javított-e.
Egy fontos kivétel: ha a szerver Ubuntu, Debian vagy Red Hat csomagból futtatja a PHP-t, a verziószám nem változik a javítással (például 8.1.2-1ubuntu2.x). Ilyenkor azt kell megnézni, hogy a disztribúció biztonsági frissítése telepítve van-e.
Mi a teendő, ha sebezhető?
A sorrend:
- Frissítés. A támogatott ágakon (8.2–8.5) frissítsen az ág javított kiadására. Ez a hivatalos álláspont szerint az egyetlen teljes megoldás.
- Régi PHP esetén átállás. A PHP 8.1 és a régebbi verziók nem kapnak hivatalos javítást. Át kell állni PHP 8.3-ra vagy 8.4-re. Régi WordPress-bővítményeknél és egyedi kódnál ez tesztelést igényel, mert egyes bővítmények nem működnek az újabb PHP-n.
- Minden példány. Ne csak az éles oldalt nézze: tesztoldalak, régi aldomainek, elfelejtett blogok és admin felületek is futhatnak régi PHP-n.
- Utóellenőrzés. Ha az oldal a javítás előtt sebezhető volt, nézze át (vagy nézesse át) a naplókat, ellenőrizze az adminfelhasználókat, és cserélje le a jelszavakat és az API-kulcsokat.
Mit kérdezzen a tárhelyszolgáltatótól vagy a fejlesztőtől?
Ha nem Ön kezeli a szervert, küldje el ezt a rövid levelet. Bemásolhatja:
Tárgy: PHP2Shell (CVE-2026-109618, CVE-2026-109619) — javítás állapota
Jó napot! Szeretném megtudni, hogy a [domain] oldalt kiszolgáló szerveren telepítve van-e a PHP 2026. október 21-i biztonsági javítása (8.5.12 / 8.4.27 / 8.3.36 / 8.2.35, vagy a disztribúció javított csomagja). Melyik PHP-verziót használja az oldal a webes környezetben? Ha 8.1 vagy régebbi, mi a terv az átállásra? Kérem, jelezzék azt is, ha a javítás előtt gyanús tevékenységet láttak a naplókban. Köszönöm!
Ha erre nem kap egyértelmű választ egy munkanapon belül, az önmagában is jelzés.
Elég a Cloudflare vagy egy biztonsági bővítmény?
Nem. A Cloudflare az ingyenes csomagban is bevezetett szabályokat az ismert támadási mintákra, de ez csak ideiglenes védelem, és csak akkor ér valamit, ha a szerver kizárólag a Cloudflare felől fogad forgalmat. A WordPress biztonsági bővítményei sem segítenek, mert a hiba azelőtt jelentkezik, hogy a WordPress egyáltalán elindulna. Ugyanezért a karbantartási mód sem véd. Ismeretlen forrásból származó „javító” bővítményt vagy kódrészletet pedig semmiképp ne telepítsen.
Mit jelent ez adatvédelmi szempontból?
Ha a szerverről személyes adatok (vevők neve, e-mail-címe, rendelései) kerülhettek illetéktelen kézbe, a GDPR szerint ezt általában 72 órán belül be kell jelenteni a NAIH-nak, és bizonyos esetekben az érintetteket is értesíteni kell. Egy időben elvégzett frissítés és egy dokumentált utóellenőrzés sokkal olcsóbb, mint egy adatvédelmi incidens kezelése.
Hogyan segít az IZ Labs?
Az IZ Labs budapesti technológiai partner. A PHP2Shell-javítást fix áron vállaljuk, amelyet a munka előtt egyeztetünk: felmérjük az összes PHP-példányt, frissítünk vagy átállunk támogatott verzióra (a bővítmények tesztelésével), ideiglenes védelmet állítunk be, ha a frissítés nem lehet azonnali, átnézzük a naplókat, lecseréljük a kulcsokat, és írásos jelentést adunk. Partnereinknél — a havi technológiai partnerség havi nettó 1,1 millió Ft-tól indul — a biztonsági frissítések a havidíj részei.
Ellenőrizze ingyen a weboldalát, vagy kérjen javítást — még aznap válaszolunk.