Röviden: Aki még PHP 8.1-et vagy régebbit üzemeltet, a PHP-projekttől már nem kap hivatalos biztonsági frissítést, a PHP2Shell-re sem. A PHP 8.1 frissítés egy támogatott verzióra ezért nem luxus, hanem a tényleges megoldás. Átvizsgáljuk az alkalmazásait, másolaton tesztelünk, ellenőrzötten átállunk, és addig biztosítjuk az átmeneti időt.
Miért akut kockázat most a PHP 8.1 és a régebbi verziók
A PHP2Shell rések, a CVE-2026-109618 és a CVE-2026-109619 bejelentkezés nélküli kódfuttatást tesznek lehetővé. A PHP 8.5.12, 8.4.27, 8.3.36 és 8.2.35 verzióban javították őket. A PHP 8.1-hez és a régebbiekhez már nincs hivatalos frissítés, csak minimális forráskód-backportok a 7.4, 8.0 és 8.1 verzióhoz. A szakmai sajtó szerint szinte az összes verzió érintett egészen a PHP 5.4-ig visszamenőleg.
Egyes disztribúciók és tárhelyszolgáltatók saját backportokat telepítenek. Hogy az Ön rendszere ide tartozik-e, azt a szolgáltatónak kell megerősítenie az Ön konkrét csomagállapotára. Ez a megerősítés nélkül azzal kell számolnia, hogy a szerver nyitva áll. Hogy ez egyenként mit jelent, azt a PHP 8.1 és régebbi: mi érvényes most írja le.
PHP 8.1 frissítés: melyik célverzió?
A célnak olyan verziónak kell lennie, amelyet a PHP-projekt még támogat, és amelyet az alkalmazása jóváhagy. A támogatás aktuális állapotát a php.net a támogatott verziók oldalán teszi közzé. A PHP 8.2 2026. 12. 31-én véget ér; az átállás 8.2-re ezért csak köztes lépés lenne, hamarosan következő újabb projekttel.
Hogy a CMS-ét vagy webshoprendszerét mely PHP-verzió támogatja, azt a gyártó rendszerkövetelményei alapján ellenőrizzük, például a wordpress.org, shopware.com vagy typo3.org oldalon, és nem emlékezetből. Gyakran előbb magát a CMS-t kell frissíteni. A régi webshopok tipikus eset, lásd Shopware 5: régi webshopok régi PHP-verzión.
Hogyan segít konkrétan a PHP SOS?
- Állapotfelmérés és biztosítás: Felmérjük az összes alkalmazást, PHP-verziójukat, a CMS állapotát, a bővítményeket és a saját kódot. Párhuzamosan beállítjuk a php.net szerinti átmeneti intézkedéseket, hogy a kockázat a migrációig csökkenjen; részletek a WAF és virtuális javítás oldalon.
- Kompatibilitás ellenőrzése: Összevetjük a gyártók rendszerkövetelményeit, Composerrel ellenőrizzük a függőségeket, és a saját kódban elavult függvényeket keresünk. Hogy ez a függőségeknél hogyan néz ki, azt a Composer-függőségek ellenőrzése résekre írja le.
- Teszt másolaton: Az alkalmazás először egy tesztkörnyezetben fut az új PHP-verzióval. A hibákat ott javítjuk, vagy dokumentáljuk az ügynökségének.
- Átállás visszaúttal: Az éles átállás egy egyeztetett karbantartási időablakban történik aktuális mentéssel és rögzített visszaúttal.
- Utóellenőrzés: Az átállás után ellenőrizzük a hibanaplókat és a központi funkciókat, és eltávolítjuk a régi PHP-verziót, ha már nincs rá szükség.
Hogy mely weboldalak melyik PHP-verziót használják, azt sok rendszeren veszélytelenül meg lehet nézni a futó FPM-poolokon keresztül:
# futó PHP-FPM master és pool folyamatok megjelenítése
ps -eo pid,cmd | grep -E "php-fpm: (master|pool)" | grep -v grep
# telepített PHP-verziók (Debian/Ubuntu)
ls /etc/php/
Az új PHP-verzióra való frissítés nem távolítja el a korábban bejuttatott kártékony szoftvert. Ha a szerver 2026. 10. 17. óta védtelenül volt a hálózaton, a nyomok ellenőrzése is hozzátartozik.
Tipikus buktatók a frissítésnél
A PHP-verzióváltás legtöbb problémája előre látható, ha tudjuk, hol kell keresni:
- Elavult bővítmények: A már nem gondozott bővítmények vagy modulok újabb PHP-verziókon gyakran nem futnak. Rájuk pótlás vagy módosítás kell.
- Saját kód: Azok a függvények, amelyeket a PHP időközben elavultnak jelölt vagy eltávolított, figyelmeztetésekhez vagy megszakadásokhoz vezetnek. A szigorúbb típusellenőrzések régi programozási hibákat tárnak fel.
- Függőségek: A Composerrel beépített könyvtárak maguk is újabb verziókat követelnek, és további módosításokat vonnak maguk után.
- PHP-bővítmények a szerveren: Nem minden bővítmény, amely a régi verzió alatt telepítve volt, áll automatikusan rendelkezésre az újnál.
- Cron-feladatok és parancssor: A weboldal már az új verzión fut, az ütemezett feladatok azonban még a régi PHP-verziót hívják.
Aki ezeket a pontokat előre ellenőrzi, lerövidíti az átállást, és elkerüli a meglepetéseket az éles üzemben.
Mit kap, és mire van szükségünk
Áttekintést kap az összes alkalmazásról a kiinduló és a célverzióval, migrációs tervet a sorrenddel és a kockázatokkal, tesztjegyzőkönyvet, az átállás dokumentációját, és azoknak a pontoknak a listáját, amelyeket az ügynökségének vagy a fejlesztőjének még el kell végeznie.
Öntől a következőkre van szükségünk:
- szerver- vagy panel-hozzáférés és hozzáférés a CMS-háttérrendszerekhez
- hozzáférés a forráskódhoz és a repositoryhoz saját fejlesztéseknél
- kapcsolat az ügynökséggel vagy a fejlesztővel, akik ismerik az alkalmazást
- egy tesztkörnyezet, vagy engedély egy létrehozására
- karbantartási időablak és egy kapcsolattartó az átvételhez
Amit nem ígérünk
Nem ígérjük, hogy minden régi alkalmazás változtatás nélkül fut egy új PHP-verzión. Fejlesztés nélküli rendszereknél nagyobb átépítés vagy váltás lehet szükséges; ezt nyíltan megmondjuk, amint kirajzolódik. A kompatibilitásra vonatkozó állításainkat a gyártók adataira alapozzuk. Az átmeneti intézkedések pedig nem pótolják a migrációt, csak áthidalják az időt. Az elavult verziók hosszú távú kockázatait a PHP end of life: az elavult verziók kockázatai írja le.
Gyakori kérdések
Érinti a PHP2Shell a PHP 8.1-et?
A szakmai sajtó szerint szinte az összes verzió érintett egészen a PHP 5.4-ig visszamenőleg. A PHP 8.1-hez és régebbiekhez a PHP-projekttől nincs hivatalos frissítés, csak minimális forráskód-backportok a 7.4, 8.0 és 8.1 verzióhoz. Egyes disztribúciók saját backportokat telepítenek, ezt az adott szolgáltatónak kell megerősítenie.
Melyik PHP-verzióra frissítsek?
Olyan verzióra, amelyet a PHP-projekt még aktívan támogat, és amelyet az alkalmazása a gyártó rendszerkövetelményei szerint jóváhagy. A PHP 8.2 2026. 12. 31-én éri el a támogatás végét, ezért célként csak korlátozottan értelmes.
Nem állíthatom át egyszerűen a PHP-verziót a tárhelypanelen?
Technikailag ez gyakran egy kattintással megy. Hogy az alkalmazás utána még fut-e, az a CMS-verziótól, a bővítményektől és a saját kódtól függ. Teszt nélkül kiesésekkel vagy hibás funkciókkal kockáztat, például egy webshop pénztárában.
Mi van, ha a CMS-em nem támogatja az új PHP-verziót?
Akkor előbb a CMS-t kell frissíteni, adott esetben új főverzióra. Fejlesztés nélküli rendszereknél váltásra lehet szükség. Addig átmeneti intézkedésekkel biztosítjuk a szervert.