PHP2Shell (CVE-2026-109618, CVE-2026-109619) — RCE в PHP: кто уязвим и как проверить

Что произошло

21 октября 2026 года проект PHP опубликовал advisory GHSA-w8hw-w9fx-j79w о двух уязвимостях, которые получили общее имя PHP2Shell:

• CVE-2026-109618 — удаленное выполнение кода (RCE) через повреждение данных запроса при нехватке памяти (out-of-memory);
• CVE-2026-109619 — RCE через состояние запроса, которое продолжает использоваться после освобождения памяти.

Обе оценены в 9.2 по CVSS 4.0. Детали утекли до окончания эмбарго, и выпуск исправлений сдвинули примерно на день. По данным Help Net Security, ловушки Amazon MadPot фиксировали попытки эксплуатации уже 17.10.2026 — до публичного раскрытия. Публичные эксплойты тоже появились, так что откладывать обновление не стоит.

Почему это критично

• Без авторизации. Атакующему достаточно одного специально сформированного HTTP-запроса.
• До кода приложения. Ошибка срабатывает при разборе multipart-запроса — раньше, чем выполнится код вашего сайта. Поэтому обновление CMS, фреймворка или плагинов уязвимость не закрывает: уязвим сам интерпретатор.
• Почти любой способ запуска PHP. RCE подтверждено для Apache mod_php. PHP-FPM, php-cgi, FrankenPHP и LiteSpeed, по анализу кода, тоже уязвимы.

Какие версии исправлены

Важная деталь про дистрибутивы: Debian, Ubuntu, RHEL и LTS-вендоры часто переносят исправление в свою сборку без смены номера версии. Тогда php -v покажет версию ниже исправленной, хотя пакет уже закрыт. Поэтому для сборок дистрибутивов смотрите changelog пакета — команды ниже.

Как проверить у себя на сервере

Самый надежный способ — проверить на самом сервере. Начните с версии и SAPI:

# Версия интерпретатора
php -v

# Версия и SAPI одной строкой
php -r 'echo PHP_VERSION, " ", PHP_SAPI;'
# → 8.3.36 cli

php в консоли — это CLI. Сайт обслуживает PHP-FPM или mod_php, а это может быть другой пакет и даже другая версия. Проверьте и тот бинарник, через который работает сайт, например php-fpm8.3 -v.

# Debian / Ubuntu: есть ли исправление в пакете
# (подставьте свою ветку: php8.2-common, php8.3-common, php8.4-common)
apt changelog php8.3-common | grep CVE-2026-10961

# RHEL / AlmaLinux / Rocky Linux
rpm -q --changelog php | grep CVE-2026-10961
# если пакета php нет — проверьте php-common или php-fpm

Шаблон CVE-2026-10961 находит обе записи — CVE-2026-109618 и CVE-2026-109619. Если вывод пустой, исправление в установленном пакете не упомянуто: обновите пакет и проверьте снова.

# Docker: обновить базовый образ и пересобрать
docker compose build --pull
docker compose up -d
docker compose exec app php -v   # app — имя вашего сервиса

Если в Dockerfile закреплен точный тег (например, FROM php:8.3.30-fpm), замените его на исправленную версию. Тег вида php:8.3-fpm подтянет исправление только после пересборки с --pull — сам по себе работающий контейнер не обновится.

Что делать

1. Обновить PHP до 8.2.35, 8.3.36, 8.4.27 или 8.5.12. Для 7.4, 8.0 и 8.1 — поставить пакет дистрибутива или LTS-вендора с бэкпортом и запланировать переход на поддерживаемую ветку.
2. Перезапустить PHP-FPM и веб-сервер. Пока работают старые процессы, в памяти остается старый код: systemctl restart php8.3-fpm, затем systemctl restart apache2 (или httpd, nginx — по вашей схеме).
3. Проверить результат: версия или changelog на сервере, затем внешняя проверка на /php2shell.
4. WAF — только как временная мера. Он снижает риск известных шаблонов атаки, но не заменяет обновление.
5. expose_php = Off в php.ini убирает версию PHP из заголовка X-Powered-By. Это гигиена — меньше подсказок автоматическим сканерам, — а не защита: уязвимый PHP со скрытой версией остается уязвимым.

