Накратко: Актуализацията на PHP в cPanel след PHP2Shell включва три стъпки: всички ea-php и при нужда alt-php пакети да се доведат до коригирано състояние, PHP-FPM и Apache да се рестартират изцяло, а състоянието на пакетите да се документира. Клиентите на сървъра не могат сами да зададат най-важните временни стойности, това трябва да направи администраторът на WHM.
Изходна ситуация на cPanel сървърите
PHP2Shell обхваща уязвимостите CVE-2026-109618 и CVE-2026-109619 в самия PHP. И двете позволяват изпълнение на зловреден код без вход в системата и са оценени с CVSS v4.0 9,2. Засегнати са PHP-FPM, Apache с mod_php, php-cgi, FrankenPHP и LiteSpeed. Проектът PHP публикува на 21.10.2026 г. версиите 8.5.12, 8.4.27, 8.3.36 и 8.2.35.
cPanel не доставя PHP като един-единствен пакет, а чрез EasyApache 4 с отделен набор пакети за всяка версия, например ea-php83 или ea-php84. На някои сървъри към тях се добавят пакетите на операционната система, а при CloudLinux и версиите alt-php. Всеки източник има собствено състояние. Пълна картина се получава едва когато проверите и трите.
Актуализация на PHP в cPanel: проверка на наличното и на разпределението
Започнете с опис на наличното. Следващите команди само четат и нищо не променят. Пътищата и имената на пакетите са примери и могат да се различават според инсталацията.
# Инсталирани версии на PHP според WHM API
whmapi1 php_get_installed_versions
# Версия за всяка ea-php инсталация
for p in /opt/cpanel/ea-php*/root/usr/bin/php; do echo "$p"; "$p" -v | head -1; done
# Състояние на пакетите (системи на базата на RPM, пример)
rpm -qa | grep -E '^ea-php[0-9]+-php-(cli|fpm|common)' | sort
В MultiPHP Manager виждате коя версия ползва кой домейн и дали PHP-FPM е включен. Отбележете версиите, които са инсталирани, но не са зададени на никой домейн. И те трябва да се актуализират или да се премахнат.
Как да оцените правилно бекпортовете
Както при другите доставчици важи следното: показаният номер на версията не е единственият критерий. Ако корекцията се доставя като бекпорт, номерът може да остане непроменен. Затова проверете допълнително дневника на промените на пакета и указанията на доставчика.
# Търсене на CVE номера в дневника на промените на пакет (пример)
rpm -q --changelog ea-php84-php-cli | grep -iE 'CVE-2026-1096(18|19)'
Ако не се намери запис, това не означава автоматично, че корекцията липсва. Означава обаче, че Ви трябва писмено потвърждение, преди да определите сървъра като пачнат. Как се четат правилно версиите, описва Проверка на версията на PHP и на състоянието на пача.
Актуализация, рестарт и проверка
Актуализацията внасяте във WHM чрез системното обновяване или чрез управлението на пакетите. След това рестартирате всички PHP процеси. Новите файлове сами не са достатъчни, докато стари процеси продължават да работят в паметта.
# Рестартиране на PHP-FPM услугите на всички версии (скрипт на cPanel)
/scripts/restartsrv_apache_php_fpm
# Пълен рестарт на Apache
/scripts/restartsrv_httpd
# Проверка на времето на стартиране на PHP процесите
ps -eo pid,lstart,cmd | grep -E 'php-fpm|lsphp|php-cgi' | grep -v grep
Всеки PHP процес трябва да има време на стартиране след актуализацията. Ако не е така, прекратете го целенасочено през съответната услуга. При няколко сървъра си струва кратък протокол за всяка машина, който по-късно да използвате като доказателство.
Актуализация на CMS чрез инструменти на cPanel като WP Toolkit не затваря уязвимостта в PHP. Тя е полезна, но не замества нито актуализацията на PHP, нито рестарта.
Централно задаване на временните стойности
Ако дадена версия още не е коригирана, php.net препоръчва временни мерки, които не осигуряват пълна защита. В cPanel ги задавате в MultiPHP INI Editor в режим за администратори или директно в php.ini на съответната ea-php версия. Стойности в .user.ini на клиентските акаунти не са достатъчни за session.upload_progress.enabled.
; php.ini за целия сървър на засегнатата версия (пример)
session.upload_progress.enabled = 0
post_max_size = 32M
upload_max_filesize = 24M
Без функция за качване php.net посочва post_max_size = 8M. При PHP 8.5 се добавя fatal_error_backtraces=0. След това рестартирайте отново всички работни процеси. Ограничение на паметта задавате чрез cgroups, например с лимитите на CloudLinux, а не чрез RLIMIT_AS или RLIMIT_DATA. Повече подробности има в Незабавни мерки без пач.
Отговорност между оператора на сървъра и собствениците на акаунти
На cPanel сървър с много акаунти администраторът на WHM носи отговорността за PHP, услугите и конфигурацията на целия сървър. Собствениците на отделните акаунти отговарят за своите приложения, добавки и данни за достъп. Информирайте собствениците на акаунти кога и как е направен пачът и им препоръчайте да проверят приложенията си за нещо необичайно. Как изглежда ситуацията от гледна точка на клиента, описва Споделен хостинг.
Запазете логовете от 20.10.2026 г. нататък. Пачът не премахва зловреден софтуер, внесен преди това.
За доказателство е достатъчен прост протокол за всеки сървър: дата и час на актуализацията, списък на ea-php и alt-php пакетите с версия преди и след, списък на процесите с времена на стартиране след рестарта и при нужда потвърждение на доставчика на пакетите относно бекпортовете. Съхранете протокола извън сървъра. По-късно той служи като доказателство пред клиенти, застрахователи или одитори и улеснява следващата спешна актуализация, защото стъпките вече са описани. Ако управлявате няколко cPanel сървъра, си струва командите за четене от тази страница да се обединят в малък скрипт, който работи по един и същи начин на всички машини и събира резултатите. Така веднага ще забележите разлики между сървърите, например забравена версия на PHP.
Как помага PHP SOS конкретно?
- Описваме ea-php, alt-php и системните пакети и свързваме всички акаунти с версията им на PHP.
- Чрез нашата услуга за PHP пач актуализираме, рестартираме всички услуги и доказваме състоянието със списъци на пакетите и времена на процесите.
- Където е нужно, задаваме временните стойности за целия сървър и по начин, по който не могат да бъдат презаписани.
- Проверяваме акаунтите за типични следи от компрометиране и при находка започваме премахване на зловреден софтуер.
- След това намаляваме броя на версиите на PHP и укрепваме конфигурацията.
Често задавани въпроси
Къде във WHM виждам коя версия на PHP ползва кой домейн?
В MultiPHP Manager на WHM виждате за всеки домейн зададената версия и дали PHP-FPM е активен. За пълен списък е подходяща и справка през командния ред. Отбележете и версиите, които не са зададени на никой домейн.
Може ли клиент на cPanel сам да зададе временните стойности в .user.ini?
За session.upload_progress.enabled php.net изрично посочва, че .user.ini и ini_set() не са достатъчни. Стойността принадлежи в php.ini, в пула на FPM или в конфигурацията на сървъра. Това може да направи само администраторът на сървъра.
Достатъчен ли е graceful рестарт на Apache?
При PHP-FPM самите FPM услуги трябва да се рестартират, а презареждането на Apache не ги обновява. При PHP манипулатори на базата на Apache пълният рестарт е сигурният начин. След това проверете времето на стартиране на всички PHP процеси.
Какво става с CloudLinux и alt-php?
На сървърите с CloudLinux уебсайтовете понякога работят със собствени alt-php пакети вместо с ea-php. Те имат собствено състояние на пакетите и трябва да се проверяват и актуализират поотделно.