Информация проверена 22 октября 2026 года. PHP2Shell — название двух критических уязвимостей в движке PHP. Обновления безопасности вышли 21 октября. При определённых условиях злоумышленник без учётной записи в приложении может выполнить код с правами процесса PHP. Проблема касается инфраструктуры, на которой работают сайты WordPress и другие приложения, включая заказную разработку.
Основное исправление — установить пакет PHP с патчами и перезапустить затронутые процессы. Обновление WordPress, плагинов или зависимостей Composer не заменяет обновление самого движка. Подробности — в официальном сообщении PHP.
Что такое PHP2Shell
CVE-2026-109618: обработка нехватки памяти может оставить внутренние данные в частично инициализированном состоянии. Их последующая обработка способна привести к выполнению кода. См. уведомление PHP о повреждении памяти при OOM.
CVE-2026-109619: повторно используемый рабочий процесс может сохранить ссылки на память, освобождённую после запроса. Следующий запрос способен обратиться к этому устаревшему состоянию. См. уведомление об устаревшем глобальном состоянии.
Для Apache с mod_php продемонстрирована атака до выполнения кода приложения. PHP-FPM и другие режимы работы также требуют оценки: форма входа или использование фреймворка не подтверждают защищённость. У разных вариантов атаки разные условия.
Какие версии PHP содержат исправления
Первые исправленные релизы, опубликованные проектом PHP для поддерживаемых веток:
PHP 8.2: 8.2.35
PHP 8.3: 8.3.36
PHP 8.4: 8.4.27
PHP 8.5: 8.5.12
Установите указанный или более поздний исправленный релиз выбранной ветки. Для PHP 8.1 и старше уточните наличие backport-патча у поставщика и запланируйте переход на поддерживаемую ветку. Отдельный патч не восстанавливает официальную поддержку устаревшей версии со стороны проекта PHP.
Учитывайте ревизию пакета. Дистрибутив может включить исправление, сохранив базовый номер PHP. Например, для Ubuntu 24.04 указан исправленный пакет 8.3.6-0ubuntu0.24.04.13. Сверяйте полный номер с USN-8948-1.
Как проверить PHP, который обслуживает сайт
php -v
php --iniЭти команды показывают интерпретатор командной строки и его настройки. Сайт может использовать другой исполняемый файл, другую версию или другой ini-файл. Проверьте также PHP-FPM-пул домена, модуль Apache либо сервис в контейнере. Не размещайте для проверки общедоступную страницу phpinfo().
Включите в инвентаризацию поддомены, тестовые среды и все экземпляры приложения. Для каждого сохраните полный номер пакета, источник обновления и сведения о перезапущенном сервисе.
Как устранить проблему в вашей среде
Управляемый хостинг или cPanel
Попросите провайдера подтвердить исправление обеих CVE и перезапуск затронутых процессов. Выбор «PHP 8.4» в панели не доказывает установку патча. cPanel отдельно отслеживает обновления внутреннего PHP и EasyApache; проверьте официальный бюллетень cPanel.
Сервер под вашим управлением
Проверьте резервную копию и совместимость приложения, затем установите обновления из подходящего источника пакетов. Для Ubuntu с управлением через APT Canonical рекомендует:
sudo apt update
sudo apt upgradeЗатем перезапустите сервис, использующий PHP: например, php8.3-fpm для соответствующего пула или apache2 при mod_php. Названия зависят от установки. Следуйте инструкции Canonical; команды APT не являются универсальной процедурой для серверов cPanel.
Контейнеры Docker
Обновите PHP-образ до исправленной сборки, пересоберите собственные образы и повторно разверните сервисы. Перезапуск старого контейнера сохраняет старый образ. Compose pull загружает образы, а Compose up может пересоздать сервисы с изменённым образом. Проверьте каждую реплику.
Временные меры и проверка результата
Правила WAF и ограничения запросов могут уменьшить доступность отдельных путей атаки. Они не подтверждают исправление движка. У временной настройки memory_limit = -1 есть компромисс: снятие лимита PHP может повлиять на доступность сервера без отдельного контроля ресурсов. Не применяйте её автоматически; учитывайте рекомендации исследователей и в первую очередь устанавливайте патч.
После обновления подтвердите используемый сайтом пакет и перезапуск процессов. Проверьте вход, загрузку файлов и основные сценарии приложения. Изучите журналы и необычные изменения. Патч не удаляет файлы и механизмы постоянного доступа, оставленные предыдущим взломом.
При подозрении на компрометацию сохраните доказательства, ограничьте доступ к затронутой среде и организуйте расследование. Восстановление может потребовать развёртывания из проверенного источника и замены раскрытых учётных данных после локализации инцидента.
Для помощи с инвентаризацией PHP, обновлением и проверками после работ обратитесь к услугам Nikba по поддержке, безопасности и инфраструктуре. По обслуживанию приложения прочитайте также руководство по оптимизации WordPress.
