# Потвърждение от хостинг доставчика за PHP актуализацията: как да попитате за състоянието на пача

> Как да получите от хостинг доставчика надеждно потвърждение за PHP актуализацията след PHP2Shell: кои данни са важни, шаблон, оценка на отговора.

Източник: https://phpsos.de/bg/ratgeber/hoster-patch-status-erfragen/  
Актуалност: 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

**Накратко:** След PHP2Shell само показаната версия на PHP доказва малко, защото хостинг доставчиците често внасят корекциите като backport. Затова поискайте писмено потвърждение от хостинг доставчика за PHP актуализацията: състояние на пакета за всеки клон на PHP, момент на инсталирането и рестарт на всички PHP процеси. Шаблон за копиране ще намерите по-долу.

## Защо именно сега писменото потвърждение има значение

На 21.10.2026 проектът PHP публикува пачовете за две критични уязвимости, известни под името PHP2Shell. И двете позволяват отдалечено изпълнение на злонамерен код без вход в системата. BSI (Федералната служба за информационна сигурност на Германия) обяви ниво на предупреждение 3 / оранжево и препоръчва незабавна актуализация.

Който поддържа уебсайта си при хостинг доставчик, често не може сам да внесе актуализацията. В същото време като оператор носите отговорност за данните на Вашите клиенти. Затова писмено, конкретно потвърждение от хостинг доставчика е нещо повече от формалност. То е елемент на Вашата документация, например пред длъжностните лица по защита на данните, застрахователите или ръководството.

Освен това: пачът не премахва зловреден софтуер, внедрен преди него. Според медийни съобщения още на 17.10. е наблюдаван първи опит за атака. Затова точният момент, от който сървърът Ви е бил защитен, е важен за въпроса дали трябва да проверявате по-нататък.

## Защо показаната версия на PHP не е достатъчна

Поправени са PHP 8.5.12, 8.4.27, 8.3.36 и 8.2.35. Много дистрибуции и хостинг доставчици обаче включват корекцията като backport в собствения си пакет. Тогава интерфейс като Plesk продължава да показва 8.2.34, въпреки че сървърът е пачнат.

