Как проверить, закрыта ли уязвимость PHP2Shell на сервере: пошаговая инструкция
После выхода исправлений для PHP2Shell многие администраторы обновили пакеты, увидели в php -v прежнюю цифру и решили, что обновление не встало. Другие, наоборот, обновили консольный PHP и не заметили, что сайт обслуживает совсем другая сборка. Ниже — порядок проверки, после которого можно честно сказать «закрыто».
Шаг 1. Найдите, какой PHP на самом деле обслуживает сайт
Консольный php и PHP, который отвечает на запросы посетителей, — часто разные программы с разными настройками. Начните с веб-сервера:
| Что проверяем | Команда | Что увидим |
|---|---|---|
| Есть ли mod_php в Apache | apachectl -M | grep -i php | Строка php_module или php7_module — PHP работает как модуль, это самый опасный вариант |
| Запущенные PHP-FPM | systemctl list-units | grep -i fpm | Службы вида php8.1-fpm, php8.3-fpm — по одной на версию |
| Куда nginx отдаёт запросы | grep -R fastcgi_pass /etc/nginx/ | Путь к сокету подскажет, какая версия FPM обслуживает какой сайт |
| Версия FPM | php-fpm8.3 -v (Debian, Ubuntu) или php-fpm -v (RHEL) | Версия именно той сборки, что отвечает посетителям |
| Другие сборки | ls /opt/remi /opt/cpanel /opt/alt /opt/plesk/php 2>/dev/null | Дополнительные версии из панелей и сторонних репозиториев |
На серверах с панелями (cPanel, Plesk, ISPmanager, FastPanel) нередко стоят пять-семь версий PHP одновременно, и разные сайты используют разные. Проверять нужно все, которые реально запущены.
Шаг 2. Сравните версию с исправленной
Если сборка совпадает с официальной нумерацией (Debian 12 и 13, репозиторий Remi, официальные Docker-образы), достаточно версии: исправлены 8.5.12, 8.4.27, 8.3.36 и 8.2.35 и всё, что новее. Всё, что ниже на тех же ветках, уязвимо.
Ubuntu, AlmaLinux, CloudLinux и пакеты для старых веток устроены иначе: исправление переносится в старую версию, и номер не меняется. Тогда смотрите журнал изменений.
Шаг 3. Проверьте журнал изменений пакета
| Система | Команда |
|---|---|
| Ubuntu, Debian | zgrep -E 'CVE-2026-10961[89]' /usr/share/doc/php8.3-fpm/changelog.Debian.gz (подставьте свою версию) |
| RHEL, Rocky, AlmaLinux | rpm -q --changelog php-fpm | grep -E 'CVE-2026-10961[89]' |
| Ubuntu — версия пакета | dpkg -l | grep php8. и сравнение с USN-8948-1: 22.04 — 8.1.2-1ubuntu2.28, 24.04 — 8.3.6-0ubuntu0.24.04.13, 26.04 — 8.5.4-0ubuntu1.5 |
Если команда нашла оба номера CVE, пакет исправлен. Если пусто — либо обновление не установлено, либо вы смотрите не на тот пакет. На наших серверах проверка выглядела именно так: в журнале php8.1 на Ubuntu 22.04 появилась строка о патче для CVE-2026-109618 и CVE-2026-109619, хотя php -v по-прежнему показывал 8.1.2.
Шаг 4. Перезапустите службы и проверьте, что старый код выгружен
Пакетный менеджер заменяет файлы на диске, но работающие процессы продолжают выполнять старую версию из памяти. Пока службу не перезапустили, сервер остаётся уязвимым.
- Перезапустите каждую службу FPM:
systemctl restart php8.3-fpmдля каждой установленной версии. - Для Apache с mod_php нужен полный перезапуск:
systemctl restart apache2илиhttpd. Команда reload здесь не подходит. - Проверьте, не осталось ли процессов со старыми библиотеками: утилита
needrestartна Debian и Ubuntu илиlsof | grep -E 'php.*(deleted)'. - Откройте сайт, админку, отправьте тестовую заявку и проверьте оплату — после перезапуска иногда всплывают старые проблемы конфигурации.
Шаг 5. Контейнеры, панели и виртуальный хостинг
- Docker. Запущенный контейнер не обновляется сам. Пересоберите образ с флагом
--pull, чтобы подтянуть исправленный базовый образ, и пересоздайте контейнеры. Простого перезапуска недостаточно. - cPanel и EasyApache 4. Пакеты ea-php82–ea-php85 получили новые версии, для ea-php74, 80 и 81 сделаны бэкпорты — сверяйтесь с журналом изменений EA4.
- DirectAdmin и CloudLinux. Сборки alt-php и ea-php сохраняют старый номер версии, проверять нужно журнал сборки.
- Виртуальный хостинг. Самостоятельно проверить сервер не получится. Выберите в панели свежую сборку своей ветки и попросите поддержку письменно подтвердить установку исправлений для CVE-2026-109618 и CVE-2026-109619.
Шаг 6. Проверьте настройки, которые снижают риск
Даже на исправленной версии полезно убедиться, что на сервере не осталось лишнего. Смотрите вывод именно FPM, а не консольного PHP: php-fpm8.3 -i | grep upload_progress. Если загрузки файлов с индикатором прогресса на сайте не используются, параметр session.upload_progress.enabled можно выключить. Заодно проверьте, что в пулах FPM нет php_admin_value, которые включают его обратно.
Что делать, если проверка показала проблему
Если исправленной версии для вашей системы нет — например, сервер на неподдерживаемой версии Ubuntu или CentOS 7, — обновить PHP «одной командой» не получится. Это повод для переезда на поддерживаемую систему, о котором мы писали в статье про сайты на старом PHP.
Если проверять некому или не хочется разбираться в командах ночью, мы сделаем это за вас: в рамках скорой помощи — от 4 900 ₽, старт в течение часа — проверим все установки PHP, обновим, перезапустим и пришлём отчёт с результатами каждой проверки. Для проектов, где новая версия PHP требует доработки кода, есть отдельная услуга обновления PHP с проверкой совместимости.
Источники
Вопросы и ответы
Почему php -v показывает старую версию после обновления?
Ubuntu, AlmaLinux и CloudLinux переносят исправление в старую версию без смены номера. Проверяйте журнал изменений пакета на упоминание CVE-2026-109618 и CVE-2026-109619.
Я обновил пакеты. Этого достаточно?
Нет, нужен ещё перезапуск php-fpm или полный перезапуск Apache с mod_php. Без него работающие процессы продолжают выполнять старый код.
Как понять, какой PHP обслуживает конкретный сайт?
Посмотрите, куда nginx передаёт запросы (fastcgi_pass), или есть ли модуль PHP в Apache (apachectl -M). Консольный php может быть другой версии.
Можно ли проверить сайт на виртуальном хостинге?
Сервер — только через хостера: попросите письменно подтвердить установку исправлений. Сам сайт снаружи можно проверить нашим бесплатным сканером взлома.