# PHP 8.1 és régebbi: frissítés támogatott verzióra

> PHP 8.1 frissítés vakrepülés nélkül: átvizsgáljuk az alkalmazásokat, másolaton tesztelünk, támogatott PHP-verzióra állunk át, és biztosítjuk az átmeneti időt.

Forrás: https://phpsos.de/hu/leistungen/php-migration-legacy/  
Állapot: 2026. 10. 25.  
Szolgáltató: PHP SOS, PHP-vészhelyzeti segítség és szerverbiztonság. Azonnali segítség WhatsAppon: https://wa.me/491736494914?text=%C3%9Cdv%C3%B6zl%C3%B6m%2C%20PHP%20SOS%21%20Seg%C3%ADts%C3%A9gre%20van%20sz%C3%BCks%C3%A9g%C3%BCnk%20a%20PHP-szerver%C3%BCnkkel.%20C%C3%A9g%3A%20%E2%80%A6%20Weboldal%3A%20%E2%80%A6

**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](https://phpsos.de/hu/php2shell/php-8-1-und-aelter/) í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](https://phpsos.de/hu/plattformen/shopware-5/).

## Hogyan segít konkrétan a PHP SOS?

1. **Á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](https://phpsos.de/hu/leistungen/waf-virtuelles-patching/) oldalon.
2. **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](https://phpsos.de/hu/ratgeber/composer-abhaengigkeiten-pruefen/) írja le.
3. **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.
4. **Á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.
5. **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:

```bash
# 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/
```

> **Fontos:**
> 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](https://phpsos.de/hu/ratgeber/php-end-of-life-risiken/) í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.

## Források

- [php.net: támogatott verziók](https://www.php.net/supported-versions.php)
- [php.net: biztonsági közlemények](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [TechTarget: PHP2Shell, 22M exposed servers at risk](https://www.techtarget.com/cybersecurity/news/366652444/PHP2Shell-22M-exposed-servers-at-risk-as-emergency-patches-released)