PHP2Shell: критические уязвимости PHP от 21 октября 2026

Краткая статья для тех, кто, на бронепоезде, как и я, зашёл в том числе и на профильный modx.pro в поисках практических рекомендаций для MODX помимо релизов PHP и сообщений провайдеров, собрал немного инфы и порядок действий.

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

21 октября 2026 года были обнаружены, а следом и опубликованы исправления двух критических уязвимостей PHP CVE-2026-109618 и CVE-2026-109619, обе с оценкой 9,2 по CVSS v4.0. В кулуарах в ходу название PHP2Shell, возможное последствие: выполнение кода без авторизации с правами процесса PHP.

Первая проблема связана с обработкой исчерпания памяти и некорректным состоянием данных запроса, вторая — с использованием состояния предыдущего запроса после освобождения памяти. Для отдельных сценариев атака подтверждена на mod_php и PHP-FPM.

Парни из PHP относят к группе риска все установки, обслуживающие веб-запросы: PHP-FPM, Apache с mod_php, php-cgi, FrankenPHP и LiteSpeed. Поэтому нужен исправленный PHP.

Какие версии исправлены
Ветка / Релиз с исправлениями
8.2 / 8.2.35
8.3 / 8.3.36
8.4 / 8.4.27
8.5 /8.5.12

PHP 8.1 и старше больше не получают обычных обновлений от проекта PHP. Для этого инцидента команда предоставила минимальные исходные backport-патчи для 7.4, 8.0 и 8.1. Пользователям этих веток нужно уточнить наличие исправленной сборки, либо переходить на поддерживаемую ветку ну и с проверкой совместимости конечно.

У дистрибутивов номер может отличаться от таблицы. Например, для Ubuntu 24.04 исправленный пакет PHP 8.3 указан как 8.3.6-0ubuntu0.24.04.13. Поэтому смотрим полный номер пакета и бюллетень поставщика, а не только 8.3.x

В объявлении PHP от 21 октября также было отдельное предупреждение об отсутствии обновлений в этот день в rpms.remirepo.net. Если используете этот репозиторий, проверьте его текущий статус и доступность исправленной сборки.

Если обновить прямо сейчас невозможно

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

Для CVE-2026-109619:

• отключить session.upload_progress.enabled
• на PHP 8.5 также отключить fatal_error_backtraces
• применить настройки до разбора запроса и перезапустить все workers. Для отключения upload progress нельзя полагаться на ini_set() или FPM .user.ini.

Это закрывает подтверждённые пути, но не все варианты уязвимости. Скрытие предупреждений через display_errors, error_reporting или @ защитой не является.

Для CVE-2026-109618 описана административная установка memory_limit=-1, без возможности вернуть конечный лимит настройками приложения. Она убирает один управляемый способ вызвать исчерпание памяти, но не исключает сбой выделения памяти на уровне ОС. Такая конфигурация требует отдельного контроля ресурсов: PHP предлагает рассмотреть контейнеры/cgroups и прямо предостерегает от использования RLIMIT_AS и RLIMIT_DATA для этой цели.

Также PHP рекомендует ограничивать размер POST-запросов: ориентиры — 8M без необходимости загрузки файлов и 32M при её наличии, с upload_max_filesize < post_max_size. Дополнительные ограничения нужны на уровне веб-сервера или прокси. Это временное снижение риска, а не замена патча.

Провайдеры уже публикуют уведомления и рекомендации. Beget сообщил о временных ограничениях на виртуальном хостинге и серверах под своим администрированием, а также о приоритетном обновлении поддерживаемых версий PHP после выхода исправлений. Timeweb Cloud призывает владельцев VPS установить исправленные пакеты и перезапустить PHP-FPM. MODX Cloud уже подтвердил завершение установки патчей для всех представленных на платформе веток от PHP 7.4 до 8.3.

В практическую плоскость: на виртуальном хостинге запросите подтверждение установки исправлений для обеих CVE. Если у вас VPS без администрирования — задача ложится на ваши плечи или на вашего системного администратора.

Официальное предупреждение PHP и ссылки на технические бюллетени.