PHP2Shell: kritikus PHP-sérülékenységek gyors kezelése összetett nagyvállalati környezetben

Esettanulmány · Ügyfél: egy magyarországi távközlési nagyvállalat · 2026. október 28.

2026. október 21-én két kritikus PHP-sérülékenység vált nyilvánossá, amelyek hitelesítés nélküli távoli kódfuttatást tehettek lehetővé. Bemutatjuk, hogyan készült fel az Inshipia már a javítás megjelenése előtt, és hogyan élesítette a javított PHP-változatokat egy heterogén, magas rendelkezésre állású környezetben.

Vezetői összefoglaló

A PHP futtatókörnyezetben 2026. október 21-én nyilvánosságra hozott, PHP2Shell néven ismert kritikus sérülékenységek – CVE-2026-109618 és CVE-2026-109619 – sürgős intézkedést tettek szükségessé. A hibák sikeres kihasználása hitelesítés nélkül is lehetővé tehette támadói kód távoli végrehajtását az érintett kiszolgálókon, veszélyeztetve az adatok biztonságát és a szolgáltatások működését. [1–4]

Az ügyfél környezetében a feladat webkiszolgálókat, a phpMyAdmin szolgáltatást és a levelezés PHP-alapú komponenseit érintette. A cél a biztonsági kockázat mielőbbi megszüntetése volt, a magas rendelkezésre állási követelmények betartása mellett.

Az Inshipia már az előzetes tájékoztatás után megkezdte a felkészülést:

• felmérte az érintett rendszereket és a frissítési lehetőségeket,
• előkészítette a csomagok közvetlen beszerzését,
• ahol lehetett, próbafordítással csökkentette a későbbi végrehajtás bizonytalanságát.

A javítás megjelenése után az eltérő platformokhoz igazodó telepítési és fordítási megoldásokra volt szükség, mert a kész bináris csomagok nem minden környezethez álltak időben rendelkezésre.

Eredmény: a javított PHP-változatok élesítése az érintett rendszereken sikeresen megtörtént, a lezáró ellenőrzések a javított környezet működését igazolták.

Kiinduló helyzet és üzleti kockázat

Érintett szolgáltatások és technológiai környezet

A beavatkozás webkiszolgálókat, a phpMyAdmin szolgáltatást, valamint a levelezési szolgáltatások PHP-t használó összetevőit érintette.

A környezet több FreeBSD-verziót, Debian- és Ubuntu-alapú rendszereket, valamint indítóképekből (boot image) induló infrastruktúrát foglalt magában. Az eltérő PHP-verziók és futtatási módok, az egyedi modulok, illetve a korábbi rendszerkialakításból megmaradt függőségek miatt a frissítés módját rendszerenként kellett meghatározni.

A PHP2Shell sérülékenységek

A PHP2Shell elnevezés a PHP futtatókörnyezet két CVE-azonosító alatt nyilvántartott, egyaránt kritikus, CVSS 4.0 szerint 9,2-es súlyosságú hibacsoportját foglalja össze. [1–4]

• CVE-2026-109618 – a memória kimerülésének (OOM) hibás kezelése: ha a kérés feldolgozása memóriakimerülés miatt egy olyan ponton szakad meg, ahol a PHP belső adatszerkezetei még nincsenek teljesen inicializálva, a futtatókörnyezet a kérés lezárásakor ezeket érvényes adatként kezelheti. Ez memóriakezelési hibához és távoli kódfuttatáshoz vezethet. [2]
• CVE-2026-109619 – korábbi kérésből visszamaradó belső állapot: egy korábbi kéréshez tartozó belső állapot a hozzá kapcsolódó memória felszabadítása után is megmaradhat. Ha ugyanaz a PHP-munkafolyamat (worker) egy következő kérés során, még a szokásos inicializálás előtt ezt felhasználja, már felszabadított memóriához férhet hozzá, ami szintén távoli kódfuttatást tehet lehetővé. [3]

A hibák magát a PHP futtatókörnyezetet érintik, ezért az alkalmazások frissítése önmagában nem elegendő a javításukhoz. A tényleges kihasználhatóság függ a PHP verziójától, futtatási módjától (például Apache mod_php vagy PHP-FPM), konfigurációjától és az alkalmazástól. Sikeres támadás esetén a kód a PHP-t futtató folyamat jogosultságaival hajtható végre; ez önmagában nem jelent automatikus rendszergazdai hozzáférést.

A teljes körű javításhoz a hibákat javító PHP-kiadás – a támogatott ágakon a 8.5.12, 8.4.27, 8.3.36 vagy 8.2.35 verzió – vagy ennek megfelelő, javítást tartalmazó csomag telepítése, majd az összes PHP-folyamat újraindítása szükséges. [1–3]

