Две уязвимости PHP2Shell с критической оценкой 9,2 затронули большинство сборок PHP, а попытки эксплуатации уже фиксируются в сети. Для русскоязычных команд это не история «про чужие WordPress»: если PHP-сервис нельзя обновить немедленно, PHP Project рекомендует отключить один параметр сессий, чтобы закрыть дополнительный сценарий удалённого выполнения кода.
Патчи для основной пары проблем вышли 21 октября, а 23 октября проект PHP опубликовал отдельное разъяснение по ещё одному, менее вероятному вектору атаки. Как сообщает ZDNet, обновиться следует до PHP 8.5.12, 8.4.27, 8.3.36 или 8.2.35. Если обновление упирается в регламент, несовместимый модуль или долгий цикл тестирования, временная мера проста: установить session.upload_progress.enabled=0.
Название PHP2Shell объединяет CVE-2026-109618 и CVE-2026-109619. Первая проблема позволяет раскрывать данные из памяти процесса, вторая создаёт путь к неаутентифицированному RCE. Важная деталь для владельцев сайтов и платформ: уязвимость находится в самом PHP, а не в конкретном CMS, фреймворке или неудачном плагине. Поэтому привычная проверка «у нас только свой код и свежий Laravel» здесь не даёт индульгенции.
Риск масштабируется из-за распространённости языка. По оценке исследователей Wiz, PHP присутствует примерно на 70% сайтов в мире. Это не означает, что 70% сайтов одинаково доступны для захвата, но хорошо объясняет срочность реакции: PHP обслуживает и небольшие лендинги, и интернет-магазины, и внутренние кабинеты, где за веб-интерфейсом нередко живут платёжные данные, CRM и административные функции.
По данным Amazon Threat Intelligence, активность, связанная с эксплуатацией, наблюдалась ещё за четыре дня до публичного раскрытия. После публикации быстро появились proof-of-concept-наработки, а Cloudflare сообщил о миллионах попыток атак в своей сети. Отдельные цепочки атак, по информации ZDNet, пытаются развернуть ботнет в стиле Mirai. Для защитников это означает неприятную, но знакомую картину: окно между публикацией CVE и массовым сканированием измеряется не неделями, а часами.
Новая рекомендация PHP Project относится к CVE-2026-115560 и не отменяет основное обновление. Этот путь к RCE требует довольно специфичной комбинации настроек: приложение должно использовать php_binary или php_serialize в параметре session.serialize_handler, затем во время работы переключить обработчик на php через ini_set() до вызова session_start(). Кроме того, должен оставаться включён механизм отслеживания прогресса загрузки файлов. Проект PHP считает такой сценарий маловероятным, поэтому временного отключения upload progress достаточно до планового исправления.
Командам не стоит трактовать слово «маловероятный» как разрешение отложить работу. Конфигурационные исключения часто живут дольше документации: их добавляют для старого интеграционного сценария, копируют между окружениями и забывают после миграции. Если приложение не меняет обработчик сериализации сессий в рантайме, PHP Project допускает оставить upload progress включённым. Но это вывод надо подтверждать поиском по коду и фактической конфигурацией каждого окружения, а не надеждой на единый шаблон Helm или Ansible.
Практический порядок действий выглядит без романтики. Сначала нужно составить инвентаризацию сервисов, контейнеров и образов, где есть PHP, включая забытые админки и CI-утилиты. Затем — обновить пакеты через штатный менеджер дистрибутива либо поддерживаемый коммерческий LTS-канал, прогнать минимальный регресс по авторизации, сессиям и загрузке файлов. На системах, которые пока не обновляются, стоит применить параметр session.upload_progress.enabled=0, проверить, что он действительно дошёл до FPM и веб-процессов, и усилить логирование подозрительных запросов.
NSA советует в ближайшие недели относиться к PHP2Shell как к приоритету: проверять зависимые сервисы, ставить все выпущенные поставщиками патчи и по возможности выводить из эксплуатации версии PHP без поддержки. Это полезный ориентир и для бизнеса. Инцидент с RCE в публичном приложении редко остаётся задачей одного разработчика: следом приходят простои, расследование, ротация секретов и вопросы к тому, почему критический компонент не был учтён в управлении активами.
Уязвимости PHP2Shell показывают, что скорость появления эксплойтов растёт вместе с доступностью инструментов для анализа кода и генерации атакующих цепочек. В такой среде «поставим патч в следующий спринт» перестаёт быть нейтральным решением: для интернет-доступных PHP-систем оно уже становится осознанным принятием риска.
