Накратко: Който иска уязвимостта PHP2Shell в PHP да бъде затворена още днес, се нуждае от четири неща: правилната актуализация, рестартиране на всички PHP процеси, проверка за вече внедрен зловреден код и доказателство. Засегнати ли сте? Обадете се. Помагаме Ви. Поемаме го отдалечено, от първото съобщение.
Сега не трийте нищо и не инсталирайте наново. И при пачването важи: първо запазване, после промяна. Ако вече е проникнало нещо, ни е нужно състоянието на файловете и логовете. Съобщете за спешен случай и ще уточним с Вас последователността.
Защо уязвимостта не може да чака
Двете уязвимости CVE-2026-109618 и CVE-2026-109619 са в самия PHP и позволяват зловреден код от разстояние без вход в системата. BSI обяви ниво на предупреждение 3 (оранжево) и препоръчва незабавна актуализация. Ако това не е възможно веднага, уеб сървърите следва да се изключат временно от мрежата. Според медийни съобщения първи опити за атака са наблюдавани още преди публикуването на пачовете на 21.10.2026 г. Cloudflare е наблюдавала опити и е пуснала защитни правила, но предупреждава, че правила, базирани само на данните от заявката, не са достатъчни.
Важно за операторите: актуализация на CMS не затваря уязвимостта в PHP. Според съобщения и WordPress.org не планира актуализация срещу нея, защото уязвимостта е в интерпретатора. Тя се затваря само на ниво PHP, т.е. при онова, което Вашият сървър реално изпълнява.
Какво да направите веднага
- Знайте целевата версия. Коригирани са PHP 8.5.12, 8.4.27, 8.3.36 и 8.2.35. PHP 8.2 достига на 31.12.2026 г. края на поддръжката – планирайте и това.
- Опишете всички системи. Включително тестови сървъри, образи на контейнери и стари системи, достъпни от интернет.
- Изяснете отговорността. При хостинг пакети и управлявани сървъри (managed) се занимава доставчикът. Питайте писмено за версията и рестартирането.
- Запазете логовете. От 20.10.2026 г. нататък, според специализираната преса.
- Съгласувайте прозореца. Рестартирането прекъсва за кратко текущите заявки. Определете момент, в който някой може да взема решения.
- Не чакайте, ако е отворено. Ако не може да се пачва веднага, обсъдете с нас изолирането или преходните мерки.
Как конкретно помага PHP SOS?
- Преглед на положението: Описваме системите, версиите на PHP, режимите на работа, хостинг доставчиците и достъпността и определяме реда: първо най-изложените системи.
- Запазване и затваряне: Запазваме текущото състояние, инсталираме актуализацията или довеждаме хостинга до доказано коригираното състояние и рестартираме всички процеси. При контейнери изграждаме образа наново и го разгръщаме.
- Проверка и почистване: Тъй като пачът не премахва зловреден код, проверяваме за признаци за по-ранно проникване и при нужда почистваме.
- Заздравяване и отчет: Получавате писмено доказателство за всяка система и препоръки, за да върви следващата актуализация по-бързо. Обхватът на услугата описва Услугата за PHP пачове.
Актуализация, рестартиране, доказателство: какво е важно
Най-честата грешка е актуализация без рестартиране. Докато стари процеси работят в паметта, уязвимият код остава активен, дори файловете да са нови. Ръководството за това е на страницата Рестартиране на PHP-FPM и на всички worker процеси. Втората грешка е да се вярва на показаното: дистрибуциите и хостинг доставчиците често доставят backport и тогава номерът на версията остава същият. Надежден е changelog на пакета с номерата на CVE, при семейството на Debian с apt-get changelog <paket>.
Освен това според наръчника на PHP от изданията за сигурност насам важи новата директива memory_hard_limit_percent. Ако една версия на PHP не я познава, тя е засегната. Тестът е кратък:
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 изрично се отхвърля от специализирани автори.
Кои мерки подхождат на Вашата система и какво могат да счупят, обсъждаме предварително. Повече по темата има на страницата Незабавни мерки, когато още не можете да пачвате и в темата WAF и виртуално пачване. За PHP 8.1 и по-стари важи отделно положение, описано в PHP 8.1 и по-стари: Какво важи сега.
Какво да ни изпратите
- Списък на сървърите и хостинг доставчиците, доколкото го има
- Изход от
php -vза всяка система и указание за режима на работа - Информация дали се ползват контейнери, Plesk, cPanel или управлявано (managed) предложение
- желан времеви прозорец и лице за контакт за рестартиранията
- Указания за нередности от 17.10.2026 г. насам
Защо PHP SOS
Работим Made in Germany и от над 25 години със своята партньорска мрежа от кибер специалисти сме специализирани в ИТ сигурността. Имате един партньор за контакт, който съпровожда актуализацията, проверява рестартирането и предоставя доказателството. Работим отдалечено, без пътуване, и документираме всяка стъпка. Не обещаваме чудеса: пачът затваря уязвимостта, но не доказва, че преди това нищо не се е случило, и това също ще Ви го кажем.
Засегнати ли сте? Обадете се. Помагаме Ви.
Не оставяйте уязвимостта отворена по-дълго. Обадете се или пишете по WhatsApp. Поемаме от първото съобщение и оставаме до приключването и документирането на инцидента. Съобщете за спешен случай сега.
Често задавани въпроси
Мога ли сам да затворя уязвимостта в 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 и потвърждение, че всички процеси са рестартирани след актуализацията.