PHP2Shell: miért kell fejlesztő a rendszered mellé akkor is, ha minden működik?

Október 21-én sürgősségi javítás jelent meg két kritikus PHP-sérülékenységre, öt nappal később pedig az amerikai kiberbiztonsági hatóság is felvette őket az aktívan kihasznált hibák listájára. Mi történt, kit érint, és miért nem egyszeri feladat a frissítés.

Egy működő weboldalról vagy webshopról könnyű azt hinni, hogy nincs vele teendő. Az októberi PHP2Shell jól mutatja, miért téves ez: az alkalmazás kódjához senki nem nyúlt, az oldal hibátlanul futott, a szerver mégis kritikus veszélybe került. A kockázatot nem a kódod változása okozta, hanem az, hogy kiderült valami a PHP-ról, amire az oldalad épül.

Mi történt?

A PHP fejlesztői október 21-én adtak ki sürgősségi javítást két sérülékenységre (CVE-2026-109618 és CVE-2026-109619). Mindkettő CVSS v4 szerint 9,2-es besorolású, vagyis kritikus, és bejelentkezés nélkül teszi lehetővé kód futtatását a szerveren, a webes folyamat jogosultságaival.

Ami igazán kellemetlenné teszi: a Datadog elemzése szerint a támadáshoz egy bejelentkezés nélküli HTTP POST kérés is elég bármelyik PHP-szkriptre, és a kérést a PHP még az alkalmazás kódja előtt feldolgozza. Az alkalmazásod beléptetése tehát nem véd, és az sem számít, mennyire jó a kódod.

• Október 17.: az Amazon csapdarendszere már rögzít egy kihasználási kísérletet, négy nappal a nyilvánosságra hozatal előtt.
• Október 20.: a PHP bejelenti a másnapi kiadást, és a technikai részletek kiszivárognak a tervezett közzététel előtt.
• Október 21.: megjelenik a javítás, és a watchTowr még aznap kihasználást észlel a saját csapdarendszereiben.
• Október 23.: a PHP egy harmadik hibáról is tájékoztat (CVE-2026-115560), amelyet a 21-i kiadás nem javít.
• Október 26.: az amerikai CISA felveszi a két hibát az aktívan kihasznált sérülékenységek listájára, a szövetségi szerveknek pedig három napot ad a javításra.

A teljes képhez hozzátartozik, hogy ez nem jelenti azt, hogy minden régi szervert feltörtek. A Rapid7 szerint a nyilvános exploitok csak szűk feltételek mellett működtek, adott operációs rendszer, PHP-verzió és webszerver párosításával. Erre viszont nem érdemes üzleti döntést építeni. A TechCrunch szerint a hibákról már két éve tudni lehetett, csak akkor úgy ítélték meg, hogy nincs gyakorlati módjuk a kihasználásnak, amíg a Calif kutatói egy AI-modell segítségével találtak egyet. A „most nem kihasználható” tehát nem végleges állapot.

Miért nem elég a frissítés gombja?

A hiba nem a Laravelben, nem a WordPressben és nem egy Composer-csomagban van, hanem magában a PHP-futtatókörnyezetben. Egy composer update ezért nem javít rajta semmit. Ráadásul a legtöbb oldalnál a csomagokat és a szervert más kezeli, így könnyen előfordul, hogy mindenki azt hiszi, a másik már megcsinálta.

A PHP-verzió kérdése önmagában is komoly. Az érintett ágak javított kiadásai: 8.5.12, 8.4.27, 8.3.36 és 8.2.35. A PHP 8.1 és a régebbi ágak nem kapnak hivatalos kiadást. A 7.4-es, 8.0-s és 8.1-es ágra a PHP csak forráskód-szintű javítást tett közzé, ezeknél disztribúciós csomag, fizetős hosszú távú támogatás vagy verzióváltás a megoldás.

A VirusTotal internetes felmérése szerint a verziójukat elárulló PHP-szerverek közül nagyjából 272 ezer fut támogatott ágon, és körülbelül 758 ezer olyan lejárt ágon (5.4-től 8.1-ig), ahol a hibás funkció alapból be van kapcsolva. Ez csak az internetről látható szerverek egy részét fedi le, mert a többség nem árulja el a verzióját, és nem azt méri, hány gép sérülékeny ténylegesen. Az arány viszont beszédes. A következő határidő is közel van: a PHP 8.2 támogatása 2026. december 31-én megszűnik.

Mit jelent a frissítés a gyakorlatban?

