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

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.

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ó és a A Remi tároló 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 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.

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

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

Források

• php.net: biztonsági közlemények
• php.net: támogatott verziók
• Red Hat Security Bulletin RHSB-2026-013