Обратно, и правилен номер на версия може да подведе. Новите файлове сами по себе си не защитават, докато стари PHP процеси работят в паметта. Новото състояние е активно едва след рестарт на всички worker процеси. Повече по темата в статията [Как да проверите правилно версията на PHP и състоянието на пача](https://phpsos.de/bg/php2shell/php-version-pruefen/).

| Твърдение на хостинг доставчика | Какво доказва | Какво още липсва |
|---|---|---|
| „Всички системи са актуални.“ | малко | Версия или състояние на пакета, дата, рестарт |
| „PHP 8.3.36 е инсталиран.“ | Версия | Дата, рестарт, засегнати сървъри |
| „Backport в пакета xy, рестарт на …“ | Пач и активиране | при нужда данни за PHP 8.1 и по-стари |

## Какви данни са Ви нужни от хостинг доставчика

Поискайте отговори на тези точки, по възможност за всеки уебсайт или договор:

- Кои клонове и версии на PHP са активни за Вашите уебсайтове, включително по-старите, които работят само за отделни директории?
- Включени ли са корекциите за CVE-2026-109618 и CVE-2026-109619, като официална версия или като backport?
- Кога е инсталирана актуализацията и кога са рестартирани всички PHP процеси (FPM пулове, Apache, LiteSpeed)?
- Деактивирана ли е `session.upload_progress.enabled` заради CVE-2026-115560?
- Какъв режим на работа ползва Вашият тарифен план, например PHP-FPM или Apache с mod_php? При mod_php екипът на PHP вижда най-висок риск.
- Кои логове за достъп и грешки от 20.10.2026 се съхраняват и как можете да ги получите?

Ако уебсайт още работи на PHP 8.1 или по-стар, попитайте отделно. За тези клонове вече няма официални актуализации, а само минимални backport корекции на изходния код за 7.4, 8.0 и 8.1.

## Шаблон: поискайте потвърждение от хостинг доставчика за PHP актуализацията

Копирайте текста в заявка към поддръжката или в имейл до Вашия хостинг доставчик. Допълнете данните в квадратните скоби.

```text
Тема: Молба за потвърждение за състоянието на пача на PHP (PHP2Shell, CVE-2026-109618 / CVE-2026-109619)

Добър ден,

при Вас поддържаме следните уебсайтове / договори:
[клиентски номер, договор, домейни]

във връзка с уязвимостите в PHP CVE-2026-109618 и
CVE-2026-109619 (PHP2Shell, пачове от 21.10.2026) както и със
съобщението за CVE-2026-115560 от 23.10.2026 Ви молим за писмено
потвърждение по следните въпроси:

1. Кои версии на PHP, респективно състояния на пакетите, са активни за нашите уебсайтове?
2. Включват ли те корекциите (официална версия или backport)?
3. Дата и час на инсталирането.
4. Дата и час на рестарта на всички PHP процеси (FPM, Apache,
   LiteSpeed или подобни).
5. Деактивирана ли е session.upload_progress.enabled на ниво сървър?
6. Какъв режим на работа на PHP се използва (напр. PHP-FPM, mod_php)?
7. Съхраняват ли се логовете за достъп и грешки от 20.10.2026 и
   как можем да ги получим?
8. Ако някой уебсайт още ползва PHP 8.1 или по-стар: каква защита
   има там и какъв преход препоръчвате?

Данните са ни нужни за нашата вътрешна документация.

Благодарим Ви и поздрави
[Име, фирма, длъжност]
```

## Как да оцените правилно отговора и да го проверите сами

Добрият отговор назовава конкретни състояния, дати и часове. Общи формулировки като „реагирахме“ не са достатъчни за Вашето досие. В такъв случай учтиво попитайте за липсващите точки.

Ако тарифният Ви план позволява, проверете допълнително и сами. С достъп по SSH обикновено са достатъчни тези команди:

```bash
# Версия на командния ред (може да се различава от уеб версията)
php -v
# Състояние на пакета при Debian/Ubuntu
dpkg -l | grep -E "php[0-9.]*-(fpm|cli|common)"
# Състояние на пакета при RHEL, Alma, Rocky
rpm -qa | grep -i php
# Откога работят PHP-FPM процесите?
ps -eo pid,lstart,cmd | grep "[p]hp-fpm"
```

Ако моментът на стартиране на PHP процесите е преди потвърдената дата на инсталиране, рестартът не е бил пълен.

### Ако хостинг доставчикът не отговаря или отговаря уклончиво

Ако отговорът липсва или решаващите данни не достигат, не трябва да смятате положението за изяснено. BSI препоръчва уеб сървърите да се изключат временно от мрежата, когато актуализацията не е възможна веднага. Дали това е пропорционално за Вашия уебсайт, решава ръководството, в идеалния случай писмено и с дата.

Паралелно си струва да потърсите възможни следи от атака, защото моментът на пача остава неизяснен. Опорни точки дава статията [Вече компрометиран ли съм?](https://phpsos.de/bg/php2shell/bin-ich-gehackt-anzeichen/). Без достъп по SSH писменото потвърждение остава най-важното Ви доказателство. Какви задължения има хостинг доставчикът и какви Вие, обяснява страницата [Споделен хостинг: какво прави хостинг доставчикът](https://phpsos.de/bg/server/shared-hosting/); за поддържани сървъри помага [Managed сървър: изясняване на отговорността](https://phpsos.de/bg/server/managed-server/).

> **Съвет:**
> Съхранявайте запитването, отговора и собствените си резултати от проверките с дата в една папка. Това досие по-късно помага при въпроси от застрахователи или длъжностни лица по защита на данните.

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

- Заедно с Вас формулираме запитването до хостинг доставчика и оценяваме отговора от професионална гледна точка.
- Където има достъп, сами проверяваме състоянието на пакета, активния режим на работа и рестарта на PHP процесите.
- Ако остават пропуски, въвеждаме преходни мерки или планираме преминаването към поддържана версия.
- Фиксираме резултата и моментите във вид на доказателство, което можете да предадете вътрешно.

Как протича актуализацията с рестарт и доказателство, описва нашата [услуга за пачване на PHP](https://phpsos.de/bg/leistungen/php-patch-service/).


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

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

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

**Какво да направя, ако хостинг доставчикът не отговаря?**  
Документирайте запитването си с дата и след разумен срок попитайте отново. Проверете паралелно дали можете сами да въведете преходни мерки и се съгласувайте с ръководството дали уебсайтът да бъде изключен от мрежата до изясняването, както BSI препоръчва за непачнати сървъри.

**Затваря ли уязвимостта и актуализация на WordPress или на магазинния софтуер?**  
Не. PHP2Shell е в самия PHP. Актуализацията на CMS или на магазинния софтуер не променя нищо в интерпретатора на PHP, който работи на сървъра.

## Източници

- [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/)