# PHP End of Life: az elavult verziók kockázatai

> PHP End of Life: mi történik a támogatás vége után, miért kritikus a PHP 8.1 és régebbi a PHP2Shell után, és hogyan tervezze az átállást 8.2+ verzióra.

Forrás: https://phpsos.de/hu/ratgeber/php-end-of-life-risiken/  
Á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:** A PHP End of Life azt jelenti, hogy a PHP-projekt ehhez az ághoz már nem ad ki biztonsági frissítéseket. A PHP2Shell jól mutatja a következményeket, mert a PHP 8.1-hez és régebbiekhez nincs hivatalos javítás, a PHP 8.2 pedig 2026. 12. 31-én véget ér. Aki ma régi ágon fut, az átállást most tervezze meg, ne a következő vészhelyzetkor.

## Mit jelent a PHP End of Life

A PHP-projekt minden PHP-ágat, például a 8.2-t vagy a 8.3-at, csak korlátozott ideig gondoz. Először hibajavítások és biztonsági frissítések érkeznek, később már csak biztonsági frissítések. Utána a támogatás teljesen megszűnik. Az aktuális időtartamokat a php.net a támogatott verziókról szóló oldalán teszi közzé.

A támogatás megszűnése után a szoftver ugyan tovább fut. Ha azonban új rés válik ismertté, a PHP-projekttől már nem jön javítás. A szerver sebezhető marad, amíg valaki más nem javít, vagy amíg át nem tér egy támogatott ágra.

A vezetőség és az IT-vezetés számára ez elsősorban tervezési kérdés. A migráció nyugodtan előkészíthető. Egy kritikus közlemény után időnyomás alatt drága és kockázatos lesz.

## Mit mutat a PHP2Shell az elavult verziókról

2026. 10. 21-én a PHP-projekt javításokat adott ki két kritikus résre, a CVE-2026-109618-ra és a CVE-2026-109619-re. Mindkettő lehetővé teszi kártékony kód távoli futtatását bejelentkezés nélkül, és CVSS v4.0 szerint 9,2 értékű. A szakmai sajtó szerint szinte az összes verzió érintett egészen a PHP 5.4-ig visszamenőleg.

| Ág | Állapot a PHP-projekt szerint | PHP2Shell-javítás |
|---|---|---|
| PHP 8.5 | támogatott | 8.5.12 |
| PHP 8.4 | támogatott | 8.4.27 |
| PHP 8.3 | támogatott | 8.3.36 |
| PHP 8.2 | támogatott 2026. 12. 31-ig | 8.2.35 |
| PHP 8.1, 8.0, 7.4 | nincs hivatalos frissítés | csak minimális forráskód-backportok |
| PHP 7.3 és régebbi | nincs hivatalos frissítés | nincs backport a PHP-projekttől |

