Накратко: PHP2Shell са две критични уязвимости в самия PHP, чрез които атакуващите могат да изпълняват злонамерен код без удостоверяване. Ако Ви е нужна бърза помощ при тази уязвимост в PHP, ние поемаме отдалечено описа, пачването или временната мярка, рестартирането на всички PHP процеси и първото търсене на следи. Накрая получавате писмено доказателство за състоянието.
Помощ при уязвимост в PHP: защо трябва да се действа сега
На 21.10.2026 г. в 16 ч. германско време проектът PHP публикува пачове за CVE-2026-109618 и CVE-2026-109619. И двете уязвимости са оценени с CVSS v4.0 9,2 и позволяват отдалечено изпълнение на злонамерен код, без никой да трябва да се удостоверява. Засегнати са обичайните режими на работа: PHP-FPM, Apache с mod_php, php-cgi, FrankenPHP и LiteSpeed.
BSI (Федералната служба за информационна сигурност на Германия) обяви ниво на предупреждение 3 (оранжево). Препоръчва незабавна актуализация, а когато това не е възможно веднага, уеб сървърите да бъдат временно изключени от мрежата. Palo Alto Networks (Unit 42) преброи над 22,6 милиона изложени на риск, потенциално уязвими инстанции. Потвърдени успешни атаки в голям мащаб според BSI отначало не са били известни, но Cloudflare вече съобщаваше за опити за атака.
За управителите и собствениците това означава: всеки публично достъпен PHP сървър е кандидат, докато не се докаже обратното. Разбираемо обяснение на уязвимостта ще намерите на страницата Какво е PHP2Shell?.
За кого е предназначена спешната помощ при PHP2Shell?
За фирми, агенции и публични институции, които ползват PHP приложения и не могат или не искат сами да овладеят положението в необходимата дълбочина. Това се отнася за собствени root сървъри и vServer-и, както и за сървъри с Plesk или cPanel, контейнерни среди и управлявани сървъри, при които отговорността е неясна.
Дори който има хостинг доставчик, често има нужда от подкрепа. Много доставчици внасят backport-ове; тогава например Plesk продължава да показва 8.2.34, въпреки че пакетът е с поправка. Обратно, може да се показва нов номер на версията, докато стари PHP процеси още работят в паметта. Кои състояния се смятат за поправени, е описано на страницата Кои PHP версии са засегнати?.
Как помага PHP SOS конкретно?
- Опис: Събираме всички PHP инсталации, режими на работа и версии на Вашите сървъри, включително състоянието на пакетите и работещите процеси. Резултатът е списък кои системи са засегнати, поправени или неясни.
- Пач или временна мярка: Където е възможно, внасяме поправените версии (8.5.12, 8.4.27, 8.3.36, 8.2.35) или пакетите на Вашата дистрибуция. Ако това не е възможно веднага, прилагаме временните мерки според php.net и казваме открито, че те не дават пълна защита.
- Рестартиране и контрол: Рестартираме всички PHP worker и процеси и след това проверяваме, че не работи нито един стар процес. Новите файлове сами по себе си не затварят уязвимостта.
- Първо търсене на следи: Запазваме сървърните логове от 20.10. нататък и търсим необичайни неща като нови PHP файлове, непознати cron задачи или нетипични процеси. Тъй като няма публикувани, потвърдени Indicators of Compromise, тази проверка се основава на анализ на поведението.
- Доказателство и следващи стъпки: Получавате писмен доклад. При съмнение за компрометиране препоръчваме подходящите следващи стъпки, например премахване на злонамерен софтуер или съдебно-техническо (форензично) разследване.
Пачът не премахва вече внедрен злонамерен софтуер и не доказва, че преди това нищо не е станало. Затова към спешната помощ винаги спада поглед към периода от 17.10.2026 г. насам.
Какво получавате от нас
- преглед на всички проверени сървъри с PHP версия, състояние на пакетите, режим на работа и статус на пача
- документация на внесените актуализации или на приложените временни мерки
- доказателство, че всички PHP процеси са рестартирани
- оценка на търсенето на следи, разграничена на доказано, вероятно и неизвестно
- списък с неуредените въпроси, например системи с PHP 8.1 или по-стар
Този доклад можете да предадете на управителите, на длъжностното лице по защита на данните или на застрахователя. Той не замества правната оценка.
Какво ни е нужно от Вас
- Достъп: SSH или достъп до панела с достатъчни права, като алтернатива разрешение хостинг доставчикът да ни дава информация
- Лице за контакт: човек, който има право да взема решения, например за кратка работа офлайн или за рестартиране
- Преглед: кои уебсайтове, магазини и приложения на кои сървъри работят
- Прозорец за поддръжка: Вашите изисквания кога могат да се правят рестартирания
- Резервни копия: информация къде се намират актуалните архиви
Администраторите, които искат предварително да проверят сами, често имат достатъчно този безопасен поглед към състоянието:
php -v
# Debian/Ubuntu: инсталирани PHP пакети с версия
dpkg -l | grep -i php
# работещи PHP процеси и времето на тяхното стартиране
ps -eo pid,lstart,cmd | grep -i php
Какво не обещаваме
Не обещаваме абсолютна сигурност, нито твърдение, че сървърът Ви никога не е бил атакуван, когато доказателствата не го позволяват. Работим по инцидента, докато той бъде приключен и документиран. Дали има задължение за уведомяване по ОРЗД или трябва да се информира застрахователят, изяснете с длъжностното лице по защита на данните, адвокат или застраховател. Ние предоставяме техническите факти за това.
Ако Ви е нужна само актуализацията с доказателство, подходяща е нашата услуга за пач на PHP. Ако вече има признаци за атака, правилният вход е спешната помощ при хакнат уебсайт.
Често задавани въпроси
Достатъчно ли е, че хостинг доставчикът ми е актуализирал PHP?
Може да е достатъчно, ако хостинг доставчикът потвърди писмено състоянието на пакета и всички PHP процеси са рестартирани. Показаният номер на версията сам по себе си не е доказателство, защото дистрибуциите внасят backport-ове. Дали сървърът е бил атакуван преди това, пачът така или иначе не показва.
Трябва ли уебсайтът ми да бъде изключен за спешната помощ?
Не непременно. BSI препоръчва уеб сървърите да се изключват временно от мрежата, когато актуализацията не е възможна веднага. Дали това е нужно при Вас, решаваме заедно след описа.
Предпазва ли актуализация на WordPress или Shopware от PHP2Shell?
Не. PHP2Shell е в самия PHP, а не в CMS. Актуализацията на CMS остава разумна, но тази уязвимост не затваря.
Какво се случва при PHP 8.1 или по-стар?
За тези версии проектът PHP вече не издава официални актуализации, а само минимални backport-ове на изходния код за 7.4, 8.0 и 8.1. Защитаваме сървъра временно и заедно с Вас планираме преминаване към поддържана версия.