# Több PHP-verzió egy szerveren: mindegyiket külön kell javítani

> Több PHP-verzió egy szerveren: az összes telepítés megkeresése, eredet és felelős tisztázása, mindegyik külön javítása, újraindítása és igazolása.

Forrás: https://phpsos.de/hu/blog/mehrere-php-versionen-server/  
Á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:** Ha egy szerveren több PHP-verzió fut, a PHP2Shell után mindegyiket külön kell ellenőrizni, frissíteni és újraindítani. Tipikus források az operációs rendszer, a tárhelypanelek, például a Plesk vagy a cPanel, a harmadik féltől származó források, például a sury.org vagy a Remi, a CloudLinux, a LiteSpeed és a saját fordítású verziók. Csak a csomagokból, fájlokból és futó folyamatokból összeállított teljes lista mutatja meg, hogy valóban nem maradt-e ki egyetlen verzió sem.

## Az elfelejtett verzió

Egy évek óta futó szerveren a PHP-verziók úgy gyűlnek, mint a régi bútorok a padláson. A panel három ágat hozott magával, egy ügyfélhez egy régebbi verzió érkezett harmadik féltől, az operációs rendszernek megvan a sajátja. Mindegyiket egyszer jó okkal telepítették. Csak ma már senki sem tudja, melyikre van még szükség.

A PHP2Shell után éppen ez jelent problémát. A javítások 2026. október 21-én jelentek meg a PHP 8.5.12, 8.4.27, 8.3.36 és 8.2.35 verzióhoz. A szerveren lévő minden telepítés azonban a saját útján, a saját csomagkarbantartójától és a saját idejében kapja meg őket. A PHP 8.1-hez és régebbiekhez csak minimális forráskód-backportok vannak. Aki csak a főverziót frissíti, a többit nyitva hagyja.

## Honnan jön ennyi verzió

Az alábbi áttekintés tipikus forrásokat és példa-útvonalakat nevez meg. A pontos útvonalak verziónként és disztribúciónként eltérnek.

| Forrás | Példa-útvonal | Ki szállítja a javítást |
|---|---|---|
| Debian/Ubuntu operációs rendszer | `/usr/bin/php8.3`, `/etc/php/8.3/` | disztribúció |
| RHEL-család operációs rendszere | `/usr/bin/php`, `/etc/php-fpm.d/` | disztribúció |
| Plesk | `/opt/plesk/php/8.3/` | Plesk |
| cPanel (EasyApache 4) | `/opt/cpanel/ea-php83/` | cPanel |
| CloudLinux alt-php | `/opt/alt/php83/` | CloudLinux |
| Remi Software Collection | `/opt/remi/php83/` | Remi |
| sury.org | `/usr/bin/php8.3`, mint a rendszernél | sury.org |
| LiteSpeed | `/usr/local/lsws/lsphp83/` | LiteSpeed, illetve a csomagforrás |
| Saját fordítású | gyakran `/usr/local/bin/php` | Ön maga |
| Konténer | az image-ben | az image kiadója, az újraépítést Ön végzi |

