Röviden: A PHP2Shell utáni cPanel PHP-frissítés három lépésből áll: az összes ea-php csomagot és adott esetben az alt-php csomagokat javított állapotra kell hozni, a PHP-FPM-et és az Apache-ot teljesen újra kell indítani, és dokumentálni kell a csomagállapotot. A szerveren lévő ügyfelek a legfontosabb átmeneti értékeket nem tudják maguk beállítani, ezt a WHM-rendszergazdának kell megtennie.
A kiindulási helyzet cPanel-szervereken
A PHP2Shell a CVE-2026-109618 és a CVE-2026-109619 rést jelöli magában a PHP-ban. Mindkettő lehetővé teszi kártékony kód futtatását bejelentkezés nélkül, és CVSS v4.0 9,2 értéket kaptak. Érintett a PHP-FPM, az Apache mod_php-vel, a php-cgi, a FrankenPHP és a LiteSpeed. A PHP-projekt 2026. október 21-én kiadta a 8.5.12, 8.4.27, 8.3.36 és 8.2.35 verziót.
A cPanel a PHP-t nem egyetlen csomagként szállítja, hanem az EasyApache 4-en keresztül, verziónként egy-egy csomagkészlettel, például ea-php83 vagy ea-php84. Ehhez jönnek egyes szervereken az operációs rendszer csomagjai, a CloudLinuxon pedig az alt-php verziók. Minden forrásnak saját állapota van. Teljes kép csak akkor áll elő, ha mindhármat ellenőrzi.
cPanel PHP-frissítés: a készlet és a hozzárendelés ellenőrzése
Kezdje a készlet felmérésével. A következő parancsok csak olvasnak, és nem módosítanak semmit. Az útvonalak és a csomagnevek példák, telepítéstől függően eltérhetnek.
# A telepített PHP-verziók a WHM API szerint
whmapi1 php_get_installed_versions
# Verzió ea-php-telepítésenként
for p in /opt/cpanel/ea-php*/root/usr/bin/php; do echo "$p"; "$p" -v | head -1; done
# Csomagállapot (RPM-alapú rendszerek, példa)
rpm -qa | grep -E '^ea-php[0-9]+-php-(cli|fpm|common)' | sort
A MultiPHP Managerben látja, melyik domain melyik verziót használja, és hogy engedélyezve van-e a PHP-FPM. Jegyezze fel azokat a verziókat, amelyek telepítve vannak, de egyetlen domainhez sincsenek hozzárendelve. Ezeket is frissíteni vagy eltávolítani kell.
A backportok helyes besorolása
Mint más szolgáltatóknál, itt is igaz: a megjelenített verziószám nem az egyetlen mérce. Ha a javítást backportként szállítják, a szám változatlan maradhat. Ezért ellenőrizze emellett a csomag változásnaplóját és a szolgáltató tájékoztatóit.
# Egy csomag változásnaplójának átkeresése CVE-számokra (példa)
rpm -q --changelog ea-php84-php-cli | grep -iE 'CVE-2026-1096(18|19)'
Ha nem talál bejegyzést, az nem jelenti automatikusan, hogy a javítás hiányzik. Azt viszont igen, hogy írásos megerősítésre van szüksége, mielőtt a szervert javítottnak minősíti. A verziók helyes olvasását a következő oldal írja le: A PHP-verzió és a javítási állapot ellenőrzése.
Frissítés, újraindítás és ellenőrzés
A frissítést a WHM-ben a rendszerfrissítésen vagy csomagkezelőn keresztül telepíti. Utána indítsa újra az összes PHP-folyamatot. Az új fájlok önmagukban nem elegendők, amíg régi folyamatok futnak a memóriában.
# Az összes verzió PHP-FPM-szolgáltatásainak újraindítása (cPanel-szkript)
/scripts/restartsrv_apache_php_fpm
# Az Apache teljes újraindítása
/scripts/restartsrv_httpd
# A PHP-folyamatok indulási idejének ellenőrzése
ps -eo pid,lstart,cmd | grep -E 'php-fpm|lsphp|php-cgi' | grep -v grep
Minden PHP-folyamat indulási ideje a frissítés utáni legyen. Ha nem így van, célzottan állítsa le a hozzá tartozó szolgáltatáson keresztül. Több szerver esetén érdemes gépenként rövid jegyzőkönyvet készíteni, amelyet később igazolásként használhat.
A cPanel-eszközökkel, például a WP Toolkittel végzett CMS-frissítés nem zárja be a PHP-rést. Hasznos, de sem a PHP-frissítést, sem az újraindítást nem helyettesíti.
Átmeneti értékek központi beállítása
Ha egy verzió még nincs javítva, a php.net átmeneti intézkedéseket javasol, amelyek nem nyújtanak teljes védelmet. A cPanelben ezeket a MultiPHP INI Editorban állítsa be rendszergazdai módban, vagy közvetlenül az adott ea-php verzió php.ini fájljában. Az ügyfélfiókok .user.ini fájljaiban megadott értékek a session.upload_progress.enabled esetében nem elegendők.
; az érintett verzió szerverszintű php.ini fájlja (példa)
session.upload_progress.enabled = 0
post_max_size = 32M
upload_max_filesize = 24M
Feltöltési funkció nélkül a php.net post_max_size = 8M értéket nevezi meg. A PHP 8.5-nél ehhez jön a fatal_error_backtraces=0. Ezután indítsa újra az összes workert. A memóriakorlátot cgroupokon keresztül állítsa be, például a CloudLinux korlátaival, ne a RLIMIT_AS vagy a RLIMIT_DATA segítségével. További részletek a következő oldalon találhatók: Azonnali intézkedések javítás nélkül.
A felelősség megoszlása a szerver üzemeltetője és a fióktulajdonosok között
Egy sok fiókot kiszolgáló cPanel-szerveren a WHM-rendszergazda felel a PHP-ért, a szolgáltatásokért és a szerverszintű konfigurációért. Az egyes fiókok tulajdonosai az alkalmazásaikért, a bővítményeikért és a hozzáférési adataikért felelnek. Tájékoztassa a fióktulajdonosokat arról, mikor és hogyan történt a javítás, és javasolja nekik, hogy vizsgálják meg az alkalmazásaikat gyanús jelekre. Hogyan néz ki a helyzet az ügyfelek szemszögéből, azt a megosztott tárhely oldala írja le.
Őrizze meg a naplókat 2026. október 20-tól. A javítás nem távolítja el a korábban bejuttatott kártevőt.
Az igazoláshoz elegendő egy egyszerű jegyzőkönyv szerverenként: a frissítés dátuma és időpontja, az ea-php és alt-php csomagok listája a verzióval előtte és utána, a folyamatlista az újraindítás utáni indulási időkkel, és adott esetben a csomagszállító megerősítése a backportokról. A jegyzőkönyvet tárolja a szerveren kívül. Később bizonyítékul szolgál ügyfelek, biztosítók vagy ellenőrök felé, és megkönnyíti a következő sürgősségi frissítést, mert a lépések már le vannak írva. Ha több cPanel-szervert üzemeltet, érdemes az ezen az oldalon szereplő olvasó parancsokat egy kis szkriptbe foglalni, amely minden gépen ugyanúgy fut, és összegyűjti az eredményeket. Így egy pillantással felismeri a szerverek közötti eltéréseket, például egy elfelejtett PHP-verziót.
Hogyan segít konkrétan a PHP SOS?
- Leltározzuk az ea-php, alt-php és rendszercsomagokat, és az összes fiókot hozzárendeljük a PHP-verziójához.
- A PHP-javítási szolgáltatásunkon keresztül frissítünk, újraindítjuk az összes szolgáltatást, és az állapotot csomaglistákkal és folyamatidőkkel igazoljuk.
- Ahol szükséges, az átmeneti értékeket szerverszinten és felülírhatatlanul állítjuk be.
- Ellenőrizzük a fiókokat a kompromittálódás tipikus nyomaira, és megállapítás esetén elindítjuk a kártevőeltávolítást.
- Ezután csökkentjük a PHP-verziók számát, és megerősítjük a konfigurációt.
Gyakori kérdések
Hol látom a WHM-ben, melyik domain melyik PHP-verziót használja?
A WHM MultiPHP Managerében minden domainnél látja a hozzárendelt verziót és azt, hogy aktív-e a PHP-FPM. A teljes listához emellett érdemes parancssori lekérdezést is használni. Jegyezze fel azokat a verziókat is, amelyek egyetlen domainhez sincsenek hozzárendelve.
Beállíthatja egy cPanel-ügyfél maga az átmeneti értékeket a .user.ini fájlban?
A session.upload_progress.enabled esetében a php.net kifejezetten megjegyzi, hogy a .user.ini és az ini_set() nem elég. Az érték a php.ini fájlba, az FPM-poolba vagy a szerverkonfigurációba tartozik. Ezt csak a szerver rendszergazdája teheti meg.
Elég az Apache graceful újraindítása?
A PHP-FPM esetében magukat az FPM-szolgáltatásokat kell újraindítani, az Apache újratöltése nem újítja meg őket. Az Apache-alapú PHP-kezelőknél a teljes újraindítás a biztos út. Ezután ellenőrizze az összes PHP-folyamat indulási idejét.
Mi a helyzet a CloudLinuxszal és az alt-php-val?
A CloudLinux-szervereken a weboldalak részben saját alt-php csomagokkal futnak az ea-php helyett. Ezeknek külön csomagállapotuk van, és külön kell őket ellenőrizni és frissíteni.