PHP2Shell a felszín alatt: hogyan válhat egy memóriahibából szerverátvétel?

Miért több ez egy hagyományos webalkalmazás-hibánál?

A PHP2Shell néven ismertté vált két sérülékenység a PHP futtatómotorjában található, nem egy konkrét WordPress-bővítményben vagy webáruház-modulban. Egy alkalmazás megfelelően ellenőrizheti a bemeneteket, biztonságosan kezelheti az adatbázis-műveleteket, és mégis veszélybe kerülhet, ha a kérést kiszolgáló PHP-környezet sérülékeny.

A PHP számos honlap, webshop, ügyfélportál és egyedi vállalati integráció alapja. Ezért a két hiba hatása nem korlátozható egyetlen tartalomkezelőre. Különösen problémás, ha egy kifelé elérhető PHP-folyamat hitelesítési adatokat, API-hozzáféréseket vagy más szolgáltatásokhoz vezető kapcsolati információkat is kezel.

2026. október 21-én a PHP fejlesztői négy támogatott verzióághoz adtak ki rendkívüli biztonsági javítást. A PHP 8.5.12, 8.4.27, 8.3.36 és 8.2.35 kiadások kezelik az ismert sérülékenységeket. A pontos technikai működést a projekt két elsődleges biztonsági közleményben ismertette. PHP – hivatalos kiadási és biztonsági tájékoztató.

Hogyan válik veszélyessé a hibás memóriakezelés?

Egy PHP-kérés feldolgozásakor a futtatókörnyezet memóriát foglal, belső adatszerkezeteket és hivatkozásokat hoz létre, majd a műveletek végén felszabadítja a szükségtelenné vált erőforrásokat. Hiba esetén ennek a folyamatnak biztonságos állapotban kell véget érnie.

A PHP2Shell két problémája éppen ennél az átmenetnél jelentkezik. Egy váratlan megszakítás részben előkészített állapotot hagyhat hátra; más esetben egy korábbi kérésből fennmaradó hivatkozás mutathat olyan memóriaterületre, amely már nem érvényes. Ha az érvénytelen állapotot a PHP később feldolgozza, memóriasérüléshez, információk kiszivárgásához, illetve meghatározott feltételek mellett távoli kódfuttatáshoz vezethet.

A következő négy állomás a mechanizmust szemlélteti, nem reprodukálható támadási útmutató: az egyes CVE-k eltérő belső útvonalakon valósulhatnak meg.

CVE-2026-109618: amikor a memóriakimerülés kezelése okoz sérülést

Az első hiba lényege a memóriakimerüléshez – out of memory, röviden OOM – kapcsolódó hibakezelés. A PHP bizonyos helyzetekben a longjmp() mechanizmussal ugrott ki egy végzetessé vált végrehajtási szakaszból. Az ilyen azonnali megszakítás akkor veszélyes, ha a belső objektumok előkészítése még nem fejeződött be.

A PHP fejlesztőinek elemzése szerint a kérés lezárásakor ilyenkor olyan részben inicializált adatszerkezetek is feldolgozásra kerülhettek, amelyek nem biztonságos állapotban maradtak. A memóriasérülés megfelelő körülmények között a végrehajtás feletti kontroll átvételéhez vezethet.

A hivatalos közlemény Apache mod_php környezetben teljes, bejelentkezés nélküli távoli kódfuttatást igazol. Az Apache-folyamat PHP-érintettsége miatt a támadási útvonal még az alkalmazás saját kódjának érdemi végrehajtása előtt kialakulhat. A PHP-FPM esetében a fejlesztők kockázatos kódfolyamatokat azonosítottak, de ehhez a konkrét CVE-hez a közzétett elemzés nem igazolt ugyanilyen teljes FPM-támadási láncot.

