# Пач, изключване или изчакване? Помощ при решението за PHP уязвимостта

> Да изключите ли уебсайта заради PHP уязвимостта? Помощ при избора между пач, изключване и изчакване, с критерии, последователност и честни граници.

Източник: https://phpsos.de/bg/blog/patchen-abschalten-abwarten/  
Актуалност: 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 уязвимостта, зависи от един въпрос: работи ли PHP на този сървър доказано на коригирана версия и рестартирани ли са всички процеси? Ако да, изключване не е нужно. Ако ъпдейтът не може да се инсталира веднага, BSI (Федералната служба за информационна сигурност на Германия) препоръчва уеб сървърът да бъде временно изключен от мрежата. Изчакването е допустимо само ако системата не използва PHP, не е публично достъпна или доставчикът е потвърдил писмено пача.

## Положението, в което трябва да решавате

PHP2Shell обхваща две уязвимости в самия PHP, CVE-2026-109618 и CVE-2026-109619, и двете оценени с CVSS v4.0 9,2. Те позволяват изпълнение на зловреден код отдалечено без вход. Коригирани версии са налични от 21.10.2026 г.: 8.5.12, 8.4.27, 8.3.36 и 8.2.35. За PHP 8.1 и по-стари вече няма официални ъпдейти.

BSI обяви предупредително ниво оранжево и съветва незабавен ъпдейт, а като заместител временно изключване. Според медийни съобщения град Майнц, звена на правителството на провинция Хесен и други публични институции предпазно са изключили уебсайтове; държавната канцелария на Хесен не съобщи за атака. Какво могат да извлекат фирмите от това, е описано в [Ведомствата изключват уебсайтове от мрежата](https://phpsos.de/bg/blog/behoerden-webseiten-offline/).

За отговорните във фирмите въпросът е по-практичен: какво правим с нашия магазин, с нашия портал, с фирмения ни уебсайт днес?

## Изключване на уебсайта, пач или изчакване: трите варианта в сравнение

Следната таблица поставя вариантите един до друг. Тя не замества оценката на Вашия конкретен случай, но прави преценката видима.

| Критерий | Пач веднага | Временно изключване | Изчакване |
|---|---|---|---|
| Защита от PHP2Shell | Висока, ако пачът и рестартът са доказани | Висока за времето на изключването | Никаква, докато не е пачнато |
| Прекъсване на дейността | Кратко, за ъпдейт и рестарт | От часове до дни | Няма |
| Предпоставка | Поддържана версия на PHP, достъп, прозорец за поддръжка | Решение на управителя, статична заместваща страница | Доказана причина, поради която няма риск |
| Усилия | Малки до средни | Малки технически, големи организационно | Малки, но усилия за проверка на доказателството |
| Типичен случай | Сървър с PHP 8.2 до 8.5 | Стара система с PHP 8.1 или по-стар, неясно състояние | Система без PHP или достъпна само вътрешно |
| Остатъчен риск | Предишно проникване остава възможно | Предишно проникване остава възможно | Напълно налице |

Един ред заслужава внимание: нито пачът, нито изключването изясняват дали вече не се е случило нещо. Според медийни съобщения първият наблюдаван опит за атака е бил на 17.10.2026 г., тоест преди пача. Затова поглед към възможни следи спада към всеки вариант.

## С пет въпроса към решението

Преминете през въпросите по ред. Първият ясен отговор обикновено води до решението.

1. **Работи ли изобщо PHP на системата и достъпна ли е от интернет?** Ако не, системата не е пряко засегната от PHP2Shell. Документирайте как сте го установили.
2. **Доказано ли е състоянието на пача?** Доказано означава: коригирана версия или backport с номера на CVE в changelog-а на пакета и рестарт на всички PHP процеси. Показването на версията в панела не стига. Как да го проверите, е описано в [Как да проверите правилно версията на PHP и състоянието на пача](https://phpsos.de/bg/php2shell/php-version-pruefen/).
3. **Може ли ъпдейтът да се инсталира през следващите часове?** Ако да: пачвате, рестартирате, контролирате. Дотогава могат да помогнат временни мерки.
4. **Невъзможно ли е това, например поради PHP 8.1 или липсващ достъп?** Тогава временното изключване е според BSI пътят. Временните мерки според php.net намаляват риска, но не защитават напълно; подробности има в [Спешни мерки, когато още не можете да пачвате](https://phpsos.de/bg/php2shell/sofortmassnahmen-ohne-patch/).
5. **Има ли признаци за компрометиране?** Тогава въпросът вече не е „пач или изключване“, а „обработка на инцидент“. Изключване, запазване на доказателства, не се трие прибързано.

## Когато изключвате: изключете правилно

Изключването трябва да премахне повърхността за атака, а не само да скрие началната страница. Страница за поддръжка, която продължава да се генерира от PHP, не изпълнява тази цел. По-добре е статична HTML страница, която уеб сървърът обслужва без PHP, или пренасочване към друг сървър.

Мислете за всичко, което е окачено на същия PHP: подстраници, интерфейси за приложения или управление на стоки, администраторски зони, обратни извиквания на плащания. Говорете предварително с платежния доставчик и логистиката, ако е засегнат магазин. И информирайте служителите и клиентите на ясен език: страницата е предпазно офлайн, контактът минава по телефон и имейл. Това е по-добре от мълчанието, което подхранва спекулации.

Важен е и краят на изключването. Определете при какво условие страницата отново се връща онлайн, например „PHP на коригирано състояние, рестартът контролиран, първата проверка за следи без находки“. Така от аварийна спирачка се получава подреден процес.

> **Важно:**
> Изключването не е поражение. Няколко публични институции според медийни съобщения направиха точно това, без да е имало атака. Предпазното изключване не означава автоматично, че уебсайтът е хакнат.

## Кога не Ви трябва доставчик

Не всяко решение изисква външна помощ. Ако Вашият уебсайт е при хостинг доставчик, който потвърждава писмено състоянието на пача и рестарта, и няма необичайни неща, с кратка документация сте добре подготвени. Същото важи, ако Вашето собствено ИТ може само да пачне сървър с поддържана версия на PHP и владее контрола.

Помощта си струва, когато работят системи със стара версия на PHP, състоянието е неясно, засегнати са няколко сървъра или има признаци за проникване.

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

1. Изясняваме с Вас за кратко време кои системи са засегнати и кое състояние на пача е доказано.
2. Предоставяме на управителя основа за решение на една страница: варианти, рискове, препоръчан път.
3. Изпълняваме избрания път, тоест пач с рестарт, временни мерки или чисто изключване със статична заместваща страница, като част от нашата [Спешна помощ при PHP2Shell](https://phpsos.de/bg/leistungen/php2shell-soforthilfe/).
4. Проверяваме за следи от 17.10.2026 г. нататък и документираме резултата.

## Извод

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


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

**Трябва ли да изключа уебсайта си заради PHP2Shell?**  
Не, ако PHP вече работи на коригирана версия и всички процеси са рестартирани. BSI (Федералната служба за информационна сигурност на Германия) препоръчва временно изключване за случая, когато незабавен ъпдейт не е възможен.

**Какво струва повече при изключване: оборотът или рискът?**  
Това може да се отговори само за конкретния случай. Прекъсване от няколко часа обикновено се планира по-добре от проникване, чиито последици и продължителност никой не познава. Запишете преценката писмено, независимо как завършва.

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

**Изчакването някога верният избор ли е?**  
Да, в ясно очертани случаи: когато на системата не работи PHP, когато тя не е достъпна от интернет или когато доставчикът е потвърдил писмено пача и рестарта. Изчакване без такива доказателства не е вариант, а риск.

**Кой трябва да вземе решението?**  
Лицето, което носи бизнес риска, по правило управителят или собственикът. ИТ предоставя фактите. Кой решава, трябва да е записано предварително в плана за извънредни ситуации.

## Източници

- [BSI: Предупреждение за PHP2Shell](https://www.bsi.bund.de/)
- [php.net: Съобщения за сигурност](https://www.php.net/)
- [hessenschau: Уебсайтове на институции в Хесен изключени](https://www.hessenschau.de/panorama/sicherheitsluecke-zahlreiche-behoerden-webseiten-in-hessen-abgeschaltet-v2,sicherheitsprobleme-hacker-webseiten-100.html)
- [ZDFheute: Уязвимост в PHP](https://zdfheute.de/politik/sicherheitsluecke-php-webseiten-onlinedienste-cybersicherheit-bsi-100.html)