A 8.1-hez és régebbiekhez így csak a disztribúciók vagy tárhelyszolgáltatók backportjain keresztüli út marad. Ezek gyakran továbbra is a régi verziószámot jelzik, noha javítva vannak. Hogy egy backport telepítve van-e, azt kötelező érvénnyel csak a szolgáltató igazolhatja. A részleteket a [PHP 8.1 és régebbi: mi érvényes most](https://phpsos.de/hu/php2shell/php-8-1-und-aelter/) oldal tartalmazza, a teljes áttekintést a [Mely PHP-verziók érintettek?](https://phpsos.de/hu/php2shell/betroffene-php-versionen/) oldal.

> **Fontos:**
> A PHP 8.2 még megkapta a PHP2Shell javítását, de 2026. 12. 31-én eléri a támogatás végét. Aki most a 8.1-ről migrál, rögtön egy újabb ágat célozzon meg.

## Az elavult PHP-verziók kockázatai áttekintve

A biztonsági kockázat áll előtérben, de nem az egyetlen. Az elavult PHP-verziók további problémákat vonnak maguk után:

- **Nincs javítás új résekre:** Minden jövőbeli sebezhetőség nyitva marad, vagy harmadik felek backportjaitól függ.
- **Elavult könyvtárak:** Az aktuális csomagok újabb PHP-ágakat feltételeznek. A könyvtárakban lévő biztonsági javításokat ekkor már nem lehet telepíteni, ahogy a [composer audit](https://phpsos.de/hu/ratgeber/composer-abhaengigkeiten-pruefen/) útmutató mutatja.
- **Függés a szolgáltatótól:** A tárhelyszolgáltatók a régi verziókért részben felárat számítanak, vagy megszüntetik az üzemeltetést. A határidőt ilyenkor a szolgáltató szabja meg, nem Ön.
- **Igazolási problémák:** A biztosítók, megbízók felé vagy auditoknál egy nem támogatott verziót nehéz megindokolni. Hogy ebből szerződéses vagy jogi következmények adódnak-e, azt a biztosítóval vagy egy ügyvéddel tisztázza.
- **Növekvő migrációs ráfordítás:** Minél nagyobb a távolság az aktuális verziótól, annál több kódot kell módosítani.

Különösen gyakran érintettek a régebbi webshop-rendszerek és a régóta nem módosított egyedi fejlesztések. Tipikus példa a [Shopware 5](https://phpsos.de/hu/plattformen/shopware-5/), amely gyakran még régebbi PHP-ágakon fut.

## Helyzetfelmérés: mely PHP-verziók futnak Önnél?

Az első lépés egy teljes kép. Sok szerveren több PHP-verzió fut párhuzamosan, például egy régi weboldalhoz, amelyet már senki sem tart számon. Ezek a parancsok csak olvasnak:

```bash
# A parancssor verziója
php -v
# Telepített verziók Debian/Ubuntu alatt
ls /etc/php/
# Telepített verziók Pleskben
ls /opt/plesk/php/ 2>/dev/null
# Futó PHP-folyamatok a verzióval a névben
ps -eo user,cmd | grep -E "[p]hp-fpm|[p]hp[0-9.]*-cgi|[l]sphp" | sort | uniq -c
```

Minden weboldalnál rögzítse: domain, PHP-verzió, üzemmód, CMS verzióval, felelős személy. Ez a lista egyben a vészhelyzeti tervének alapja. Megosztott tárhelyen a verziókat többnyire a tárhelyszolgáltató ügyfélmenüjében találja.

## A migráció megtervezése: így járjon el

A migráció egy támogatott ágra általában ugyanazokat a lépéseket követi, a rendszertől függetlenül:

1. **A cél meghatározása:** válasszon olyan ágat, amelyet a php.net szerint még lehetőleg hosszú ideig támogatnak, és a gyártó rendszerkövetelményei szerint illik a CMS-éhez.
2. **A kompatibilitás ellenőrzése:** CMS, bővítmények, témák és saját kód. Az adatok az adott gyártó hivatalos oldalán találhatók.
3. **Staging felállítása:** a weboldal másolata az új PHP-verzióval, az adatbázissal együtt.
4. **Tesztelés:** minden fontos folyamat a kapcsolatfelvételi űrlaptól a rendelési folyamatig, továbbá a hibanapló figyelmeztetései.
5. **Átállás és újraindítás:** verzióváltás, az összes PHP-folyamat újraindítása, a működés és a hibanapló ellenőrzése.

Tervezzen reálisan. Egy kicsi, aktuális CMS-sel rendelkező weboldal gyakran gyorsan átállítható. Egy évek alatt kialakult, sok bővítménnyel és saját kóddal rendelkező webshop ezzel szemben a kód és a bővítmények módosítását igényelheti, egészen a webshop-rendszer új főverziójára való váltásig. Tisztázza korán, hogy belsőleg ki dönt, mekkora költségkeret áll rendelkezésre, és be kell-e vonni külső fejlesztőket.

Rögzítse emellett, hogyan tartja a jövőben szemmel a támogatások végét. Egy évi fix időpont, amikor a weboldalai listáját összeveti a php.net adataival, megakadályozza, hogy két év múlva ugyanaz a szűk keresztmetszet újra kialakuljon.

Az átállásig használja a php.net átmeneti intézkedéseit, például a `session.upload_progress.enabled=0` beállítást a szerverkonfigurációban. Ezek nem jelentenek teljes védelmet, de csökkentik a kockázatot.

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

- Felmérjük a szervereken lévő összes PHP-verziót, üzemmódot és alkalmazást.
- Weboldalanként értékeljük a kockázatot, és Önnel együtt meghatározzuk a sorrendet és a célverziót.
- A migrációig átmeneti intézkedéseket vezetünk be, és a szolgáltatótól igazolásokat kérünk a backportokról.
- Staging környezeten keresztül migrálunk, és dokumentáljuk a tesztet és az átállást.

A menetet a [PHP 8.1 és régebbi: migráció támogatott verzióra](https://phpsos.de/hu/leistungen/php-migration-legacy/) szolgáltatás írja le.


## Gyakori kérdések

**Mikor ér véget a PHP 8.2 támogatása?**  
A PHP 8.2 2026. 12. 31-én éri el a PHP-projekt általi támogatás végét. A PHP2Shell javítását az ág még a 8.2.35 verzióval megkapta, későbbi rések esetén ezután már nem várható hivatalos frissítés.

**Kap a PHP 8.1 javítást a PHP2Shell ellen?**  
A PHP-projekttől a 8.1-hez és régebbiekhez már nincsenek hivatalos frissítések. Csak minimális forráskód-backportok léteznek a 7.4, 8.0 és 8.1 verzióhoz. Hogy a tárhelyszolgáltatója vagy a disztribúciója telepíti-e ezeket, és hogyan, azt a szolgáltatótól kell megkérdeznie.

**Biztonságos egy régi PHP-verzió a tárhelyszolgáltató backportjaival?**  
A backportok konkrét réseket zárhatnak le, de nem pótolnak egy támogatott ágat. A szolgáltatótól függnek, gyakran később érkeznek, és nem fednek le minden rést. Tartós megoldásként ezért alkalmatlanok.

**Honnan tudom, hogy a CMS-em fut-e új PHP-verzióval?**  
Ellenőrizze a rendszerkövetelményeket a gyártó hivatalos oldalán, és tesztelje staging környezetben. A bővítményekre és témákra ugyanez érvényes, mert gyakran ezek jelentik a tényleges szűk keresztmetszetet.

## 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)