A Wiz eredeti elemzése ugyanehhez a CVE-hez kapcsolja a munkamenet-feltöltés kezelésében fellépő use-after-free jelenséget és a PHP-folyamat memóriájának távoli kiolvasását is. Ezek a demonstrációk más előfeltételekre épülnek, mint a hivatalosan igazolt, Apache mod_php alatti OOM-kódfuttatási útvonal. Wiz Research – eredeti kutatás.

A javítás ezért túlmegy egyetlen bemeneti ellenőrzés módosításán: a fejlesztők a memóriakimerülési állapotok kezelését alakították át, hogy a megszakítás biztonságosabb végrehajtási ponton történjen. PHP Security Team – a CVE-2026-109618 technikai közleménye.

CVE-2026-109619: érvénytelenné vált globális memóriaállapot

A második sérülékenység egyik kulcsfogalma a use-after-free: a program olyan memóriára hivatkozik, amelyet időközben már felszabadított. A PHP-folyamatok jellemzően nem minden kérés után szűnnek meg; a munkafolyamat egyes belső, globális adatai több kérés feldolgozása során is megmaradhatnak.

Ha a takarítás vagy az újrainicializálás valamely hibás útvonalon elmarad, egy korábbi kérés érvénytelen hivatkozást hagyhat hátra. A későbbi kérés ezután olyan memóriaterületet használhat, amelynek az eredeti tartalma már nincs a helyén. Ez újabb memóriasérülést, érzékeny adat kiolvasását, illetve bizonyos konfigurációknál kódfuttatást eredményezhet.

A Wiz kutatásában a CVE-2026-109619-hez a végzetes hibák utáni hibakeresési állapot (fatal-error backtrace) érvénytelen memóriahivatkozását, valamint az OPcache típuszavarát kapcsolja. Az előbbivel Drupal-, az utóbbival WordPress-környezetben demonstráltak bejelentkezés nélküli kódfuttatást. A PHP fejlesztői a hivatalos közleményben további globális állapotokat, köztük munkamenet-életciklushoz kötött előállító és felhasználó műveleteket is tárgyalnak. Ezek kihasználhatósága mindig az adott futtatókörnyezettől és az előfeltételektől függ.

Ennél a CVE-nél bizonyos PHP-FPM-környezetekre is igazoltak támadási útvonalakat. Ezért hibás következtetés volna, hogy a PHP-FPM általánosan véd a PHP2Shell ellen. A pontos feltételeket az adott támadási mód és futtatókörnyezet határozza meg. PHP Security Team – a CVE-2026-109619 technikai közleménye; Wiz Research – részletes kutatás.

Apache mod_php és PHP-FPM: miért nem azonos a kockázat?

Apache mod_php esetén a PHP az Apache-kiszolgálófolyamat részeként működik, míg PHP-FPM alatt elkülönített PHP-munkafolyamatok dolgozzák fel a kéréseket. Az eltérő folyamatmodell, a kérések élettartama és a belső állapotok újrahasználata befolyásolja, hogy melyik sérülékenységi útvonal aktiválható.

A jelenlegi, elsődleges technikai forrásokból három megállapítás következik: a CVE-2026-109618 teljes kihasználása mod_php alatt igazolt; ugyanennél a hibánál nem szabad a PHP-FPM-re automatikusan ugyanazt a bizonyítási szintet kiterjeszteni; a CVE-2026-109619 egyes PHP-FPM-es esetekben is kihasználható.

Nem célszerű tehát az érintettséget a webkiszolgáló nevéből vagy abból megítélni, hogy az alkalmazás nem Apache-on fut. Az operációs rendszer, a telepített PHP-csomag, a modulok, a munkafolyamat-konfiguráció és a ténylegesen telepített biztonsági javítás együtt határozzák meg a helyzetet.

Szintén lényeges, hogy egyes Linux-disztribúciók a javítást korábbi PHP-csomagverzióba építik vissza. Ilyenkor a megjelenített főverzió önmagában félrevezető: a gyártói biztonsági közlemény és a konkrét csomagkiadás a mérvadó.

