# 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.

Source: https://www.iz-labs.com/hu/insights/php2shell-teendok-wordpress-webshop

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](/hu/php2shell). 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?

2026. 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:

1. **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.
2. **WordPress admin:** az Eszközök menü Site Health oldalán, az Info fülön, a Szerver szakaszban szerepel a PHP-verzió.
3. **Parancssor:** a szerveren a `php -v` parancs 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](/hu/php2shell#check) — 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:

1. **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.
2. **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.
3. **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.
4. **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](/hu/php2shell#check), vagy [kérjen javítást](/hu/contact?need=security) — még aznap válaszolunk.