Проверка PHP2Shell

Как закрыть уязвимость и ничего не сломать

Уязвим сам интерпретатор PHP, поэтому обновление CMS, плагинов или кода сайта не помогает. Порядок действий:

1. Сделайте резервную копию и оцените обновление

   Обновление внутри своей ветки (например, 8.3.30 → 8.3.36) — исправительный релиз без изменений в языке: его ставят сразу, сохранив копию файлов сайта и базы. Переход на другую ветку (с 8.1 на 8.3 и выше) может сломать старый код — сначала проверьте сайт на тестовой копии.

2. Обновите PHP

   Выберите способ по тому, как у вас установлен PHP, и подставьте свою ветку вместо 8.3. Ключ --only-upgrade обновляет только уже установленные пакеты и ничего не добавляет. Если в репозитории дистрибутива исправленной версии еще нет, проверьте changelog пакета (исправление могли перенести без смены номера) или возьмите PHP из репозитория ondrej/sury.

   # Debian / Ubuntu: какие пакеты PHP ждут обновления
   sudo apt update
   apt list --upgradable 2>/dev/null | grep php
   # добавьте свои: libapache2-mod-php8.3, php8.3-mysql и другие модули
   sudo apt install --only-upgrade php8.3-common php8.3-cli php8.3-fpm
   
   # RHEL / AlmaLinux / Rocky Linux: какие пакеты PHP ждут обновления
   dnf check-update 'php*'
   sudo dnf upgrade php-common php-cli php-fpm
   
   # Docker: pull — для готовых образов (image:), build --pull — для своих Dockerfile; закрепленный тег вроде php:8.3.30-fpm замените на исправленный
   docker compose pull
   docker compose build --pull
   docker compose up -d

   Виртуальный хостинг или панель (ISPmanager, cPanel, Plesk): выберите в настройках сайта исправленную версию PHP. Если ее нет в списке — напишите в поддержку: на таком тарифе PHP обновляет хостер.

3. Перезапустите PHP

   Пока работают старые процессы, в памяти остается уязвимый код. Перед перезапуском проверьте конфигурацию — команды ниже не перезапустят службу, если в ней ошибка. Перезапуск занимает секунды, но запросы в этот момент могут получить ошибку — делайте его в часы низкой нагрузки. Перезапустите и другие долгоживущие процессы на PHP: воркеры очередей, демоны под supervisor, RoadRunner или Swoole. В Docker после up -d контейнеры уже новые.

   # nginx или Apache + PHP-FPM: достаточно перезапустить PHP-FPM (на RHEL служба называется php-fpm)
   sudo php-fpm8.3 -t && sudo systemctl restart php8.3-fpm
   # Apache с mod_php: перезапустить Apache (на RHEL — httpd)
   sudo apachectl configtest && sudo systemctl restart apache2

4. Проверьте результат

   На сервере — версию того бинарника, который обслуживает сайт (php-fpm8.3 -v, а не только php -v), или changelog пакета (команды выше). Снаружи — повторите проверку на этой странице.

5. Если сайт был уязвим — поищите следы взлома

   По данным Help Net Security, ловушки Amazon MadPot фиксировали попытки эксплуатации с 17 октября 2026 года. Посмотрите, не появились ли в каталоге сайта новые или измененные PHP-файлы, которых вы не выкладывали. Команда только читает список файлов и ничего не меняет. Пустой результат не доказывает, что взлома не было: дату изменения файла можно подделать.

   # подставьте каталог своего сайта
   find /var/www \( -name '*.php' -o -name '*.phtml' -o -name '*.phar' \) -newermt '2026-10-17' -ls

   Нашли незнакомые файлы — не удаляйте их сразу: сохраните копии и журналы веб-сервера, смените пароли и ключи доступа к серверу и обратитесь к специалисту по разбору инцидентов.

Если обновиться сегодня нельзя

Включите правила WAF против PHP2Shell, если они есть у вашего провайдера, и назначьте обновление на ближайшие дни. WAF снижает риск известных вариантов атаки, но уязвимость не закрывает. Скрыть версию из заголовков (expose_php = Off) полезно, но это тоже не защита.