Накратко: Който сам управлява root сървър или vServer, трябва след PHP2Shell сам да го и обезопаси: да доведе PHP пакетите до коригирано състояние, да рестартира всички PHP процеси и да провери резултата. Операторът на центъра за данни по правило се грижи само за хардуера, виртуализацията и мрежата. След това си струва сървърът да се укрепи трайно.
Вашата отговорност при собствен сървър
При неуправляван root сървър или vServer наемате изчислителна мощ, а не обслужване. Операционната система, уеб сървърът, PHP, базата данни, защитната стена, резервните копия и наблюдението са във Ваши ръце. За ръководството и собствениците това означава: ако никой във фирмата или при външен доставчик на услуги не е поел изрично тези задачи, никой не ги изпълнява.
PHP2Shell го прави видимо. Двете уязвимости CVE-2026-109618 и CVE-2026-109619 са в самия PHP и позволяват изпълнение на код без вход в системата. Проектът PHP публикува на 21.10.2026 г. версиите 8.5.12, 8.4.27, 8.3.36 и 8.2.35. BSI (Федерална служба за информационна сигурност на Германия) препоръчва незабавна актуализация, а когато това не е възможно, уеб сървърът да се изключи временно от мрежата.
Защита на vServer: проверка на наличното и на състоянието на пакетите
Първо се уверете кои версии на PHP са инсталирани и от кой източник идват. Много сървъри ползват, освен пакетите на дистрибуцията, и допълнителни източници на пакети. Следващите команди само четат. Имената на пакетите са примери.
# Debian/Ubuntu: инсталирани PHP пакети и откъде идват
apt list --installed 'php*' 2>/dev/null
apt-cache policy php8.3-fpm
# AlmaLinux/Rocky/RHEL
dnf list installed 'php*'
# Какви PHP изпълними файлове изобщо има?
ls /usr/bin/php* /usr/sbin/php-fpm* 2>/dev/null
Само номерът на версията не е достатъчен. Дистрибуциите често доставят корекциите за сигурност като бекпорт и тогава показаният номер остава по-стар. Решаващ е дневникът на промените на пакета.
# Debian/Ubuntu (името на пакета е пример)
apt changelog php8.3-fpm 2>/dev/null | grep -iE 'CVE-2026-1096(18|19)'
# Семейство RHEL (името на пакета е пример)
rpm -q --changelog php-fpm | grep -iE 'CVE-2026-1096(18|19)'
Подробно ръководство има в Проверка на версията на PHP и на състоянието на пача.
Внесете актуализацията и обновете всички процеси
Внесете актуализациите чрез управлението на пакетите и след това рестартирайте всяка услуга, която зарежда PHP. В зависимост от построението това са PHP-FPM, Apache с mod_php, LiteSpeed или сървър за приложения. Новите файлове на диска не са достатъчни, докато стари процеси продължават да работят в паметта.
# Намиране на услугите с PHP
systemctl list-units --type=service | grep -iE 'php|apache2|httpd|lsws'
# Показване на процесите с време на стартиране
ps -eo pid,lstart,cmd | grep -E 'php|apache2|httpd' | grep -v grep
# Debian/Ubuntu: разпознаване на програми със стари библиотеки (ако е инсталирано)
needrestart -r l
Всеки съществен процес трябва да е стартиран след актуализацията. Полезен е инструментът needrestart в системите на Debian, който показва услуги със стари библиотеки. Подробности за рестарта описва Рестартиране на PHP-FPM и на всички работни процеси.
Пачът не премахва зловреден софтуер, внесен преди актуализацията. Запазете логовете на уеб сървъра от 20.10.2026 г. нататък и проверете сървъра за следи, преди да го определите като чист.
За първо търсене на следи са подходящи няколко проверки, които нищо не променят. Потърсете PHP файлове, създадени или променени в уеб директориите от 17.10.2026 г. насам, непознати записи в crontab на всички потребители, нови системни потребители и SSH ключове, както и процеси на потребителя на уеб сървъра, които поддържат изходящи връзки.
# PHP файлове, променени от 17.10.2026 г. насам (пътят е пример)
find /var/www -type f -name '*.php' -newermt '2026-10-17' -ls
# Мрежови връзки със съответния процес
ss -tupn
Никоя от тези проверки сама по себе си не доказва проникване, а празният резултат не доказва обратното. Те показват обаче дали е необходимо по-задълбочено разследване. Работете върху копия на логовете и не променяйте подозрителни файлове, докато състоянието не бъде запазено. При находки сигурният път е подреденото разследване. В този случай не изключвайте просто сървъра и не го инсталирайте веднага наново, защото така се губят следи, важни за оценката на задълженията за уведомяване и за евентуален сигнал до органите.
Трайно укрепване на сървъра
След острия пач следва основната защита. Тя не предотвратява всяка уязвимост, но ограничава щетите и съкращава времето за реакция следващия път. Доказали са се следните точки:
- Достъпи: SSH само с ключ, без директен вход като root, интерфейсите за управление достъпни само от познати мрежи.
- Защитна стена: отваряйте само портовете, които наистина са нужни, ограничете изходящите връзки на уеб сървъра.
- Конфигурация на PHP: изключете опасните функции,
open_basedirза всеки уебсайт, отделни пулове и потребители за всяко приложение. - Права върху файловете: уеб сървърът не бива да може да записва програмен код, директориите за качване не изпълняват PHP.
- Актуализации: внасяйте актуализациите за сигурност автоматично, планирайте твърдо рестарт и проверка.
- Резервни копия: копия по правилото 3-2-1, поне едно копие извън сървъра и защитено от промяна.
- Протоколи: събирайте логовете централно и ги пазете достатъчно дълго.
Как изглежда надеждното резервно копие, описва Резервни копия по правилото 3-2-1. Като рамка за фирми е подходящ IT-Grundschutz на BSI.
Кога управляваният сървър е по-добрият избор
Собственият сървър си струва, когато някой поеме надеждно поддръжката: следене на актуализациите, оценка на ситуации като PHP2Shell, възможност за реакция през нощта. Ако този капацитет липсва, смисъл има или управляван сървър, или постоянен договор за поддръжка. И в двата случая е важно отговорностите да се запишат писмено. Повече по темата има в Управляван сървър: изяснете отговорността.
Как помага PHP SOS конкретно?
- Описваме всички PHP инсталации, източници на пакети и услуги на Вашия сървър и оценяваме действителното състояние на пача.
- Внасяме актуализациите, рестартираме всички процеси и документираме резултата.
- Проверяваме сървъра за следи от компрометиране и запазваме логовете за по-късен анализ.
- В рамките на нашето укрепване на сървъри настройваме правилно достъпите, защитната стена, PHP пуловете и правата.
- При желание поемаме текущата поддръжка чрез договор за поддръжка на сигурността.
Често задавани въпроси
Пачва ли центърът за данни моя vServer автоматично?
При неуправляваните root сървъри и vServer по правило не. Доставчикът осигурява хардуера или виртуализацията и мрежата, а операционната система и всички услуги върху нея управлявате сами. При съмнение проверете договора си.
Достатъчни ли са автоматичните актуализации за сигурност?
Те помагат, но не заместват проверката. Автоматичните актуализации не винаги рестартират работещите PHP процеси и често не обхващат пакети от външни източници. След всяка актуализация за сигурност проверявайте състоянието на пакетите и времето на стартиране на процесите.
Как да разбера дали моят пакет съдържа бекпорт?
В дневника на промените на пакета и в съобщенията за сигурност на Вашата дистрибуция. Ако там е записан номерът на CVE, корекцията е включена, дори версията да изглежда по-стара. Ако записът липсва, изяснете състоянието, преди да определите сървъра като пачнат.
Какво да направя, ако за моята версия на PHP не излезе пач?
PHP 8.1 и по-стари вече не получават официални актуализации. Приложете временните мерки по php.net, планирайте бързо преминаване към поддържана версия и при нужда изключете сървъра временно от мрежата според препоръката на BSI.