Plesk сървър: проверка и пач на версиите на PHP

Накратко: Актуализацията на PHP в Plesk е приключила едва когато всяка инсталирана версия на PHP е на коригирано състояние, всички PHP-FPM услуги са рестартирани и можете да го докажете със състоянието на пакетите и времето на стартиране на процесите. Номерът на версията, показан в панела, не е достатъчен за това, защото бекпортовете често го оставят непроменен.

За какво става дума при PHP2Shell на Plesk сървъри

PHP2Shell означава две критични уязвимости в самия PHP (CVE-2026-109618 и CVE-2026-109619, и двете с CVSS v4.0 9,2). Те позволяват на нападатели да изпълняват код на сървъра без вход в системата. Засегнати са, наред с други, PHP-FPM и Apache с mod_php, т.е. точно режимите на работа, които Plesk настройва за уебсайтовете.

На 21.10.2026 г. проектът PHP публикува коригираните версии 8.5.12, 8.4.27, 8.3.36 и 8.2.35. За PHP 8.1 и по-стари вече няма официални актуализации. Сървърите с Plesk имат особеност: там често работят няколко версии на PHP една до друга, отчасти от самия Plesk, отчасти от операционната система. Всяка от тях се нуждае от собствена проверка.

Актуализация на PHP в Plesk: първо опишете наличното

Преди да актуализирате каквото и да е, си изгответе списък на всички PHP манипулатори и на домейните, които ги ползват. Това става през панела (Инструменти и настройки, Настройки на PHP) или от командния ред. Следващите команди нищо не променят, а само четат.

# Всички регистрирани PHP манипулатори с версия и път
plesk bin php_handler --list

# Версия на всяка инсталирана от Plesk версия на PHP (пътят е пример)
for p in /opt/plesk/php/*/bin/php; do echo "$p"; "$p" -v | head -1; done

За всеки манипулатор отбележете версията, режима на работа (FPM, FastCGI, Apache модул) и броя на домейните. Манипулаторите без домейн не са повод за успокоение. По-късно те могат да бъдат зададени на домейн или да работят на тестови поддомейни.

Проверете състоянието на пакета, а не показаното

Plesk показва номера на версията, който съобщава самият PHP. Ако Plesk или дистрибуцията доставят корекцията като бекпорт, там може да продължи да пише например 8.2.34, въпреки че корекцията е включена. Обратното също е възможно: на пръв поглед актуален номер може да заблуди, ако пакетът още не е обновен. Решаващи са инсталираното състояние на пакета и писменото потвърждение на доставчика.

# Debian/Ubuntu (имената на пакетите са пример)
dpkg -l | grep -E 'plesk-php|php[0-9.]+-(fpm|cli)'

# AlmaLinux/Rocky/RHEL (имената на пакетите са пример)
rpm -qa | grep -E 'plesk-php|^php' | sort

Сравнете версиите на пакетите с данните в дневниците на промените на Plesk и с указанията на Вашата дистрибуция. Ако там не е документирано ясно, че CVE-2026-109618 и CVE-2026-109619 са отстранени, попитайте доставчика. Образец за това ще намерите в Попитайте хостинг доставчика за състоянието на пача.

Внесете актуализацията и рестартирайте всички работни процеси

Самата актуализация минава през инсталатора на Plesk или през управлението на пакетите на системата. После идва стъпката, която най-често липсва: рестартирането. В Plesk всяка версия на PHP има собствена FPM услуга. Рестартирайте всички, не само тази на основния домейн.

# Списък на всички PHP-FPM услуги (имената на услугите са пример)
systemctl list-units --type=service | grep -i 'php.*fpm'

# Рестартиране на всяка услуга, напр.:
systemctl restart plesk-php84-fpm

# Проверка на времето на стартиране на работещите PHP процеси
ps -eo pid,lstart,cmd | grep -E 'php-fpm|php-cgi' | grep -v grep

Ако домейн работи с Apache и mod_php, рестартирайте Apache изцяло. Ако времето на стартиране на PHP процес е преди актуализацията, процесът още не е обновен. Повече за тази стъпка има в Рестартиране на PHP-FPM и на всички работни процеси.

Временна защита, докато актуализацията още липсва

Ако за дадена версия още няма наличен пач, php.net препоръчва временни мерки. Те не са пълна защита. В Plesk стойностите, които приложенията не бива да презаписват, се задават като php_admin_value в допълнителните директиви на FPM за домейна или за целия сървър в php.ini на съответната версия.

; Пример за допълнителни PHP-FPM директиви в Plesk
php_admin_value[session.upload_progress.enabled] = 0
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 6M

При качвания според php.net е предвидено post_max_size = 32M, като upload_max_filesize е под тази стойност. При PHP 8.5 се добавя fatal_error_backtraces=0. Ограничаването на паметта чрез memory_limit=-1 бива прилагано само заедно с ограничение на ниво контейнер или cgroup. След това отново следва рестартиране на всички работни процеси. Подробности има в Незабавни мерки без пач. BSI (Федерална служба за информационна сигурност на Германия) препоръчва уеб сървърите временно да се изключат от мрежата, ако актуализацията не е възможна веднага.

След пача: запазете логовете и потърсете следи

Пачът затваря уязвимостта за в бъдеще. Той не премахва зловреден софтуер, внесен преди това, и не доказва, че нищо не се е случило. Затова запазете логовете на уеб сървъра от 20.10.2026 г. нататък. Plesk ги съхранява за всеки домейн в директорията logs; в тази ситуация не съкращавайте срока им на съхранение.

Обърнете внимание на нови или променени PHP файлове в директориите за качване, на непознати планирани задачи и на нови администраторски акаунти. Публикувани и потвърдени индикатори за компрометиране (Indicators of Compromise) досега няма; откриването се основава на анализ на поведението. Ако откриете нещо необичайно, не продължавайте на своя глава, а първо запазете състоянието.

Как помага PHP SOS конкретно?

• Описваме всички PHP манипулатори на Вашия Plesk сървър, свързваме ги с домейните и проверяваме действителното състояние на пакетите за всяка версия.
• В рамките на нашата услуга за PHP пач внасяме актуализациите, рестартираме всички услуги и документираме времето на стартиране на процесите като доказателство.
• Където пач липсва, прилагаме временните мерки по php.net за целия сървър и по начин, по който не могат да бъдат презаписани.
• Запазваме логовете и търсим следи от компрометиране, а при находка го правим заедно с Incident Response.
• След това укрепваме сървъра трайно и премахваме ненужните версии на PHP.

Често задавани въпроси

Източници

• php.net: Съобщения за сигурност
• PHP 8 ChangeLog
• php.net: Поддържани версии
• BSI