Что можно проверить на enterno.io

Проверка PHP2Shell — /php2shell

Инструмент делает один обычный GET-запрос к главной странице сайта (с переходом максимум по трем редиректам) и читает только те заголовки ответа, которые сайт отдает любому посетителю: X-Powered-By, Server и cookie PHPSESSID. Найденная версия PHP сравнивается с исправленными релизами. Больше ничего: ни атак, ни проверочных эксплойтов, ни подбора, ни нагрузки — по сути, то же самое, что открыть сайт в браузере.

Возможные ответы:

• Уязвима — версия ниже исправления своей ветки. Если по заголовкам видна сборка дистрибутива, будет пометка «возможен бэкпорт»: проверьте changelog пакета на сервере.
• Исправлена — версия не ниже исправленного релиза своей ветки.
• Версия скрыта — PHP виден (например, по cookie PHPSESSID), но номер версии сайт не сообщает. Это не значит «защищено»: проверьте версию на сервере.
• PHP не обнаружен — в заголовках нет признаков PHP. Это тоже не гарантия: PHP может стоять за прокси, который убирает такие заголовки.

Технологии и известные CVE — /tech-detect

Определение технологий находит CMS, фреймворки, серверы и их версии и показывает известные CVE для найденной версии. Каталог учитывает исправления по веткам, PHP2Shell в нем уже есть. Общая проверка заголовков безопасности и настроек сайта — в сканере безопасности.

Мониторинг — /monitors

Мониторинг следит за доступностью сайта и сообщает, если он перестал отвечать — полезно в дни, когда по уязвимости идет массовое сканирование. Версию PHP мониторинг не проверяет: после обновления повторите проверку на /php2shell.

Проверяйте только свои сайты

Проверяйте свои сайты или сайты, владелец которых разрешил проверку. enterno.io не выполняет никаких атакующих действий — только читает заголовки, которые сайт сам отдает каждому посетителю. Попытка же эксплуатировать уязвимость на чужой системе без разрешения — уже не проверка: в России это подпадает под ст. 272 УК РФ (неправомерный доступ к компьютерной информации), и похожие нормы есть в других странах.

Частые вопросы

Мы обновили CMS и плагины — этого достаточно?

Нет. PHP2Shell — уязвимость самого интерпретатора PHP: она срабатывает при разборе запроса, до запуска кода приложения. Нужно обновить PHP и перезапустить PHP-FPM или веб-сервер, затем сверить версию на /php2shell.

Сайт работает через PHP-FPM, а не mod_php. Он уязвим?

Да, исходите из этого. RCE подтверждено для Apache mod_php, но по анализу кода уязвимы и PHP-FPM, php-cgi, FrankenPHP и LiteSpeed. Обновляйте PHP независимо от SAPI.

У нас PHP 7.4, 8.0 или 8.1. Что делать?

Официального релиза для этих веток нет. PHP опубликовал минимальные исходные бэкпорты, а дистрибутивы и LTS-вендоры выпускают свои пакеты — номер версии при этом может остаться прежним. Проверьте changelog пакета на CVE-2026-109618 и CVE-2026-109619 и запланируйте переход на поддерживаемую ветку.

Проверка показала «версия скрыта». Значит, сайт защищен?

Нет. Скрытая версия (например, после expose_php = Off) мешает определить ее снаружи, но уязвимость не закрывает. Проверьте php -v и changelog пакета на сервере.

Можно ли обойтись WAF вместо обновления?

Нет. WAF снижает риск известных шаблонов атаки и полезен как временная мера, пока готовится обновление, но обновление PHP он не заменяет.

Источники

• PHP: advisory GHSA-w8hw-w9fx-j79w
• NVD: CVE-2026-109618
• NVD: CVE-2026-109619
• Help Net Security: PHP2Shell, 21.10.2026