Üzleti jelentőség

A sérülékenységek kihasználása az érintett PHP-folyamat számára hozzáférhető adatok és erőforrások jogosulatlan elérését, módosítását, valamint a szolgáltatások működésének megzavarását tehette volna lehetővé. Az adott környezet jogosultságaitól és elkülönítésétől függően ez webes tartalmak, alkalmazáskonfigurációk, hozzáférési adatok, illetve kapcsolódó adatbázisok vagy levelezési adatok veszélyeztetésével járhatott volna. A kutatói vizsgálatok a kódfuttatás mellett érzékeny folyamatmemória kiolvasásának lehetőségét is bemutatták. [4]

Az ügyfél számára ezért egyszerre két prioritás volt:

• a biztonsági kitettség gyors megszüntetése – egy sikeres támadás adatbiztonsági és rendelkezésre állási következményekkel járhatott volna;
• a szolgáltatások folytonosságának megőrzése – egy nem megfelelően előkészített frissítés alkalmazáshibákat vagy szolgáltatáskiesést okozhatott volna.

A beavatkozást úgy kellett előkészíteni és ütemezni, hogy mindkét kockázatot kezelje.

A feladat nehézsége

Sürgős javítás, esti karbantartási ablak

A javítást magas rendelkezésre állású szolgáltatásokon kellett előkészíteni, amelyeknél tervezett beavatkozásra kizárólag az esti karbantartási ablakban volt lehetőség. A sürgősség mellett alapvető követelmény volt a felhasználók által érzékelhető fennakadások elkerülése, illetve a szükséges megszakítások minimalizálása.

A rendelkezésre álló időbe bele kellett férnie:

• a telepítésnek,
• a szükséges újraindításoknak,
• az üzletkritikus funkciók ellenőrzésének,
• és probléma esetén a visszaállításnak.

A kiszolgáló vagy a PHP-folyamat sikeres elindulása önmagában nem volt elegendő a szolgáltatás megfelelő működésének igazolásához.

Eltérő platformok és egyedi fordítási igények

Az egyedi PHP-modulok miatt több környezetben a PHP forrásból történő fordítására volt szükség. Az eltérő operációsrendszer- és PHP-verziókhoz külön kellett kezelni a fordítási feltételeket, a függőségeket és a kompatibilitást.

A csomagellátás sem volt egységes: a kezelt környezetekben a forráskód szintjén elérhető javítás és a kész bináris csomagok megjelenése között több órás, egyes esetekben egy- vagy többnapos eltérés mutatkozott. Bizonyos platform–operációs rendszer–PHP-verzió kombinációkhoz a beavatkozás idején nem állt rendelkezésre megfelelő frissített csomag.

Az indítókép-alapú működés további követelményt jelentett: a javításnak az indításhoz használt rendszerképekben is meg kellett jelennie ahhoz, hogy egy későbbi újraindítás után is a javított környezet álljon rendelkezésre.

Örökölt környezet és ellenőrzési korlátok

A feladatot több mint egy évtized alatt kialakult rendszermegoldások és egyedi függőségek is nehezítették. Ezek miatt nem lehetett minden kiszolgálón azonos frissítési eljárást alkalmazni.

A javítottság ellenőrzéséhez nem állt rendelkezésre központi sérülékenységszkenner. Az érintettség felmérését és a javítás érvényesülésének igazolását ezért rendszerszintű ellenőrzésekre kellett alapozni, az üzletkritikus alkalmazásfunkciók vizsgálatával együtt.

Az Inshipia felkészülése és intézkedései

1. Felkészülés az előzetes jelzés alapján

Az első előzetes tájékoztatás még csak a sérülékenységek tényét és a frissítésre való felkészülés szükségességét jelezte. A részletes technikai információk ekkor még embargó alatt álltak; a csapat a PHP változásnaplójában is találkozott visszatartott részletekkel.

Az Inshipia ettől kezdve figyelemmel kísérte a Debian biztonsági bejelentéseit és a Sury csomagtároló friss csomagjainak megjelenését. A cél az volt, hogy a javítás elérhetővé válásakor az előkészítési feladatok már ne késleltessék a végrehajtást.

2. Az érintett rendszerek és a szolgáltatási hatás felmérése

A csapat felmérte, mely rendszereken található PHP, milyen interfészen vagy futtatási módban használják, és az adott környezetben milyen módon frissíthető. A felmérés arra is kiterjedt, hogy egy leállítás vagy újraindítás mekkora fennakadást okozna az érintett szolgáltatásban.