Különösen alattomosak a sury.org csomagjai, mert ugyanazokat az útvonalakat használják, mint a disztribúció. Hogy egy `php8.3` a Debianból vagy a sury.org-ról származik-e, csak a csomagforrás mutatja meg. A sajátosságokat a [A sury.org tároló](https://phpsos.de/hu/blog/sury-repository-php/) és a [A Remi tároló](https://phpsos.de/hu/blog/remi-repository-php/) cikk írja le. Hogy a Plesk hogyan kezeli a verzióit, azt a [Plesk-szerver: PHP-verziók ellenőrzése és javítása](https://phpsos.de/hu/server/plesk/) oldal ismerteti.

## Az összes PHP-telepítés megkeresése

Megbízható lista három nézőpontból áll össze. A parancsok kizárólag olvasnak, és szervertől függően eltarthatnak egy ideig.

```bash
# 1. Csomagok: amit a csomagkezelő ismer
dpkg-query -W -f='${Package}\t${Version}\n' '*php*' 2>/dev/null | grep -E "fpm|cli|cgi|mod-php|lsphp"
rpm -qa 2>/dev/null | grep -iE "php.*(fpm|cli|cgi|litespeed)|^php-[0-9]|^ea-php|^alt-php" | sort

# 2. Fájlok: végrehajtható PHP-binárisok, a csomagkezelésen kívül is
find / -xdev -type f \( -name 'php' -o -name 'php[0-9]*' -o -name 'php-fpm*' -o -name 'php-cgi*' -o -name 'lsphp*' \) -perm -u+x 2>/dev/null

# 3. Folyamatok: ami éppen ténylegesen fut, indulási idővel
ps -eo pid,user,lstart,cmd | grep -E "[p]hp-fpm|[p]hp-cgi|[l]sphp|[a]pache2|[h]ttpd|[f]rankenphp"
```

Vesse össze a három listát. A csomag nélküli fájl saját fordítású vagy kézzel másolt verzióra utal. A megfelelő fájl nélküli folyamat egy törölt, de még futó telepítésre utalhat. Apache esetén ellenőrizze azt is, hogy be van-e töltve PHP-modul, például az `apache2ctl -M` vagy a `httpd -M` paranccsal. A konténerek és a Kubernetes-podok ezeken a listákon csak részben jelennek meg, és az image-ek külön ellenőrzését igénylik.

## Minden verzió külön javítása

Ha a listájában minden telepítésnek van egy sora, mindegyikre ugyanaz a folyamat vonatkozik:

1. **Tisztázza a felelőst:** A javítás a disztribúciótól, a paneltől, harmadik féltől származó forrásból vagy Öntől jön?
2. **Értékelje az állapotot:** hivatalos kijavított verzió, megerősített backport, tisztázatlan vagy nyitott.
3. **Frissítsen:** az adott forrás útján, nem más úton.
4. **Indítsa újra:** ennek a verziónak a szolgáltatását, nem csak a fő szolgáltatást. mod_php esetén a webszervert. A részletek a [A PHP-FPM és az összes worker újraindítása](https://phpsos.de/hu/php2shell/php-fpm-neustart/) oldalon vannak.
5. **Ellenőrizze:** vesse össze a folyamatok indulási idejét a frissítés időpontjával.
6. **Dokumentálja:** verzió, csomagállapot, bizonyíték, újraindítás ideje.

Azokra a verziókra, amelyekhez nincs javítás, a migrációig a php.net átmeneti intézkedései érvényesek. Ezeket minden verzióra külön állítsa be, mert minden telepítésnek saját php.ini-je és saját poolja van.

> **Fontos:**
> Ne feledkezzen meg a parancssorról. A cron-feladatok és szkriptek gyakran más PHP-verzióval futnak, mint a weboldal. Ennek a verziónak is javított állapotban kell lennie, még ha nem is dolgoz fel webes kéréseket.

## Melyik verziót használja a parancssor, melyiket a konténer?

Két terület különösen gyakran kerüli el a keresést. Az első a parancssor. Debian és Ubuntu alatt az alternatívák rendszere dönti el, melyik bináris áll a `php` parancs mögött. Az `update-alternatives --display php` megmutatja, mely verziók vannak regisztrálva és melyik érvényes éppen. A rögzített útvonalat hívó cron-feladatok, például a `/usr/bin/php7.4`, azonban megkerülik ezt a beállítást. Ezért érdemes megnézni az összes felhasználó crontabjait és a saját cron-feladatokat létrehozó panelek konfigurációját.

A második terület a konténerek. Egy Docker-konténer a szerveren saját PHP-verziót hoz magával, amely a gazdagép egyetlen csomaglistáján sem szerepel. A `docker ps` megmutatja a futó konténereket; hogy van-e bennük PHP és milyen verzió, azt az image megtekintése vagy egy `php -v` a konténerben árulja el. A javítás ott nem a gazdagépen történik, hanem az image újraépítésével és a konténer lecserélésével.

## Kevesebb biztonságosabb

A legjobb ellenőrzés az, amelyet nem kell elvégezni. Minden telepített PHP-verzió megduplázza a ráfordítást a következő résnél. A PHP2Shell után ezért egyértelmű szabály éri meg: a szerveren minden verziónak célja és felelőse kell, hogy legyen. Ami egyikkel sem rendelkezik, azt először kikapcsolják, majd egy megfigyelési idő után eltávolítják. Erről többet a [Régi PHP-verziók kikapcsolása a tárhelypanelben](https://phpsos.de/hu/blog/alte-php-versionen-abschalten/) cikkben olvashat.

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

- Összeállítjuk a szerverei összes PHP-telepítésének teljes listáját csomagokból, fájlokból, folyamatokból és konténerekből.
- Verziónként tisztázzuk az eredetet, a felelőst és a javítási állapotot.
- A [PHP-javítási szolgáltatás](https://phpsos.de/hu/leistungen/php-patch-service/) keretében minden verziót frissítünk, minden szolgáltatást újraindítunk, és igazoljuk az állapotot.
- Önnel közösen meghatározzuk, mely verziók maradnak, a többit pedig ellenőrzötten eltávolítjuk.


## Gyakori kérdések

**Miért fut több PHP-verzió a szerveremen?**  
Gyakori okok: a tárhelypanelek saját PHP-buildeket hoznak magukkal, újabb verziókhoz harmadik féltől származó források, például a sury.org vagy a Remi szolgálnak, és régebbi alkalmazásoknak meghatározott verzióra van szükségük. Ehhez gyakran hozzájön még az operációs rendszer PHP-verziója is.

**Veszélyes az a PHP-verzió, amelyet egy weboldal sem használ?**  
Amíg telepítve van és szolgáltatásként aktív, elérhető lehet, például egy tesztdomainen, egy elfelejtett poolon vagy egy cron-feladaton keresztül. Ráadásul később véletlenül hozzárendelhető egy weboldalhoz. A nem szükséges verziókat érdemes eltávolítani.

**Hogyan találom meg az összes PHP-telepítést egy Linux-szerveren?**  
Kombináljon három nézőpontot: telepített csomagok, végrehajtható PHP-fájlok a fájlrendszerben és futó folyamatok. Csak ha mindhárom ugyanazt a képet adja, teljes a lista.

**A frissítés után minden verziót külön újra kell indítani?**  
Igen. Minden verziónak általában saját FPM-szolgáltatása van, a LiteSpeednek saját lsphp-folyamatai, a mod_php pedig az Apache-folyamatban él. A fő szolgáltatás újraindítása nem újítja meg a többit.

## Források

- [php.net: biztonsági közlemények](https://www.php.net/)
- [php.net: támogatott verziók](https://www.php.net/supported-versions.php)
- [Red Hat Security Bulletin RHSB-2026-013](https://access.redhat.com/security/vulnerabilities/RHSB-2026-013)