# Затворете уязвимостта в PHP веднага

> Уязвимостта в PHP още е отворена? Пачваме отдалечено, рестартираме всички процеси и доказваме резултата. Обадете се или пишете по WhatsApp.

Източник: https://phpsos.de/bg/soforthilfe/php-luecke-sofort-schliessen/  
Актуалност: 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 да бъде затворена още днес, се нуждае от четири неща: правилната актуализация, рестартиране на всички PHP процеси, проверка за вече внедрен зловреден код и доказателство. Засегнати ли сте? Обадете се. Помагаме Ви. Поемаме го отдалечено, от първото съобщение.

> **Действайте веднага:**
> **Сега не трийте нищо и не инсталирайте наново.** И при пачването важи: първо запазване, после промяна. Ако вече е проникнало нещо, ни е нужно състоянието на файловете и логовете. [Съобщете за спешен случай](https://phpsos.de/bg/notfall/) и ще уточним с Вас последователността.

## Защо уязвимостта не може да чака

Двете уязвимости CVE-2026-109618 и CVE-2026-109619 са в самия PHP и позволяват зловреден код от разстояние без вход в системата. BSI обяви ниво на предупреждение 3 (оранжево) и препоръчва незабавна актуализация. Ако това не е възможно веднага, уеб сървърите следва да се изключат временно от мрежата. Според медийни съобщения първи опити за атака са наблюдавани още преди публикуването на пачовете на 21.10.2026 г. Cloudflare е наблюдавала опити и е пуснала защитни правила, но предупреждава, че правила, базирани само на данните от заявката, не са достатъчни.

Важно за операторите: актуализация на CMS не затваря уязвимостта в PHP. Според съобщения и WordPress.org не планира актуализация срещу нея, защото уязвимостта е в интерпретатора. Тя се затваря само на ниво PHP, т.е. при онова, което Вашият сървър реално изпълнява.

## Какво да направите веднага

1. **Знайте целевата версия.** Коригирани са PHP 8.5.12, 8.4.27, 8.3.36 и 8.2.35. PHP 8.2 достига на 31.12.2026 г. края на поддръжката – планирайте и това.
2. **Опишете всички системи.** Включително тестови сървъри, образи на контейнери и стари системи, достъпни от интернет.
3. **Изяснете отговорността.** При хостинг пакети и управлявани сървъри (managed) се занимава доставчикът. Питайте писмено за версията и рестартирането.
4. **Запазете логовете.** От 20.10.2026 г. нататък, според специализираната преса.
5. **Съгласувайте прозореца.** Рестартирането прекъсва за кратко текущите заявки. Определете момент, в който някой може да взема решения.
6. **Не чакайте, ако е отворено.** Ако не може да се пачва веднага, обсъдете с нас изолирането или преходните мерки.

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

1. **Преглед на положението:** Описваме системите, версиите на PHP, режимите на работа, хостинг доставчиците и достъпността и определяме реда: първо най-изложените системи.
2. **Запазване и затваряне:** Запазваме текущото състояние, инсталираме актуализацията или довеждаме хостинга до доказано коригираното състояние и рестартираме всички процеси. При контейнери изграждаме образа наново и го разгръщаме.
3. **Проверка и почистване:** Тъй като пачът не премахва зловреден код, проверяваме за признаци за по-ранно проникване и при нужда почистваме.
4. **Заздравяване и отчет:** Получавате писмено доказателство за всяка система и препоръки, за да върви следващата актуализация по-бързо. Обхватът на услугата описва [Услугата за PHP пачове](https://phpsos.de/bg/leistungen/php-patch-service/).

## Актуализация, рестартиране, доказателство: какво е важно

Най-честата грешка е актуализация без рестартиране. Докато стари процеси работят в паметта, уязвимият код остава активен, дори файловете да са нови. Ръководството за това е на страницата [Рестартиране на PHP-FPM и на всички worker процеси](https://phpsos.de/bg/php2shell/php-fpm-neustart/). Втората грешка е да се вярва на показаното: дистрибуциите и хостинг доставчиците често доставят backport и тогава номерът на версията остава същият. Надежден е changelog на пакета с номерата на CVE, при семейството на Debian с `apt-get changelog <paket>`.

Освен това според наръчника на PHP от изданията за сигурност насам важи новата директива `memory_hard_limit_percent`. Ако една версия на PHP не я познава, тя е засегната. Тестът е кратък:

```bash
php -r 'var_dump(ini_get("memory_hard_limit_percent"));'
```

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

## Ако актуализацията не е възможна веднага

Има причини актуализацията да не е възможна днес: старо приложение, което не работи с по-нови версии на PHP, хостинг доставчик без разрешение, образ на контейнер във фиксиран конвейер. За тези случаи php.net посочва преходни мерки, които изрично не са пълна защита: `memory_limit=-1`, зададен така, че приложенията да не могат да го презапишат, ограничаване на `post_max_size`, `session.upload_progress.enabled=0` и при PHP 8.5 `fatal_error_backtraces=0`, всяка с рестартиране. Към това се добавят защитни правила в периферията, които не заместват актуализацията. Разпространяван съвет да се блокират всички заявки с `PHPSESSID` изрично се отхвърля от специализирани автори.

Кои мерки подхождат на Вашата система и какво могат да счупят, обсъждаме предварително. Повече по темата има на страницата [Незабавни мерки, когато още не можете да пачвате](https://phpsos.de/bg/php2shell/sofortmassnahmen-ohne-patch/) и в темата [WAF и виртуално пачване](https://phpsos.de/bg/leistungen/waf-virtuelles-patching/). За PHP 8.1 и по-стари важи отделно положение, описано в [PHP 8.1 и по-стари: Какво важи сега](https://phpsos.de/bg/php2shell/php-8-1-und-aelter/).

## Какво да ни изпратите

- Списък на сървърите и хостинг доставчиците, доколкото го има
- Изход от `php -v` за всяка система и указание за режима на работа
- Информация дали се ползват контейнери, Plesk, cPanel или управлявано (managed) предложение
- желан времеви прозорец и лице за контакт за рестартиранията
- Указания за нередности от 17.10.2026 г. насам

## Защо PHP SOS

Работим Made in Germany и от над 25 години със своята партньорска мрежа от кибер специалисти сме специализирани в ИТ сигурността. Имате един партньор за контакт, който съпровожда актуализацията, проверява рестартирането и предоставя доказателството. Работим отдалечено, без пътуване, и документираме всяка стъпка. Не обещаваме чудеса: пачът затваря уязвимостта, но не доказва, че преди това нищо не се е случило, и това също ще Ви го кажем.

## Засегнати ли сте? Обадете се. Помагаме Ви.

Не оставяйте уязвимостта отворена по-дълго. Обадете се или пишете по WhatsApp. Поемаме от първото съобщение и оставаме до приключването и документирането на инцидента. [Съобщете за спешен случай сега](https://phpsos.de/bg/notfall/).


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

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

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

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

**Достатъчно ли е session.upload_progress.enabled да се зададе на 0?**  
Не. Според специализирани доклади настройката сама по себе си не затваря и двете уязвимости; актуализацията на PHP остава задължителна. Задавайте я само в php.ini, в FPM пула или в конфигурацията на сървъра, не чрез ini_set() или .user.ini.

**Откъде да знам, че след това уязвимостта наистина е затворена?**  
С доказателство на работещата система: версия или changelog на пакета, тест за новата директива memory_hard_limit_percent и потвърждение, че всички процеси са рестартирани след актуализацията.

## Източници

- [php.net: Съобщения за сигурност](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [Наръчник на PHP: Основна конфигурация (ini.core)](https://www.php.net/manual/en/ini.core.php)
- [BSI: Федерална служба за информационна сигурност на Германия](https://www.bsi.bund.de/)