Ez alapján rendszerenként meghatározhatóvá vált, hol használható kész csomag, hol szükséges forrásból fordítani, és mely beavatkozásoknál kell kezelni a szolgáltatás esetleges kiesésének hatását.

3. A csomagbeszerzés előkészítése

A szokásos működésben a Debian-frissítések az ügyfél belső csomagtükrének másnap reggeli, ütemezett szinkronizálásával váltak volna elérhetővé. A csapat előkészítette a szükséges csomagok közvetlen letöltését a Sury tárolóból, hogy a javítás beszerzésével ne kelljen megvárni a következő szinkronizálást.

4. Próbafordítás a javítás megjelenése előtt

Ahol erre lehetőség volt, az Inshipia még a javítás megjelenése előtt lefordította a PHP előző verzióját. A próbafordítás célja a fordítási környezet, a függőségek és az egyedi modulok körüli hibák előzetes feltárása és rendezése volt.

Ennek köszönhetően az új forráskód megjelenésekor már előkészített fordítási környezet állt rendelkezésre. Az előző verzió sikeres fordítása ugyanakkor nem helyettesítette a javított változat fordítását és az alkalmazások működésének ellenőrzését.

5. Platformhoz igazított fordítás és telepítés

A javítás megjelenése után több esetben a kész csomagokra várás helyett forrásból kellett előállítani a frissített PHP-t. A beavatkozás során az alábbi megoldásokra volt szükség:

Környezet vagy körülmény	Alkalmazott megoldás
Debian-alapú rendszerek, belső csomagtükör napi szinkronizálással	A Sury-csomagok közvetlen beszerzése a következő reggeli szinkronizálás kivárása helyett.
FreeBSD-rendszer, amelyhez október 21-én 22 órakor, hat órával a hivatalos kiadás után sem volt megfelelő frissített bináris csomag	A PHP fordítása a ports rendszer segítségével.
FreeBSD-célrendszer, amelyen nem állt rendelkezésre ports környezet	Fordítás egy külön virtuális gép ports környezetében, majd az elkészült bináris átvitele a célrendszerre.
Ubuntu-alapú rendszer	A PHP kézi fordítása forrásból, az egyedi modulokkal együtt.

A külön fordítókörnyezetben előállított bináris használata a célrendszerrel való kompatibilitás ellenőrzését is szükségessé tette. Az indítóképek és a futó környezetek összhangját szintén biztosítani kellett.

6. Élesítés, működésellenőrzés és lezárás

Az élesítés a PHP frissítése mellett kiterjedt a kapcsolódó szolgáltatások és az üzletkritikus funkciók ellenőrzésére. A lezárás során ellenőrzésre került, hogy:

• a javított változat ténylegesen fut,
• a szükséges modulok betöltődnek,
• az indítóképekből történő újraindítás sem állítja vissza a korábbi állapotot.

A javítás élesítése az érintett rendszereken sikeresen megtörtént.

Az ügyfél számára nyújtott érték

Az Inshipia munkája már a javítás megjelenése előtt csökkentette a végrehajtás előtt álló akadályokat. Az érintett rendszerek felmérése, a szolgáltatásokra gyakorolt hatás értékelése, a csomagok közvetlen beszerzésének előkészítése és a próbafordítások révén több olyan feladat előre elvégezhető volt, amely egyébként az esti karbantartási ablak idejét terhelte volna.

A platformonként megválasztott fordítási és telepítési megoldásoknak köszönhetően a beavatkozás nem függött a kész bináris csomagok megjelenésétől vagy a belső csomagtükör napi szinkronizálásától. Az ügyfél így az örökölt, heterogén környezetben is sikeresen, a karbantartási keretek között zárhatta le a sürgős biztonsági feladatot.

Tanulságok

Az eset megmutatja, hogy egy kritikus PHP-frissítés végrehajtási idejét a javítás megjelenésén túl a csomagellátás, a fordítási feltételek, az alkalmazásfüggőségek és az ellenőrzések is meghatározzák. Ebben a környezetben a gyors reagálás feltétele az előzetes rendszerismeret és a javítás megjelenése előtt elvégzett felkészülés volt.

A tapasztalat a további fejlesztések irányát is kijelöli. A következő sürgős beavatkozás előkészítési idejét és bizonytalanságát csökkentheti:

• a naprakész komponensleltár,
• a megismételhető fordítási folyamat,
• az indítóképek következetes kezelése,
• az automatizált funkcionális ellenőrzések.

Források

1. PHP – Security advisory: Critical remote code execution vulnerabilities, update now – a PHP 2026. október 21-i biztonsági közleménye.
2. PHP – CVE-2026-109618: RCE via OOM corruption
3. PHP – CVE-2026-109619: RCE via stale global state
4. Wiz Research – PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet