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

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

Източник: https://phpsos.de/bg/server/plesk/  
Актуалност: 25.10.2026  
Доставчик: PHP SOS, Спешна помощ за PHP и сигурност на сървъри. Незабавна помощ по WhatsApp: https://wa.me/491736494914?text=%D0%97%D0%B4%D1%80%D0%B0%D0%B2%D0%B5%D0%B9%D1%82%D0%B5%2C%20PHP%20SOS%2C%20%D0%B8%D0%BC%D0%B0%D0%BC%D0%B5%20%D0%BD%D1%83%D0%B6%D0%B4%D0%B0%20%D0%BE%D1%82%20%D0%BF%D0%BE%D0%BC%D0%BE%D1%89%20%D1%81%20%D0%BD%D0%B0%D1%88%D0%B8%D1%8F%20PHP%20%D1%81%D1%8A%D1%80%D0%B2%D1%8A%D1%80.%20%D0%A4%D0%B8%D1%80%D0%BC%D0%B0%3A%20%E2%80%A6%20%D0%A3%D0%B5%D0%B1%D1%81%D0%B0%D0%B9%D1%82%3A%20%E2%80%A6

**Накратко:** Актуализацията на 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 процеси продължават да работят в паметта, уязвимостта остава отворена. Без рестартиране на всички работни процеси пачът не е в сила.

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

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

```bash
# Всички регистрирани 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, въпреки че корекцията е включена. Обратното също е възможно: на пръв поглед актуален номер може да заблуди, ако пакетът още не е обновен. Решаващи са инсталираното състояние на пакета и писменото потвърждение на доставчика.

```bash
# 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 са отстранени, попитайте доставчика. Образец за това ще намерите в [Попитайте хостинг доставчика за състоянието на пача](https://phpsos.de/bg/ratgeber/hoster-patch-status-erfragen/).

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

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

```bash
# Списък на всички 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 и на всички работни процеси](https://phpsos.de/bg/php2shell/php-fpm-neustart/).

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

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

```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. След това отново следва рестартиране на всички работни процеси. Подробности има в [Незабавни мерки без пач](https://phpsos.de/bg/php2shell/sofortmassnahmen-ohne-patch/). BSI (Федерална служба за информационна сигурност на Германия) препоръчва уеб сървърите временно да се изключат от мрежата, ако актуализацията не е възможна веднага.

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

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

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

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

- Описваме всички PHP манипулатори на Вашия Plesk сървър, свързваме ги с домейните и проверяваме действителното състояние на пакетите за всяка версия.
- В рамките на нашата [услуга за PHP пач](https://phpsos.de/bg/leistungen/php-patch-service/) внасяме актуализациите, рестартираме всички услуги и документираме времето на стартиране на процесите като доказателство.
- Където пач липсва, прилагаме временните мерки по php.net за целия сървър и по начин, по който не могат да бъдат презаписани.
- Запазваме логовете и търсим следи от компрометиране, а при находка го правим заедно с [Incident Response](https://phpsos.de/bg/leistungen/incident-response/).
- След това укрепваме сървъра трайно и премахваме ненужните версии на PHP.


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

**Защо Plesk показва PHP 8.2.34 и след актуализацията?**  
Дистрибуциите и доставчиците понякога внасят корекциите за сигурност като бекпорт, без да променят номера на версията. Тогава от значение са състоянието на пакета и потвърждението на доставчика. Само показаното не доказва нито че има пач, нито че го няма.

**Достатъчно ли е да щракнете върху Актуализиране в панела на Plesk?**  
Актуализацията записва нови файлове, но работещите PHP процеси продължават да работят със стария код в паметта. Новото състояние е активно едва след рестартиране на всички PHP-FPM услуги и на уеб сървъра. След това проверете времето на стартиране на процесите.

**Трябва ли да пачвам и версии на PHP, които никой домейн не ползва?**  
Да, стига да останат инсталирани. Неизползван манипулатор може по-късно да бъде зададен по погрешка или да е достъпен чрез тестови среди. Версиите, от които не се нуждаете, е по-добре да се деинсталират изцяло.

**Помага ли актуализация на WordPress в Plesk Toolkit срещу PHP2Shell?**  
Не. PHP2Shell засяга самия PHP, а не CMS. Актуализацията на CMS все пак е полезна, но не затваря тази уязвимост.

## Източници

- [php.net: Съобщения за сигурност](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [php.net: Поддържани версии](https://www.php.net/supported-versions.php)
- [BSI](https://www.bsi.bund.de/)