PHP2Shell: kritikus PHP-sérülékenységek és a teendők

Mi a PHP2Shell?

A PHP2Shell elnevezés a PHP magjában felfedezett két, egymással rokon memóriabiztonsági sérülékenységet fogja össze. A hibákat CVE-2026-109618 és CVE-2026-109619 azonosítja. A PHP projekt 2026. október 21-én adott ki hozzájuk biztonsági frissítést.

A hiba a futtatókörnyezetben található: WordPress, Laravel vagy egyedi PHP-alkalmazás alatt is ugyanaz a sérülékeny PHP dolgozhat. Egy naprakész CMS sem teszi biztonságossá a régi PHP-t. A nyilvános webes kéréseket feldolgozó telepítéseket kell először felmérni.

Mi történik a PHP-ban?

A CVE-2026-109618 esetén a memóriahiány kezelése megszakíthatja a kérés feldolgozását, miközben belső adatok még csak részben inicializáltak. A későbbi takarítás ezeket érvényes adatként kezelheti. A CVE-2026-109619 esetén egy kéréshez tartozó globális állapot a memória felszabadítása után is fennmaradhat; egy későbbi kérés ugyanabban a workerben ezt az elavult állapotot használhatja.

A PHP hivatalos közleménye mindkettőnél hitelesítés nélküli távoli kódfuttatás lehetőségére figyelmeztet. Apache mod_php esetén a kockázatot különösen magasnak értékeli: bemutatott támadási útvonalon a hiba az alkalmazáskód futása előtt kiváltható. Más webes SAPI-k, köztük PHP-FPM, php-cgi, FrankenPHP és LiteSpeed is érintettek. A technikai részletek környezetfüggők; az érintettséget nem szabad egyetlen nyilvános proof of concept működéséből megítélni.

Milyen következménye lehet?

Sikeres kódfuttatás esetén a támadó a PHP worker jogosultságával férhet hozzá fájlokhoz, konfigurációhoz és az alkalmazás által elérhető rendszerekhez. Ez weboldal módosításához, adatok és titkok megszerzéséhez, rosszindulatú kód elhelyezéséhez vagy szolgáltatáskimaradáshoz vezethet. A pontos hatás a worker jogosultságaitól és a környezet elkülönítésétől függ.

A memóriával kapcsolatos hibák érzékeny folyamatadatok kiszivárgásának kockázatát is felvetik. Nem állítjuk, hogy minden érintett szerveren történt támadás: az érintettség és a bizonyított kompromittálódás külön kérdés. Ha gyanús jelet találsz, incidensként kezeld, és őrizd meg a naplókat.

Érintett és javított PHP-verziók

A PHP projekt első javított kiadásai az alábbiak. Disztribúciós vagy szolgáltatói csomagnál előfordulhat, hogy a javítást régebbi verziószámba portolták vissza; ilyenkor a csomag biztonsági közleményét és buildazonosítóját kell ellenőrizni. A PHP 8.1 és régebbi ágak a PHP projekt szokásos támogatásából már kikerültek.

Hogyan védekezz és ellenőrizd a javítást?

Készíts leltárt minden webes PHP-környezetről: domainek, aldomainok, PHP-FPM poolok, Apache-modulok, konténerek, cron által indított külön PHP és vezérlőpanelek saját futtatói. A parancssori `php -v` csak a CLI-binárist mutatja; a weboldalt kiszolgáló verzió külön is ellenőrzendő.

Telepítsd a PHP projekt vagy a disztribúció javított csomagját. Frissítsd a konténerképeket is, majd cseréld le a futó példányokat és indítsd újra az összes érintett workert. Plesk esetén a webhelyek PHP-kezelőjén túl a Plesk saját PHP-motorjának verzióját is ellenőrizd. A frissítés után teszteld az oldalakat és rögzítsd a webes futtató valódi verzióját.

• Ellenőrizd a szolgáltató közleményében mindkét CVE javítását, ha visszaportolt csomagot használsz.
• Vizsgáld meg a hibák, worker-összeomlások és szokatlan kimenő kapcsolatok naplóit; a naplóhiány nem bizonyítja, hogy nem történt támadás.
• Gyanús aktivitásnál különítsd el az érintett példányt, őrizd meg a bizonyítékokat, és a hozzáférések/titkok cseréjét a vizsgálat alapján végezd.
• A konkrét, lépésenkénti ellenőrzőlista a kapcsolódó tudásbázis-cikkben található.

Mi van, ha most nem frissíthető?

A PHP biztonsági csapata szerint nincs teljes értékű konfigurációs kerülőmegoldás: a frissítés az egyetlen teljes javítás. A hivatalos közlemény több részleges kockázatcsökkentő beállítást ír le, például a session upload progress kikapcsolását és a kérések méretének korlátozását. Ezeket csak dokumentált, rövid átmeneti lépésként alkalmazd, mert a másik támadási út vagy egy eltérő variáns továbbra is fennmaradhat.

A `memory_limit=-1` például megszüntet egy vezérelhető PHP memóriahatár-elérést, de erőforrás-kimerülést okozhat, és nem javítja ki a mögöttes hibát. A WAF és a CMS-frissítés önmagában sem helyettesíti a javított PHP-t. Ha nincs ellenőrizhető javítás, mérlegeld az érintett webes PHP-szolgáltatás ideiglenes korlátozását vagy leállítását.

Gyakori kérdések

WordPress-oldalt használok: elég a WordPress frissítése? Nem. A PHP-futtatót is frissíteni kell; a WordPress frissítése külön, továbbra is fontos karbantartási feladat.

Elég a `php -v` kimenete? Nem feltétlenül. A CLI és a webszerver eltérő binárist, pool-t vagy konténert használhat.

A sitemap vagy egy SEO-eszköz jelzi az érintettséget? Nem. Az érintettség üzemeltetési kérdés, amit a tényleges PHP-futtató és a gyártói javítás ellenőrzésével lehet megállapítani.