Практически инструкции: Как да проверите дали вашият PHP сървър е защитен от PHP2Shell?

Следващите инструкции са предназначени основно за Linux сървъри с Ubuntu или Debian, използващи Apache, PHP-FPM и APT.

1. Проверете инсталираната PHP версия

Свържете се със сървъра чрез SSH и изпълнете:

php -v

Командата показва версията на PHP, използвана от командния ред (CLI).

Важно е да знаете, че един сървър може да използва едновременно няколко различни PHP версии. Например един онлайн магазин може да работи с PHP 8.3, а по-стара ERP система — с PHP 7.2.

За да видите всички инсталирани PHP пакети:

dpkg -l | grep -E '^ii  php[0-9]|^ii  libapache2-mod-php'

За проверка на наличните PHP-FPM услуги:

systemctl list-units --all 'php*-fpm.service'

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

2. Проверете за налични актуализации

Обновете информацията за пакетите:

sudo apt update

След това проверете за налични PHP актуализации:

apt list --upgradable 2>/dev/null | grep -E '^(php|libapache2-mod-php)'

Ако са налични нови версии, проверете дали съдържат необходимите поправки.

За да видите инсталираната и предложената версия на конкретен пакет:

apt policy php8.3-fpm

Тази команда показва текущо инсталирания пакет, кандидата за обновяване и наличните източници.

3. Проверете дали поправките за PHP2Shell са включени

Това е една от най-важните проверки, особено когато се използват по-стари версии на PHP.

При някои доставчици информацията за промените се съхранява в Debian changelog файловете.

Например за PHP 7.2:

zcat /usr/share/doc/php7.2-common/changelog.Debian.gz | head -50

За PHP 7.4:

zcat /usr/share/doc/php7.4-common/changelog.Debian.gz | head -50

Можете да потърсите конкретните идентификатори на уязвимостите:

zgrep -E 'CVE-2026-109618|CVE-2026-109619' 
/usr/share/doc/php*/changelog.Debian.gz

При липсващи changelog файлове трябва да проверите документацията и съобщенията за сигурност на доставчика на пакетите.

Практически пример от WebBuild

При актуализиране на сървър с Ubuntu 24.04 и PHP пакети от deb.sury.org установихме, че пакетът PHP 7.2.34-66 съдържа следната информация:

php7.2 (7.2.34-66)

* Backported from 8.2.35
  + [CVE-2026-109618, CVE-2026-109619]:
    Avoid state corruption via bailout.

Това потвърждава, че доставчикът е включил поправки за двете уязвимости и в PHP 7.2, въпреки че тази версия отдавна е извън официалната поддръжка.

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

Трябва обаче да се подчертае, че наличието на backport не прави автоматично остарялата версия напълно защитена срещу всички известни уязвимости.

4. Проверете коя PHP версия използва Apache

Ако сървърът използва Apache, проверете активните модули:

apache2ctl -M | grep -E 'php|proxy_fcgi|mpm_'

Проверете и конфигурацията на виртуалните хостове:

apache2ctl -S

При използване на PHP-FPM потърсете конфигурационните директиви, които свързват конкретните сайтове с PHP процесите:

grep -RniE 'SetHandler|ProxyPassMatch|php[0-9].[0-9]-fpm' 
/etc/apache2/sites-enabled/ /etc/apache2/conf-enabled/

Например конфигурация, насочваща заявките към:

/run/php/php8.3-fpm.sock

показва, че съответният обработчик използва PHP 8.3.

Не променяйте автоматично конфигурациите на Apache или PHP-FPM, преди да установите зависимостите на отделните приложения.

5. Инсталирайте необходимите актуализации

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

Първо симулирайте актуализацията:

sudo apt-get -s upgrade

Прегледайте дали ще бъдат премахнати или задържани важни пакети.

След това можете да изпълните:

sudo apt update
sudo apt upgrade

При критична продукционна инфраструктура обновяването трябва да се извършва контролирано, тъй като инсталирането на PHP пакети може да рестартира Apache и PHP-FPM услугите.

6. Проверете състоянието на услугите след обновяването

След актуализацията проверете конфигурацията на Apache:

sudo apache2ctl configtest

При коректна конфигурация обикновено ще получите:

Syntax OK

След това проверете услугата:

systemctl status apache2 --no-pager

Проверете и PHP-FPM:

systemctl status php8.3-fpm --no-pager

Ако Apache не успее да стартира след множество автоматични рестартирания и показва start-limit-hit, проверете системния журнал:

sudo journalctl -u apache2 -n 100 --no-pager

Когато причината е само достигнат лимит на systemd и конфигурацията е валидна, може да се приложи:

sudo systemctl reset-failed apache2
sudo systemctl start apache2

Това не отстранява реални конфигурационни грешки или проблеми със зареждането на модули.

7. Проверете за признаци на компрометиране

Инсталирането на поправките предотвратява експлоатацията на конкретните отстранени уязвимости, но не премахва автоматично евентуално вече инсталиран зловреден код.

Проверете журналите на Apache:

sudo journalctl -u apache2 --since "2026-10-17"

Прегледайте и файловете в:

/var/log/apache2/

Особено внимание заслужават необичайни заявки, непознати изпълними файлове, неочаквани промени в приложенията, новосъздадени потребители, подозрителни процеси и нетипични изходящи мрежови връзки.

За преглед на наскоро променени PHP файлове в конкретен проект може да използвате:

find /var/www/example.com -type f -name '*.php' 
-mtime -7 -print

Заменете примерния път с реалната директория на проекта.

Тази проверка не доказва наличие на атака — легитимните актуализации също променят файлове. Резултатите трябва да бъдат сравнени с очакваните промени и историята на внедряванията.

При сериозни съмнения за компрометиране е необходим специализиран анализ на инцидента, включително съхраняване на доказателства, проверка на механизмите за постоянен достъп и смяна на потенциално компрометирани идентификационни данни.

8. Не разчитайте единствено на версията на PHP

Най-сигурният подход включва няколко независими проверки:

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

Заключение: Актуализацията е само първата стъпка

PHP2Shell показва колко сериозни могат да бъдат последствията от уязвимост в широко използвана сървърна технология.

Защитата не се изчерпва с изпълнението на една команда за обновяване. Необходими са правилна оценка на риска, проверка на конфигурацията, контролирано прилагане на поправките и постоянно наблюдение на инфраструктурата.

За онлайн магазините, CRM и ERP системите това е особено важно, защото сигурността на сървърната среда е пряко свързана със защитата на бизнес данните и непрекъсваемостта на ежедневните операции.

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

Създайте своя дигитален проект с WebBuild