• Leltár. Tudni kell, pontosan mi szolgálja ki a kéréseket. A parancssori php -v mást mutathat, mint amit a webszerver használ, és a konténerekbe vagy más szoftverekbe csomagolt PHP is számít.
• A javítás azonosítása. A Linux-disztribúciók gyakran a verziószám változtatása nélkül építik be a javítást, ezért a csomag változásnaplóját kell megnézni, nem csak a számot.
• Újraindítás. A Google összefoglalója külön kiemeli, hogy a ténylegesen futó PHP-FPM, Apache vagy más kiszolgáló folyamatot kell újraindítani, a konténerképet pedig újra kell építeni. A telepített csomagtól még a régi kód futhat.
• Átmeneti beállítás. A PHP a CVE-2026-115560 miatt a következő hibajavító kiadásig a session.upload_progress.enabled=0 beállítást javasolja. Ezt a szerver szintjén kell megadni, mert az ini_set() és a .user.ini már túl késő. Ha az alkalmazás használja a feltöltés követését, ez a funkció addig nem fog működni, ezért előbb ellenőrizni kell.
• Ellenőrzés. A frissítés után végig kell próbálni a kritikus folyamatokat: belépést, fizetést, űrlapokat, háttérfeladatokat. Ehhez jó, ha vannak automatizált tesztek és van visszaállítási terv.
• Nyomok keresése. A javítás nem távolítja el azt, amit egy támadó korábban a szerveren hagyott. Gyanús például, ha a webes folyamat parancsértelmezőt indít, ha a naplóban Allowed memory size ... exhausted hiba jelenik meg Unknown on line 0 megjelöléssel, vagy ha a PHP-folyamatok váratlanul összeomlanak. Találat esetén a kulcsokat és jelszavakat is kompromittáltnak kell tekinteni.

A Rapid7 szerint a hiányzó naplóbejegyzés sem bizonyíték arra, hogy minden rendben van, a Datadog pedig azt írja, hogy egy sikeres támadás is végződhet normál HTTP 200 válasszal, és a folyamat tovább fut. Emiatt egy rendelkezésre állást figyelő monitor sem pótolja a frissítést: az oldal elérhető lehet akkor is, ha már nem csak a tiéd. A beállítások és a tűzfalszabályok legfeljebb időt adnak, az AWS megfogalmazásában egyedül a frissítés nyújt teljes megoldást.

Mit csinál az a fejlesztő, aki folyamatosan ránéz?

Nem a tűzoltás a lényeg, hanem hogy a tűzoltásnak legyen esélye. A PHP bejelentése és a javítás között nagyjából egy nap telt el, a kihasználási kísérletek pedig már akkor zajlottak. Ilyenkor nincs idő fejlesztőt keresni, ajánlatot kérni, majd megérteni egy ismeretlen rendszert.

• Figyeli a biztonsági közleményeket, és el tudja dönteni, mi érinti a rendszeredet és milyen sürgős.
• Ismeri a környezetet: tudja, mi hol fut, mihez van hozzáférése, és mit kell újraindítani.
• Kis lépésekben frissít. Aki rendszeresen frissít, annak egy sürgős javítás rutinfeladat. Aki évek óta nem nyúlt a rendszerhez, annak ugyanez verzióugrás, kompatibilitási hibákkal, a legrosszabb pillanatban.
• Előre tervezi a verzióváltást. A támogatás lejárata előre ismert dátum, így a váltás nyugodtan beütemezhető, nem pedig egy sérülékenység kényszeríti ki.
• Dokumentál. Marad nyoma annak, mi és mikor történt, ami egy incidensnél vagy ügyfél felé is számít.

Osztott tárhelynél a PHP javítása többnyire a szolgáltató feladata, de ettől még nem kerül le rólad minden: a használt PHP-ág kiválasztása, az alkalmazás kompatibilitása és annak ellenőrzése, hogy a javítás tényleg megérkezett, a te oldaladon marad.

Öt kérdés, amit tulajdonosként feltehetsz

• Ki a felelős név szerint azért, hogy egy biztonsági közleményre reagáljunk?
• Pontosan milyen PHP-verzió szolgálja ki az oldalt, és meddig támogatott?
• Mikor volt az utolsó frissítés, és van-e erről nyoma?
• Mennyi idő alatt lehet élesíteni egy sürgős javítást, és hogyan állunk vissza, ha gond van?
• A PHP2Shell javítása megtörtént, újraindultak a folyamatok, és megnézte valaki a naplókat?

Ha az első kérdésre nincs név, ott érdemes kezdeni. Ha pedig a korábbi fejlesztő már nem elérhető, a rendszerátvételről szóló cikkünkben leírtuk, mire számíts, a keretrendszer oldaláról pedig a Laravel-frissítésről szóló írásunk segíthet.