Mit bizonyítottak a független kutatók?

A Wiz Research a PHP2Shell több támadási útvonalát ellenőrzött környezetben vizsgálta. A kutatók WordPress-, Drupal- és Joomla-alapú teszteken is bemutattak bejelentkezés nélküli távoli kódfuttatást. Mindez nem feltétlenül ezeknek az alkalmazásoknak a saját biztonsági hibájából következett: a sérülékeny PHP-futtatókörnyezet volt a közös elem.

A Wiz külön bemutatta a PHP-folyamat memóriájának kiolvashatóságát is. A megszerzett memóriarészletek – a rendszer működésétől függően – tokeneket, jelszavakat, API-kulcsokat vagy más érzékeny értékeket tartalmazhatnak. Ez fontos különbség: a támadási kockázat nem minden esetben korlátozódik kódfuttatásra.

A Datadog Security Labs a CVE-2026-109618 kihasználását független laboratóriumi vizsgálatban reprodukálta PHP 8.5.11 alatt. Elemzésük szerint a sikeres támadás nem feltétlenül jár feltűnő szerverösszeomlással, és az olyan általános védelmi mechanizmusok, mint a memóriacímek véletlenszerűsítése, önmagukban nem jelentenek teljes megoldást.

Tényhatár: az éles rendszerek ellen észlelt próbálkozás, egy ellenőrzött laboratóriumi demonstráció és a bizonyítottan sikeres betörés három különböző állítás. A vizsgált kutatások nem adnak ellenőrizhető, globális összesítést a sikeresen feltört szerverek számáról. Wiz – eredeti kutatás; Datadog – független elemzés.

Mit jelent ez a banki API-k és vállalati pénzügyi rendszerek számára?

A pénzügyi rendszerek több egymáshoz kapcsolódó szolgáltatásból állnak. Egy PHP-alapú ügyfélportál, webshop, számlázási integráció vagy vállalati adminisztrációs felület külső API-khoz és belső adatbázisokhoz is hozzáférhet.

Feltételezett példa: egy vállalat PHP-alapú háttérrendszere fizetési státuszt ellenőriz egy szolgáltatónál. A kapcsolat kezeléséhez használt hozzáférési token vagy más hitelesítési adat a feldolgozás során átmenetileg a szerver memóriájába kerülhet. Ha egy sérülékenység révén a támadó pont ehhez a tartományhoz fér hozzá, további rendszerek elérését elősegítő információhoz juthat.

Más támadási útvonalaknál a webkiszolgáló jogosultságaival futtatott kód fájlokat módosíthat, zavarhatja az üzleti folyamatokat, vagy megpróbálhat továbbjutni a hálózaton. Ez indokolja, hogy az incidenskezelés ne csak a weboldal elérhetőségére, hanem az adatok bizalmasságára és sértetlenségére is kiterjedjen.

A példából nem következik, hogy magyar bankoknál vagy fintech cégeknél bizonyított PHP2Shell-adatlopás történt volna. A szakmai tanulság a futtatókörnyezet, az API-titkok és a kapcsolódó rendszerek egységes kockázatkezelése.

Miért nem elegendő önmagában a webes tűzfal?

A Cloudflare és más szolgáltatók új WAF-szabályokkal és támadásészlelési megoldásokkal csökkentik a kitettséget. A Cloudflare full transaction detection megközelítése például nemcsak a beérkező HTTP-kérés, hanem a szerverválasz tartalmát is vizsgálhatja. Ez bizonyos esetekben segíthet felismerni vagy blokkolni az érzékeny adatot tartalmazó választ.

Ez azonban nem helyettesíti a PHP hibajavítását. Egy már végrehajtott szerveroldali műveletet a válasz blokkolása nem von vissza. Ráadásul nem minden támadás egyformán látható a hálózati forgalomban, és a támadók módosíthatják a kéréseiket a szűrés megkerülésére.

A PHP hivatalos elemzése alapján nincs olyan általános konfigurációs változtatás, amely mindkét CVE minden támadási útvonalát megszüntetné. A session.upload_progress.enabled=0 beállítás például bizonyos előfeltételeket korlátozhat, de nem teljes értékű javítás. A memóriakorlátok megváltoztatása sem helyettesíti a fejlesztői biztonsági frissítést.

A helyes védekezés többrétegű: javított futtatókörnyezet, korlátozott hozzáférések, naplózás, rendellenes PHP-folyamattevékenységek felismerése és megfelelő incidenskezelési készenlét. Cloudflare – Full Transaction Detection.

Gyakorlati ellenőrzőlista üzemeltetőknek

1. Térképezzék fel az összes PHP-környezetet. A publikus oldalak mellett a háttéradminisztráció, az API-k, a tesztrendszerek, az ERP-integrációk, a konténerek és a gyártói kezelőfelületek is számítanak.
2. Telepítsék a megfelelő biztonsági javítást. A PHP 8.5.12, 8.4.27, 8.3.36 és 8.2.35 hivatalosan javított kiadás. Menedzselt szervernél vagy disztribúciós csomagnál a szolgáltató hivatalos biztonsági csomagja a mérvadó.
3. Ellenőrizzék a ténylegesen futó rendszert. A PHP-munkafolyamatok újraindítása, a Docker-image-ek cseréje, az alkalmazások újraépítése és újbóli telepítése külön lépés lehet. A parancssorból lekérdezett PHP-verzió nem feltétlenül egyezik a webkiszolgálóban használt változattal.
4. Vizsgálják a kompromittálódás lehetséges jeleit. Gyanús HTTP-kérések, ismétlődő rendellenes válaszok, szokatlan PHP-hibák, váratlanul elindított rendszerparancsok, új fájlok és ismeretlen hálózati kapcsolatok adhatnak támpontot. Egyetlen ilyen jel sem bizonyít önmagában sikeres támadást.
5. Incidensgyanú esetén őrizzék meg a bizonyítékokat. Az érintett rendszer kontrollált izolálása, a naplók és a releváns állapotadatok megőrzése után értékeljék, mely hitelesítési adatok válhattak hozzáférhetővé, és indokolt-e kulcsok vagy tokenek cseréje.

A PHP 7.4, 8.0 és 8.1 ágakhoz rendkívüli forráskódjavítások is megjelentek, de ez nem állítja vissza e verziók hivatalos általános támogatását. Régi rendszereknél a gyártói támogatás és a hosszú távú migrációs terv különösen fontos.

A PHP2Shell legfontosabb tanulsága

A szoftverbiztonság nem ér véget az alkalmazás saját programkódjánál. A futtatókörnyezet, a hibakezelés, a memóriaműveletek és a több HTTP-kérést kiszolgáló folyamatok belső állapotkezelése ugyanolyan fontos biztonsági határvonalat képezhet.

A PHP2Shell története a fejlesztők és a független kutatók együttműködéséről is szól: a mesterséges intelligenciával támogatott kódelemzés szerepet kapott a hibák megtalálásában, de a támadási útvonalak bizonyítását, a javítás elkészítését és a kiadások ellenőrzését szakemberek végezték.

Banki API-k, webshopok és vállalati pénzügyi rendszerek üzemeltetésekor ezért a tényleges futtatókörnyezet verziójának és javítási állapotának ellenőrzése, a kapcsolódó hitelesítési adatok védelme és a szerveroldali támadásészlelés is a mindennapi működés része kell legyen.

Szerkesztői megjegyzés (2026. október 21.): Az elemzés a PHP Security Team, a Wiz Research, a Datadog Security Labs és a Cloudflare aznap elérhető szakmai közlései alapján készült; az azóta megjelenő hatósági bejelentéseket, javításokat és incidenseket a folyamatosan frissülő PHP2Shell-helyzetjelentésünkben követjük.