Как устранить PHP2Shell

php.net высказывается однозначно: «Полноценных мер защиты нет, обновление — единственный безопасный вариант». Это руководство описывает обновление, часто забываемый перезапуск, проверку и то, на что обратить внимание, если сервер был доступен атакующим.

1 Найдите каждый PHP на сервере

На многих серверах работает больше одного PHP: системный пакет, версии, установленные панелью управления (cPanel EA-PHP, Plesk, CWP/CloudLinux alt-php, DirectAdmin), контейнеры и сборки командной строки, используемые cron. Каждую версию, обслуживающую веб-запросы, нужно обновить.

Выполните php -v, выведите процессы php-fpm командой ps aux | grep php-fpm и проверьте селектор PHP в Вашей панели.

2 Обновите до исправленной версии

Исправленные версии upstream: 8.5.12, 8.4.27, 8.3.36 и 8.2.35. Пакеты дистрибутивов могут содержать исправление под более старым номером версии — проверьте журнал изменений на CVE-2026-109618 и CVE-2026-109619.

Для PHP 8.1 и старше проект PHP выпусков не делает. Для тех, кто собирает из исходников, опубликованы минимальные бэкпорты для 7.4, 8.0 и 8.1, но надёжное решение — переход на поддерживаемую ветку.

Debian / Ubuntu (пакеты дистрибутива)

Установите обновление безопасности из Вашего дистрибутива и перезапустите PHP. Номер версии может не измениться; CVE указан в журнале изменений пакета.

sudo apt update && sudo apt install --only-upgrade 'php*'
sudo systemctl restart 'php*-fpm' apache2 2>/dev/null
apt changelog php8.3-fpm | grep -i -m3 CVE-2026-1096

RHEL / AlmaLinux / Rocky (dnf)

Установите исправления (errata) поставщика для Вашего потока модуля PHP, затем выполните перезапуск.

sudo dnf upgrade --refresh 'php*'
sudo systemctl restart php-fpm httpd
rpm -q --changelog php-common | grep -i -m3 CVE-2026-1096

Docker / официальные образы php

Загрузите или пересоберите образ с исправленным тегом и пересоздайте контейнеры.

docker pull php:8.3-fpm   # must report 8.3.36 or later
docker compose up -d --build --force-recreate
docker compose exec app php -v

cPanel, Plesk, CWP, DirectAdmin

Используйте средство обновления панели для каждой установленной версии PHP (EA-PHP, обработчики PHP в Plesk, alt-php, CustomBuild), затем перезапустите PHP-FPM. Панели часто оставляют старые версии для отдельных сайтов — обновите или удалите и их.

Виртуальный или управляемый хостинг

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

Windows / IIS

Скачайте исправленную сборку с windows.php.net, замените каталог PHP и перезапустите (recycle) пулы приложений IIS.

3 Перезапустите все процессы PHP

Установка пакета не меняет уже работающий код. Перезапустите PHP-FPM, Apache (для mod_php), LiteSpeed, FrankenPHP, обработчики очередей и супервизоры. Для контейнеров пересоберите или загрузите новый образ — перезапуск того же образа исправление не устанавливает.

4 Проверьте

Выполните php -v для каждого бинарного файла и убедитесь, что работающие процессы используют новую сборку (например, ls -l /proc/$(pgrep -o php-fpm)/exe не должен показывать «deleted»). Затем запустите эту проверку ещё раз.

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

Примените частичные меры защиты, перечисленные ниже, и ограничьте доступ к сайту, пока не сможете обновиться. Они снижают риск, но не устраняют его.

6 Поищите признаки компрометации — и смените секреты

Если уязвимый сайт был доступен из интернета, проверьте активность начиная с 20 октября 2026 года: падения рабочих процессов PHP (SIGSEGV) в журнале ошибок PHP-FPM или Apache, новые или изменённые PHP-файлы в корне сайта, новые задания cron, новые учётные записи администраторов и неожиданные исходящие соединения.

Поскольку CVE-2026-109619 может раскрыть память процесса PHP без выполнения какого-либо кода, чистая файловая система не доказывает, что утечки не было. Для сайтов, которые были доступны, смените пароли баз данных, ключи API, учётные данные платёжных систем и почты и аннулируйте пользовательские сессии.

7 После обновления

Исправление вводит новый жёсткий лимит памяти: процесс, достигший его, немедленно завершается, а функции завершения (shutdown handlers) не выполняются. Проверьте, как Ваше приложение ведёт себя при нехватке памяти, пересмотрите memory_limit вместе с post_max_size и max_input_nesting_level и отмените временную настройку memory_limit = -1, если Вы задали её до установки исправления. Скрытие версии с помощью expose_php = Off — необязательная мера усиления защиты, а не исправление.

Частичные меры защиты (по данным php.net и бюллетеней)

Они лишь сужают известные пути атаки. php.net указывает, что обновление — единственный безопасный вариант.

; php.ini / FPM pool (php_admin_value) — после этого перезапустите все рабочие процессы
session.upload_progress.enabled = 0
fatal_error_backtraces = 0        ; PHP 8.5
post_max_size = 8M                ; 32M если загрузка файлов необходима
max_input_nesting_level = 16      ; default 64
display_errors = 0

; FPM pool
pm.max_requests = 200

Задавайте эти параметры в php.ini, в пуле PHP-FPM (php_admin_value) или в конфигурации сервера — не через ini_set() или .user.ini — и перезапустите рабочие процессы. Дополнительные меры из бюллетеней и от исследовательской группы:

memory_limit = -1 блокирует некоторые пути, основанные на собственном лимите памяти PHP, но передаёт исчерпание памяти операционной системе — используйте его только вместе с лимитом memory.max в cgroup v2. Не используйте RLIMIT_AS или RLIMIT_DATA: они могут задействовать те же уязвимые пути.
Снизьте max_input_nesting_level настолько, насколько позволяют Ваши формы.
Уменьшите pm.max_requests в PHP-FPM, чтобы рабочие процессы перезапускались чаще (ценой производительности).
Ограничьте размер запроса, число полей и глубину вложенности на уровне веб-сервера или прокси; удалите некорректные или устаревшие настройки INI, задаваемые для отдельных запросов.
Политики SELinux или AppArmor могут ограничить, что способен запустить скомпрометированный рабочий процесс, — они снижают ущерб, но не предотвращают раскрытие памяти.

Источники

Источник: бюллетень безопасности php.net от 21 октября 2026 года. Последняя проверка: 2026-10-23.