A PHP fejlesztői október 21-én négy kiadási ághoz adtak ki sürgősségi frissítést. A PHP2Shell néven összefoglalt két memóriakezelési hiba, a CVE-2026-109618 és a CVE-2026-109619 bizonyos környezetekben lehetővé teszi, hogy egy távoli támadó bejelentkezés nélkül kódot futtasson a webszerveren. Apache mod_php alatt olyan támadást is bemutattak, amelyhez az alkalmazás saját kódjának el sem kell indulnia. A PHP projekt biztonsági közleménye
A figyelmeztetés minden webes kéréseket kiszolgáló PHP-telepítésre vonatkozik, köztük a PHP-FPM, az Apache mod_php, a php-cgi, a FrankenPHP és a LiteSpeed környezetekre. Ez nem jelenti azt, hogy mindkét hibát mindegyik környezetben azonos módon ki lehet használni. A fejlesztők a legnagyobb kockázatot a mod_php esetében látják, de minden érintett üzemeltetőt azonnali frissítésre kérnek.
Az első figyelmeztetések óta két kérdés tisztázódott: elérhetők a javítások, és ismertek azok a hibák is, amelyek miatt a beállítások módosítása nem ad teljes védelmet. Az üzemeltetők feladata most annak megállapítása, hogy ki frissíti az egyes PHP-telepítéseket, és ténylegesen melyik csomag szolgálja ki a webes kéréseket.
Mely PHP-verziók tartalmazzák mindkét javítást?
| PHP-ág | A két PHP2Shell-hibát javító első hivatalos kiadás |
|---|---|
| PHP 8.2 | 8.2.35 |
| PHP 8.3 | 8.3.36 |
| PHP 8.4 | 8.4.27 |
| PHP 8.5 | 8.5.12 |
A megfelelő kiadás vagy olyan szállítói csomag telepítendő, amelynek biztonsági közleménye mindkét CVE javítását igazolja. A PHP projekt előzetesen átadta a javításokat a Linux-disztribúciók és a hosszú távú támogatást nyújtó szolgáltatók részére. Ha egy disztribúció korábbi verziószámú csomagba ültette át a módosításokat, a saját biztonsági közleménye és a telepített csomag teljes kiadási azonosítója alapján ellenőrizhető a védelem. A PHP letöltési oldala · A holland NCSC verzióösszesítője
Egy szervezeten belül több gazdája is lehet a feladatnak. A nyilvános webhely mögötti PHP-t kezelheti a tárhelyszolgáltató, a konténerképeket karbantarthatja a belső infrastruktúra-csapat, egy üzleti alkalmazásba csomagolt PHP-példány frissítését pedig a szoftver szállítója végezheti. A WordPress, egy bővítmény vagy más webalkalmazás sikeres frissítése egyik esetben sem igazolja önmagában a PHP javítását.
A javítások előtt kerültek nyilvánosságra az első részletek
A Huntress beszámolója szerint a hibákról október 20-án, az összehangolt közzététel és a javítócsomagok megjelenése előtt szivárgott ki információ. A védekezők így már tudtak a lehetséges távoli kódfuttatásról, de még nem rendelkeztek az egyes telepítések megítéléséhez szükséges műszaki részletekkel. A Huntress időrendi beszámolója
A CERT-EU korai figyelmeztetése mindkét hibához 9,2-es súlyossági pontszámot közölt, és az azonnali javítás előkészítését javasolta. Az internet felől elérhető, gyorsan nem frissíthető alkalmazásoknál az elkülönítést is megfontolásra ajánlotta. A műszaki részletek akkori hiánya az október 21-i kiadás előtti állapotot tükrözte. A PHP fejlesztői azóta külön közleményben ismertették a két hibát, a kipróbált támadási útvonalakat és azok korlátait. A PHP projekt közleményeire mutató operatív összefoglaló
Első hiba: a memóriafoglalás meghiúsulása kódfuttatáshoz vezethet
A CVE-2026-109618 akkor idézhet elő veszélyes állapotot, ha a PHP memóriafoglalás közben hibába ütközik. A feldolgozás olyan pillanatban szakadhat meg, amikor az aktuális kérés belső adatszerkezetei még csak részben épültek fel. A kérés lezárásakor a PHP ezután úgy kezelheti a hiányosan előkészített adatokat, mintha azok érvényesek lennének. A PHP részletes közleménye a CVE-2026-109618 hibáról
Apache mod_php alatt a kéréshez tartozó erőforrások felszabadítása akkor is lefuthat, ha a kérés inicializálása meghiúsult. A bemutatott támadás így már azelőtt elérte a sérülékeny kódrészletet, hogy a webalkalmazás saját ellenőrzései működésbe léphettek volna.
PHP-FPM alatt ugyanilyen indítási hiba esetén a rendszer leállítja az érintett kiszolgálófolyamatot. Ha azonban a memória a sikeres inicializálás után fogy el, a sérülékeny állapot továbbra is kialakulhat. A fejlesztők ezt a forráskód elemzése alapján állapították meg; ehhez az első hibához nem mutattak be teljes, működő PHP-FPM-es támadást.
A javítás megakadályozza, hogy a PHP a memória elfogyása után érvényesként dolgozza fel a félkész kérés adatait. A PHP saját memóriakorlátjának kikapcsolása csak a hiba egyik kiváltó okát szünteti meg: az alapul szolgáló memóriafoglalás ettől még meghiúsulhat. Ezért a memóriakorlát módosítása nem helyettesíti a frissítést.
Második hiba: az egyik kérésből visszamaradt hivatkozás veszélyeztetheti a következőt
A CVE-2026-109619 az egymás után több kérést kezelő PHP-folyamatokat érinti. Egy kérés befejezésekor a PHP felszabadíthat egy memóriaterületet úgy, hogy a kiszolgálófolyamatban megmarad egy arra mutató hivatkozás. Ha ugyanaz a folyamat újabb kérést kap, még azelőtt felhasználhatja a régi hivatkozást, hogy az inicializálás visszaállítaná a megfelelő állapotot. Ezt nevezik felszabadítás utáni memóriahasználatnak (use-after-free). A PHP részletes közleménye a CVE-2026-109619 hibáról
A fejlesztők PHP 8.5-ön, mod_php alatt igazolták a távoli kódfuttatást a végzetes hibákhoz készített hívási verem feldolgozásán keresztül. A munkamenetek kezeléséhez kapcsolódó útvonalat pedig mod_php és PHP-FPM alatt is igazolták. Az FPM-es változathoz az alkalmazásnak is végre kell hajtania egy megfelelő műveletet. Az első hibánál hiányzó FPM-es demonstráció tehát nem jelent védelmet a második hibával szemben.
Az igazolt következmények közé tartozik a memória tartalmának kiolvasása és a kódfuttatás a webes kérést kezelő folyamat jogosultságaival. Ha ez a folyamat olvashatja az alkalmazás konfigurációját vagy adatbázis-jelszavait, illetve írhatja a webhely fájljait, a támadó ezekhez is hozzáférhet. A további lehetőségeket a jogosultságok, a szolgáltatások elkülönítése és a hálózati elérés határozza meg. A kódfuttatásból nem következik automatikusan rendszergazdai hozzáférés a teljes kiszolgálóhoz.
Mit érnek az átmeneti beállítások?
A PHP projekt álláspontja szerint a két eredeti sérülékenységre a javított futtatókörnyezet telepítése ad teljes megoldást. A fejlesztők kivételesen a PHP 7.4, 8.0 és 8.1 ágakhoz is közzétettek korlátozott terjedelmű, forráskódszintű javításokat azok számára, akik nem jutnak megfelelő szállítói csomaghoz. Ez nem indította újra e verziók hivatalos biztonsági támogatását. A PHP projekt frissítési útmutatója
A második hibánál a fájlfeltöltés előrehaladásának munkamenetben történő követését a session.upload_progress.enabled=0 beállítással lehet kikapcsolni. PHP 8.5 alatt a fatal_error_backtraces=0 letiltja a végzetes hibákhoz készített hívási verem rögzítését. Ezek külön-külön az adott funkcióhoz kötődő, igazolt támadási útvonalat zárják le. A kiszolgálófolyamatokat az átállítás után újra kell indítani. A hibaüzenetek megjelenítésének elrejtése nem javítja a memóriakezelést. A PHP technikai útmutatója
Későbbi pontosítás: a PHP projekt október 23-án egy külön hibára, a CVE-2026-115560 azonosítójú problémára is felhívta a figyelmet. Ehhez szokatlan feltételnek kell teljesülnie: az alkalmazás futás közben, a munkamenet indítása előtt meghatározott módon átváltja a munkamenetadatok tárolási formátumát, miközben a feltöltéskövetés engedélyezett. Az ilyen alkalmazásoknál a fejlesztők a feltöltéskövetés kikapcsolását javasolták a következő rendes hibajavító kiadásig. Ahol az alkalmazás futás közben nem vált formátumot, e külön hiba miatt nem szükséges letiltani a funkciót. A PHP projekt október 23-i tájékoztatója
Ha egy internet felől elérhető szolgáltatás nem frissíthető azonnal, érdemes mérlegelni a hozzáférés szűkítését, a szolgáltatás elkülönítését vagy az érintett nyilvános funkció átmeneti felfüggesztését. Minden ideiglenes intézkedéshez legyen felelős és konkrét javítási határidő, hogy a kerülőmegoldás ne váljon tartós kivétellé.
Mit lehet tudni a tényleges kihasználásról?
A Huntress az október 21-i helyzetjelentésében még azt írta, hogy saját partneri környezetében addig nem észlelt kihasználást. Ez egy adott időpontra és a vállalat megfigyelési körére vonatkozó állítás volt. A Huntress helyzetjelentése
Október 26-án az amerikai CISA mindkét hibát felvette az ismerten kihasznált sérülékenységek katalógusába. Az F5 Labs az internetes felderítések és kihasználási kísérletek gyors növekedését is megfigyelte; az általuk látott forgalom nagyobb része a CVE-2026-109619 hibát célozta. A korai észlelési adatok tehát már nem írják le a későbbi helyzetet. A CISA katalógusa · Az F5 Labs megfigyelései
A katalógusba kerülés a frissítés sürgősségét támasztja alá. A támadási kísérletek száma azonban nem azonos a sikeresen feltört szerverek számával, és egy sérülékeny telepítés megtalálása önmagában nem bizonyít behatolást. A javítást ettől függetlenül nem indokolt addig halasztani, amíg helyben is támadás nyomára bukkannak.
A javításnak minden futó példányhoz el kell jutnia
A webhelyek listája jó kiindulópont, de nem feltétlenül mondja meg, melyik szolgáltatás melyik PHP-ágat használja, konténerben fut-e, és ki felel a frissítéséért. A nyilvános éles webhely mellett a tesztkörnyezeteket, régebbi ügyfélportálokat, adminisztrációs felületeket és külső szállítók által karbantartott alkalmazásokat is át kell tekinteni.
Konténeres telepítésnél az alapkép frissítése nem változtatja meg a korábbi képből már futó példányokat. A javított képből újra kell telepíteni az alkalmazást, majd ellenőrizni kell az éles példányokat. Terheléselosztó mögött ugyanígy minden kiszolgáló állapota számít: egyetlen frissített csomópont mellett továbbra is fogadhatnak kéréseket javítatlan szerverek.
Az ellenőrzés az adott webhelyet ténylegesen kiszolgáló PHP-ra vonatkozzon. Ha a parancssori PHP és a webkiszolgáló másik telepítést használ, a parancssorban megjelenő megfelelő verziószám nem igazolja a webalkalmazás védelmét.
A frissítés és az incidensvizsgálat két külön feladat
A javítás lezárja az ismert szoftverhibát, de nem állapítja meg, hogy korábban történt-e behatolás, és nem távolítja el a támadó által esetleg hátrahagyott hozzáférést. A frissítéssel párhuzamosan érdemes áttekinteni a webszolgáltatás által indított szokatlan folyamatokat, az alkalmazásfájlok megmagyarázhatatlan módosításait, a rendellenes kimenő kapcsolatokat és az alkalmazás hitelesítő adatainak váratlan használatát.
Ezek általános vizsgálati támpontok, nem kizárólag a PHP2Shellre jellemző támadási jelek. Az eredményeket az alkalmazás megszokott működésével és más bizonyítékokkal együtt kell értelmezni. Behatolás gyanújánál meg kell őrizni a releváns naplókat, és a helyreállítást az incidenskezelőkkel kell egyeztetni. A csomag sikeres frissítése nem indok a korábbi gyanús tevékenység vizsgálatának lezárására.
A webhelyüzemeltetők azonnali teendői
- Azonosítsák a telepítéseket és a felelősöket. Minden szolgáltatásnál rögzítsék a tényleges PHP-verziót, a futtatás módját és a frissítés gazdáját.
- Ellenőrizzék mindkét javítást. Szállítói csomag esetén keressék a CVE-2026-109618 és a CVE-2026-109619 azonosítót a csomaghoz tartozó biztonsági közleményben.
- Vegyék előre a leginkább kitett rendszereket. Elsőbbséget érdemelnek a nyilvánosan elérhető alkalmazások és az érzékeny adatokhoz vagy belső szolgáltatásokhoz hozzáférő rendszerek.
- Igazolják az éles telepítést. Ellenőrizzék, hogy minden érintett szerver, kiszolgálófolyamat és konténer a javított csomaggal működik.
- Kezeljék a kimaradó rendszereket. Ahol késik a frissítés, korlátozzák a kitettséget, és rendeljenek felelőst, valamint határidőt a javításhoz.
- Vizsgálják ki a gyanús tevékenységet. A korábbi behatolásra utaló jeleket külön incidenskezelési feladatként kövessék nyomon.
A frissítés akkor tekinthető befejezettnek, ha az üzemeltető minden érintett szolgáltatásnál igazolni tudja, hogy a webes kéréseket már a javított PHP dolgozza fel.
Eredeti cím: Emergency Security Update For Critical PHP Vulnerabilities – Here’s Everything You Need To Know❗️
