Röviden: A Plesk PHP-frissítése akkor van lezárva, ha minden telepített PHP-verzió javított állapotban van, az összes PHP-FPM-szolgáltatást újraindították, és ezt a csomagállapottal és a folyamatok indulási idejével igazolni tudja. A panelben látható verziószám önmagában nem elég, mert a backportok gyakran változatlanul hagyják.
Miről szól a PHP2Shell a Plesk-szervereken
A PHP2Shell a PHP-ban lévő két kritikus rést jelöli (CVE-2026-109618 és CVE-2026-109619, egyenként CVSS v4.0 9,2). Lehetővé teszik a támadóknak, hogy bejelentkezés nélkül kódot futtassanak a szerveren. Érintett többek között a PHP-FPM és az Apache mod_php-vel, vagyis pontosan azok az üzemmódok, amelyeket a Plesk a weboldalakhoz beállít.
- október 21-én a PHP-projekt kiadta a javított 8.5.12, 8.4.27, 8.3.36 és 8.2.35 verziókat. A PHP 8.1-hez és a régebbiekhez már nincs hivatalos frissítés. A Plesk-szervereknek van egy sajátossága: itt gyakran több PHP-verzió fut egymás mellett, részben magától a Pleskről, részben az operációs rendszerből. Mindegyiket külön kell ellenőrizni.
A panelben végzett frissítés a lemezen cseréli le a fájlokat. Amíg régi PHP-folyamatok futnak a memóriában, a rés nyitva marad. Az összes worker újraindítása nélkül a javítás nem hatásos.
Plesk PHP-frissítés: először a készlet felmérése
Mielőtt bármit frissítene, szerezzen egy listát az összes PHP-kezelőről és az őket használó domainekről. Ez megoldható a panelen keresztül (Eszközök és beállítások, PHP-beállítások) vagy parancssorból. A következő parancsok nem módosítanak semmit, csak olvasnak.
# Az összes regisztrált PHP-kezelő verzióval és útvonallal
plesk bin php_handler --list
# A Plesk által telepített minden PHP-verzió verziója (az útvonal példa)
for p in /opt/plesk/php/*/bin/php; do echo "$p"; "$p" -v | head -1; done
Jegyezze fel minden kezelőnél: a verziót, az üzemmódot (FPM, FastCGI, Apache-modul) és a domainek számát. A domain nélküli kezelő nem jelent enyhülést. Később hozzárendelhetők, vagy teszt-aldomaineken futhatnak.
A kijelzés helyett a csomagállapotot ellenőrizze
A Plesk azt a verziószámot mutatja, amelyet maga a PHP jelent. Ha a Plesk vagy a disztribúció a javítást backportként szállítja, ott továbbra is állhat például 8.2.34, noha a korrekció benne van. Fordítva, egy naprakésznek tűnő szám megtévesztő lehet, ha egy csomag még nem frissült. A döntő a telepített csomagállapot és a szolgáltató írásos megerősítése.
# Debian/Ubuntu (a csomagnevek példák)
dpkg -l | grep -E 'plesk-php|php[0-9.]+-(fpm|cli)'
# AlmaLinux/Rocky/RHEL (a csomagnevek példák)
rpm -qa | grep -E 'plesk-php|^php' | sort
Hasonlítsa össze a csomagverziókat a Plesk változásnaplóiban és a disztribúció tájékoztatóiban szereplő adatokkal. Ha ott nem dokumentálták egyértelműen, hogy a CVE-2026-109618 és a CVE-2026-109619 javítva van, kérdezzen rá a szolgáltatónál. Ehhez mintát talál itt: A javítási állapot megkérdezése a tárhelyszolgáltatótól.
A frissítés telepítése és az összes worker újraindítása
Maga a frissítés a Plesk-telepítőn vagy a rendszer csomagkezelőjén keresztül fut. Utána jön az a lépés, amely a leggyakrabban kimarad: az újraindítás. A Pleskben minden PHP-verziónak saját FPM-szolgáltatása van. Indítsa újra mindet, ne csak a főtartományét.
# Az összes PHP-FPM-szolgáltatás listázása (a szolgáltatásnevek példák)
systemctl list-units --type=service | grep -i 'php.*fpm'
# Szolgáltatásonként újraindítás, pl.:
systemctl restart plesk-php84-fpm
# A futó PHP-folyamatok indulási idejének ellenőrzése
ps -eo pid,lstart,cmd | grep -E 'php-fpm|php-cgi' | grep -v grep
Ha egy domain Apache-csal és mod_php-vel fut, indítsa újra teljesen az Apache-ot. Ha egy PHP-folyamat indulási ideje a frissítés előtti, akkor még nem újult meg. Ennek a lépésnek a részleteit a következő oldal tartalmazza: A PHP-FPM és az összes worker újraindítása.
Átmeneti védelem, ha a frissítés még hiányzik
Ha egy verzióhoz még nincs elérhető javítás, a php.net átmeneti intézkedéseket javasol. Ezek nem jelentenek teljes védelmet. A Pleskben azokat az értékeket, amelyeket az alkalmazások nem írhatnak felül, php_admin_value-ként állítsa be a domain további FPM-direktíváiban, vagy szerverszinten az adott verzió php.ini fájljában.
; Példa a további PHP-FPM-direktívákra a Pleskben
php_admin_value[session.upload_progress.enabled] = 0
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 6M
A php.net szerint feltöltések esetén post_max_size = 32M van előirányozva, az upload_max_filesize ennél kisebb. A PHP 8.5-nél ehhez jön a fatal_error_backtraces=0. A memory_limit=-1 beállítással történő memóriakorlátozás csak akkor alkalmazható, ha mellette konténer- vagy cgroup-szinten is van korlát. Ezután ismét az összes worker újraindítása következik. A részleteket a következő oldalon találja: Azonnali intézkedések javítás nélkül. A BSI (a német Szövetségi Információbiztonsági Hivatal) azt javasolja, hogy ha a frissítés nem lehetséges azonnal, a webszervereket átmenetileg vegyék le a hálózatról.
A javítás után: naplók mentése és nyomok keresése
A javítás a jövőre nézve zárja be a rést. Nem távolítja el a korábban bejuttatott kártevőt, és nem bizonyítja, hogy nem történt semmi. Ezért őrizze meg a webszerver naplóit 2026. október 20-tól. A Plesk ezeket domainenként a logs könyvtárban tárolja; ebben a helyzetben ne rövidítse a megőrzési időt.
Figyeljen az új vagy módosított PHP-fájlokra a feltöltési könyvtárakban, az ismeretlen ütemezett feladatokra és az új rendszergazdai fiókokra. Közzétett, megerősített Indicators of Compromise eddig nincsenek; az észlelés viselkedéselemzésen alapul. Ha gyanús jeleket talál, ne dolgozzon tovább saját szakállára, hanem először mentse az állapotot.
Hogyan segít konkrétan a PHP SOS?
- Felmérjük a Plesk-szerver összes PHP-kezelőjét, hozzárendeljük a domaineket, és verziónként ellenőrizzük a tényleges csomagállapotot.
- A PHP-javítási szolgáltatásunk keretében telepítjük a frissítéseket, újraindítjuk az összes szolgáltatást, és a folyamatok indulási idejét dokumentáljuk igazolásként.
- Ahol hiányzik a javítás, a php.net szerinti átmeneti intézkedéseket szerverszinten és felülírhatatlanul állítjuk be.
- Mentjük a naplókat és keressük a kompromittálódás nyomait, megállapítás esetén az Incident Response keretében.
- Ezután tartósan megerősítjük a szervert, és eltávolítjuk a nem szükséges PHP-verziókat.
Gyakori kérdések
Miért mutat a Plesk a frissítés után még mindig PHP 8.2.34-et?
A disztribúciók és a szolgáltatók a biztonsági javításokat részben backportként telepítik, a verziószám megváltoztatása nélkül. Ilyenkor a csomag állapota és a szolgáltató megerősítése a döntő. A kijelzés önmagában sem a javítást, sem annak hiányát nem bizonyítja.
Elég a Plesk-panelben a Frissítésre kattintani?
A frissítés új fájlokat helyez el, a futó PHP-folyamatok azonban a memóriában lévő régi kóddal dolgoznak tovább. Az új állapot csak az összes PHP-FPM-szolgáltatás és a webszerver újraindítása után aktív. Ezután ellenőrizze a folyamatok indulási idejét.
Azokat a PHP-verziókat is javítanom kell, amelyeket egyetlen domain sem használ?
Igen, ha telepítve maradnak. Egy nem használt kezelő később véletlenül hozzárendelhető, vagy tesztkörnyezeteken keresztül elérhető lehet. A nem szükséges verziókat érdemesebb teljesen eltávolítani.
Segít a PHP2Shell ellen egy WordPress-frissítés a Plesk-eszköztárban?
Nem. A PHP2Shell magát a PHP-t érinti, nem a CMS-t. A CMS-frissítés ettől függetlenül hasznos, de ezt a rést nem zárja be.