PHP2Shell: A kritikus PHP-hibák a mod_php-szervereket érintik a legsúlyosabban

A PHP október 21-én, szerdán 14:00 UTC-re hozta előre biztonsági frissítésének kiadását, miután egy nappal korábban két sérülékenység részletei szivárogtak ki a Hacker News oldalán. A javításokat a PHP 8.5.12, 8.4.27, 8.3.36 és 8.2.35 verziói tartalmazzák. Mindkét hiba magában az értelmezőben található, nem pedig egy CMS-ben. A PHP CVE-2026-109618 és CVE-2026-109619 sérülékenységekről szóló biztonsági közleményei mindkettőt 9,2 pontra értékelik a CVSS 4.0 szerint, és megerősítik, hogy hitelesítés nélküli távoli kódfuttatást tesznek lehetővé a webes munkafolyamat jogosultságaival.

A memóriahiány kezelése félig inicializált állapotban hagyja a memóriát

Az első sérülékenység abból ered, ahogyan a PHP a memóriahiányos hibákat kezeli. Memóriahiány (OOM) esetén az értelmező a longjmp() segítségével lép ki az aktuális környezetből, még akkor is, ha a kéréshez tartozó memória abban a pillanatban csak részben van inicializálva. A leállítási eljárás ezután érvényesként olvassa be ezt az állapotot. A támadó egy post_max_size alatt maradó multipart kéréssel idézhet elő memóriahiányt, például részenként korlátlan számú fejléccel, a max_file_uploads korlátba bele nem számító üres fájlmezőkkel vagy egymásba ágyazott mezőnevekkel. A javítás a longjmp() helyett a következő biztonságos VM-ponton kezelt memóriahiányt, egy második, magasabb küszöbérték felett pedig azonnali _exit() hívást alkalmaz.

A második sérülékenység a kérésen túl is fennmaradó globális állapothoz kapcsolódik. Ha egy végzetes hiba megszakít egy műveletet, mielőtt az alaphelyzetbe állítaná az állapotát, egy globális mező továbbra is a halommemória egy felszabadított területére mutat. Amikor ugyanazon a munkafolyamaton a következő kérés a szokásos inicializálás előtt kiolvassa ezt az értéket, felszabadítás utáni memóriahasználat történik. A PHP két megerősített kiváltási módot sorol fel: a PHP 8.5 fatal_error_backtraces beállítását és a munkamenethez kapcsolódó feltöltési folyamatkövetést, amely alapértelmezés szerint engedélyezett, és nem igényli, hogy az alkalmazás meghívja a session_start() függvényt.

Miért a mod_php a leginkább veszélyeztetett?

A mod_php-t használó Apache akkor is meghívja a kérés leállítási eljárását, ha a kérés indítása már meghiúsult. Ehhez elegendő, ha a PHP a kéréstörzs feldolgozása közben kifogy a memóriából, és semmilyen alkalmazáskódnak nem kell lefutnia. A PHP alapértelmezett memória- és bemeneti korlátok mellett igazolta a teljes körű kódfuttatást mod_php-n. A PHP-FPM leállítja azt a gyermekfolyamatot, amelynek indítása meghiúsul, ami megakadályozza a közvetlen kihasználási módot. A második sérülékenység esetében a PHP egy szokásos FPM-folyamatkészlet ellen is megerősítette a kihasználhatóságot, bár ehhez megfelelő műveletre van szükség az alkalmazásban. A forráskód elemzése alapján a FrankenPHP a mod_php-hoz hasonlóan viselkedik, míg az LSAPI bizonyos feltételek mellett lehet érintett. A CVSS-vektorban szereplő magas támadási összetettség azt tükrözi, hogy a PHP fordítási konfigurációja és a halommemória elrendezése befolyásolja a kihasználás megbízhatóságát.

Kihasználási kísérletek és az AI szerepe

A watchTowr közlése szerint mindkét sérülékenység ellen aktív kihasználási kísérleteket észlel, a Cloudflare pedig azt nyilatkozta a The Hacker News számára, hogy már a javítás kiadása előtt is látott korai támadásokat. Sikeres behatolást eddig nem erősítettek meg. A holland kormányzati szolgáltatásokat, köztük a DigiD-t és a MijnOverheidot ennek ellenére elővigyázatosságból leállították, az Egyesült Királyság NCSC-je pedig azt tanácsolja, hogy ha nincs más lehetőség, válasszák le a hálózatról a javítatlan rendszereket.

A Wiz Research fedezte fel a hibákat, és augusztus 24-én jelentette őket. A Wiz szerint a Gemini 4 Argon és a GPT-5.6 Sol segített a felfedezésben, a kihasználó kód fejlesztésében és a javítás ellenőrzésében, különösen a kihasználó kód egyes célpontokhoz való finomhangolásában. A Wiz az OpenAI és a Calif felfedezéshez és koordinációhoz nyújtott segítségét is elismeri. Ez összhangban van azzal, amit az Anthropic nemrég írt az olcsó tévéokosítókat célzó, önmagát másoló AI-ról, ahol a modellek szintén megkönnyítik a támadások végrehajtását.

Mit tegyenek most a rendszergazdák?

Az egyetlen teljes körű megoldás a frissítés. A Linux-disztribúciók és az LTS-szállítók előzetesen megkapták a javításokat, és gyakran régebbi verziószámok alatt is visszaportolják őket, ezért a verziószám helyett a CVE-azonosítókat keresse a változásnaplóban. A már nem támogatott 7.4-es, 8.0-s és 8.1-es ágak csak minimális, forráskódszintű visszaportolásokat kapnak. Ha nem tud azonnal frissíteni, a PHP azt javasolja, hogy rendszergazdai szinten állítsa be a memory_limit=-1 értéket, mert a megerősített OOM-kihasználást a kérésenkénti kiszámítható korlát teszi lehetővé. Állítsa be a session.upload_progress.enabled=0 értéket, PHP 8.5 esetén pedig a fatal_error_backtraces=0 értéket is, majd indítsa újra az összes munkafolyamatot. Ha az alkalmazás nem használ multipart űrlapokat, tiltsa le őket az előtétrétegben. E beállítások egyike sem jelent teljes körű megoldást. Megosztott tárhely vagy webszervert futtató NAS esetén ellenőrizze, hogy a szolgáltató melyik PHP-verziót biztosítja.