PHP2Shell: kritikus hiba a PHP-ban, mindenkinek frissítenie kell

A biztonsági hírekre általában könnyű legyinteni, hiszen hetente érkezik egy újabb “kritikus” sérülékenység, amiből a végén többnyire semmi sem lesz. A tegnapi, október 21-i PHP-s biztonsági kiadás szerintem viszont tényleg más kategória, hiszen nem egy pluginról vagy egy CMS-ről van szó, hanem magáról a nyelvről, amin az internet jelentős része fut. Hogy mennyire kell ezt komolyan venni, és mit kell most azonnal megnéznünk? Erre próbálok választ adni.

Mi történt?

A PHP csapata tegnap kiadta a 8.5.12, 8.4.27, 8.3.36 és 8.2.35-ös verziókat, melyek két súlyos hibát javítanak: a CVE-2026-109618-at és a CVE-2026-109619-et. Az előbbinél a PHP memóriafogyás (OOM) közben szakadhat meg úgy, hogy a kérés adatai csak félig vannak inicializálva, a takarítás pedig ezt az érvénytelen állapotot érvényesnek hiszi. Az egyik kiváltó tényező a multipart (azaz feltöltéses) kérések feldolgozása. A másiknál a kérés állapota a memória felszabadítása után is életben marad, és a következő, ugyanazon a workeren futó kérés használhatja azt. Ez utóbbinál a megerősített útvonal a munkamenet-feltöltés előrehaladását követő funkció, ami ráadásul alapból be van kapcsolva.

A két hibát együtt PHP2Shell néven emlegetik. A név nem a PHP-tól jön, hanem egy kiszivárgott képernyőfotón látható exploit-eszközről terjedt el. Megtalálását a Calif a saját közlése szerint az OpenAI-jal és a Wizzel közösen érte el, a PHP bejelentése viszont egyetlen felfedezőt sem nevez meg.

Mennyire súlyos?

Ez az a kérdés, amire egyszerűen nem lehet legyinteni. A PHP mindkettőt 9.2-es (CVSS v4.0), az NVD pedig 9.8-as (CVSS 3.1) pontszámmal látta el, és a PHP csapata megerősítette, hogy bejelentkezés nélkül, távolról is lehetséges kódfuttatás. A legrosszabb a helyzet Apache mod_php esetén, ahol a támadás még azelőtt lefut, hogy az alkalmazásunk egyetlen sora is elindulna, tehát se a CMS, se a biztonsági pluginunk nem tud közbeavatkozni. A PHP-FPM-nél ez nehezebb, mert ott az alkalmazás működésétől is függ, a CVE-2026-109618-hoz pedig a PHP egyik csapattagja szerint teljes FPM-es támadást még nem mutattak be. A kutatók ugyanakkor WordPress, Drupal és Joomla ellen is demonstráltak hitelesítés nélküli kódfuttatást, és szerintük egy “Hello World” alkalmazás is érintett lehet.

Támadják már?

Erről megoszlanak a vélemények, és ez szerintem részben természetes, hiszen alig egy napja nyilvános az egész. A Cloudflare, a watchTowr és a Hadrian támadási próbálkozásokról számol be, az Amazon pedig már október 17-i, azaz a bejelentést megelőző kísérletet is látott (hogy ezek sikeresek lettek volna-e, azt ők sem tudják). Ezzel szemben a CISA a jelentések szerint még nem látott kihasználást, és egyik hiba sem szerepelt az ismert kihasznált sérülékenységek listáján. A CERT-EU szerint viszont már keringenek az első PoC-k. Én ezek alapján nem várnék a megerősítésre.

Kiket érint?

Gyakorlatilag mindenkit, aki a PHP-t webes kérések kiszolgálására használja (mod_php, PHP-FPM, php-cgi, FrankenPHP, LiteSpeed). A rosszabb hír, hogy a PHP 8.1-es és régebbi ágakra nem adott ki hivatalos javítást. A 7.4-hez, 8.0-hoz és 8.1-hez csak forráskód-visszaportok léteznek, bináris nélkül, a kutatók szerint pedig akár az 5.4-ig visszamenőleg is érintett lehet a kód. A mysites.guru mérései alapján a megfigyelt oldalak 22,7%-a fut ilyen elavult ágon, a Joomlásoknál ez 23,9%, a WordPressesek között 18,0% (október 20-i adat). Ez elég sok ahhoz, hogy valahol a környezetünkben is legyen ilyen.

Mit tegyünk?

Első lépésben frissítsünk, majd (és ezt szinte mindenki elfelejti) indítsuk újra az Apache-ot, a PHP-FPM-et és minden hosszan futó workert, hiszen a frissítés önmagában nem elég. Ellenőrizzük azt a PHP-verziót is, amelyik ténylegesen kiszolgálja az oldalt, mert a parancssori php -v eltérhet ettől. A disztribúciós csomagok verziószáma pedig nem mindig változik a javítással, ezért érdemes a disztribúció saját biztonsági közleményét is megnézni.

Ha azonnal nem tudunk frissíteni, a PHP átmeneti beállításokat javasol: session.upload_progress.enabled=0, memory_limit=-1 és szigorú kérésméret-korlát, PHP 8.5-nél pedig fatal_error_backtraces=0. A csapat viszont maga is hangsúlyozza, hogy ezek nem teszik biztonságossá a rendszert. Ha pedig a CVE-2026-109619 miatt memóriatartalom is kiszivároghatott, akkor a PHP-alkalmazásokban tárolt jelszavak és kulcsok cseréje sem túlzás, plusz érdemes visszamenőleg október 17-től átnézni a naplókat.

Összegzés

Őszintén szólva egy ilyen hiba mellett nagyon könnyű pánikolni, de szerintem itt nem a pánik a megoldás, hanem a gyors, módszeres cselekvés. Frissítsünk, indítsuk újra a workereket, nézzük át a naplókat, és aki 8.1-es vagy régebbi PHP-n fut, az most végre tegye meg azt a váltást, amit egy ideje halogat. A 8.2-es ág támogatása ráadásul év végén lejár, tehát jobb, ha rögtön a 8.4 vagy 8.5 irányába indulunk.