PHP2Shell: критические уязвимости PHP, позволяющие выполнять произвольный код без аутентификации AI

1. Общие сведения.

21 октября 2026 года Wiz Research опубликовала исследование PHP2Shell. Обнаруженные ошибки затрагивают ядро PHP и позволяют выполнять код без аутентификации либо раскрывать память процесса. Исследователи продемонстрировали атаки на WordPress, Drupal и Joomla. Это примеры затронутых приложений: причина находится в интерпретаторе, а не в отдельном плагине CMS.

По данным Wiz, хотя бы одна из ошибок присутствует в версиях начиная с PHP 5.4. Возможность эксплуатации конкретного сервера зависит от версии, конфигурации и обработки запросов. Источник: исследование Wiz Research.

2. Что это за уязвимости.

PHP2Shell — общее название двух критических уязвимостей безопасности памяти. В бюллетене PHP Group они описаны следующим образом:

• CVE-2026-109618 — повреждение состояния при нехватке памяти (OOM). Сбой выделения памяти прерывает инициализацию данных запроса. При очистке частично сформированные структуры могут обрабатываться как корректные, что создаёт условия для повреждения памяти и выполнения кода.
• CVE-2026-109619 — использование устаревшего глобального состояния. Внутренние ссылки переживают освобождение памяти запроса. Следующий запрос того же рабочего процесса может обратиться к ним до завершения штатной инициализации.

Обе проблемы относятся к движку PHP. Обновления CMS и её расширений сами по себе не исправляют интерпретатор. Источник: PHP Group, 21.10.2026.

Общая проблема связана с аварийным завершением запроса: после освобождения памяти внутреннее состояние PHP может содержать устаревшие ссылки. Последующий запрос использует некорректные данные. В исследовании рассмотрены обработка прогресса загрузки, десериализация, трассировка фатальных ошибок и OPcache.

Утечка памяти представляет самостоятельную угрозу: в ней могут оказаться пароли, токены и ключи API. Для такой утечки выполнение команд не обязательно. Wiz также отмечает роль ИИ в поиске ошибок и адаптации исследовательских цепочек эксплуатации.

3. Исправленные версии и временные меры.

Команда PHP выпустила исправления для CVE-2026-109618 и CVE-2026-109619. Проверять следует именно среду, обслуживающую веб-запросы: PHP-FPM, mod_php, CGI или другой используемый обработчик.

Для пакетов дистрибутива необходимо проверить бюллетень поставщика: исправление может быть перенесено в пакет без перехода на указанный upstream-релиз. Для PHP 8.1 и старше нужно подтвердить наличие поддерживаемого исправления у поставщика либо запланировать переход на поддерживаемую ветку.

Временные меры закрывают лишь отдельные пути атаки. Например, отключение session.upload_progress.enabled требует настройки до разбора запроса и перезапуска всех рабочих процессов. Оно не устраняет остальные варианты. Полное решение — обновление PHP. Подробности и ограничения приведены в бюллетене команды PHP от 21 октября 2026 года.

4. Практическая проверка инфраструктуры.

4.1. Инвентаризация.

Для первичного сбора сведений об установленном командном интерпретаторе можно использовать следующие команды, которые показывают версию, пути конфигурации и загружаемые модули:

php -v
php --ini
php -m

4.2. Контроль обновления.

Для каждого сервиса зафиксируйте владельца, доступность из Интернета, используемый обработчик, версию пакета и подтверждение исправления. После обновления проверьте вход, загрузку файлов, фоновые задания и другие критичные операции приложения. Для контейнеров проверьте образ запущенного экземпляра, а не только обновлённый тег в реестре.

5. Признаки атаки.

Часть обработки происходит до выполнения кода приложения. Поэтому журнал CMS может содержать мало сведений, а отсутствие подозрительных событий не подтверждает, что атаки не было.

Для первичного поиска Wiz предлагает сопоставлять необычные multipart-запросы с ошибками нехватки памяти, ответами HTTP 500, аномальными cookie PHPSESSID и перезапусками PHP-воркеров. Это поводы для проверки, а не доказательство компрометации.

Практически полезно объединить в одной временной шкале access/error-логи веб-сервера, журналы PHP-FPM и телеметрию процессов. В PHP-FPM расположение журнала ошибок задаёт error_log; возможна отправка в syslog. Аварийные завершения процессов и связанные перезапуски следует учитывать при анализе стабильности пула. См. документацию PHP-FPM.

5.1. Что сопоставлять в журналах и телеметрии.

• Необычно большие или повреждённые значения PHPSESSID в ответах сервера.
• Аномальные multipart-запросы, включая chunked-передачу или отсутствие Content-Length, множество частей и необычные имена полей; особенно важна их связь по времени с ошибками памяти и HTTP 500.
• Необъяснимые аварийные завершения и перезапуски рабочих процессов PHP.
• Нетипичные дочерние процессы веб-сервера.

5. Признаки атаки.

Часть обработки происходит до выполнения кода приложения. Поэтому журнал CMS может содержать мало сведений, а отсутствие подозрительных событий не подтверждает, что атаки не было.

Для первичного поиска Wiz предлагает сопоставлять необычные multipart-запросы с ошибками нехватки памяти, ответами HTTP 500, аномальными cookie PHPSESSID и перезапусками PHP-воркеров. Это поводы для проверки, а не доказательство компрометации.

Практически полезно объединить в одной временной шкале access/error-логи веб-сервера, журналы PHP-FPM и телеметрию процессов. В PHP-FPM расположение журнала ошибок задаёт error_log; возможна отправка в syslog. Аварийные завершения процессов и связанные перезапуски следует учитывать при анализе стабильности пула. См. документацию PHP-FPM.

5.1. Что сопоставлять в журналах и телеметрии.

• Необычно большие или повреждённые значения PHPSESSID в ответах сервера.
• Аномальные multipart-запросы, включая chunked-передачу или отсутствие Content-Length, множество частей и необычные имена полей; особенно важна их связь по времени с ошибками памяти и HTTP 500.
• Необъяснимые аварийные завершения и перезапуски рабочих процессов PHP.
• Нетипичные дочерние процессы веб-сервера.
• Новые PHP-файлы в веб-каталоге, изменения заданий cron и SSH-ключей, исходящие соединения на ранее не наблюдавшиеся адреса. Такие события требуют проверки контекста.

5.2. Действия при подозрении на компрометацию.

Согласуйте изоляцию узла с командой реагирования, сохраните журналы веб-сервера и PHP, телеметрию процессов и сведения об изменённых файлах. Определите, какие секреты были доступны процессу PHP. При подтверждённой компрометации или обоснованном подозрении на утечку отзовите затронутые токены и ключи, смените пароли и завершите соответствующие сессии; новые секреты выдавайте в доверенной среде.

6. Заключение.

Завершать проверку следует подтверждением исправленного пакета в работающем веб-обработчике и результатов функциональной проверки сайта. В карточке работ полезно сохранить дату, ответственного, проверенную версию и ссылку на бюллетень поставщика. При обнаружении признаков компрометации обновление нужно дополнить расследованием и оценкой необходимости отзыва затронутых учётных данных.

7. Источники.

1. PHP Group. Security advisory: Critical remote code execution vulnerabilities, update now.
2. Wiz Research. PHP2Shell.
3. PHP2Shell — сводная страница исследователей.