Команда PHP выпустила экстренные обновления для двух критических RCE-уязвимостей: CVE-2026-109618 и CVE-2026-109619. Объединённые названием уязвимости PHP2Shell, они позволяют неавторизованному атакующему выполнить код с правами веб-процесса — а значит, требуют внимания не только от разработчиков, но и от владельцев WordPress, Drupal, Joomla и самописных сервисов на PHP.
Проблема затрагивает PHP-инсталляции, которые обрабатывают веб-запросы: PHP-FPM, Apache с mod_php, php-cgi, FrankenPHP и LiteSpeed. Как сообщает BleepingComputer, наиболее рискованным вариантом разработчики PHP считают mod_php: для него уже продемонстрирован сценарий, при котором вредоносный запрос срабатывает до запуска прикладного кода. Обычный WAF, проверка авторизации в приложении или аккуратный роутинг в таком случае оказываются за линией атаки, а не перед ней.
Две ошибки вокруг аварийного завершения запроса
Обе уязвимости связаны с тем, как PHP обращается с памятью, когда обработка HTTP-запроса завершается нештатно. CVE-2026-109618 использует цепочку слабостей, приводящую к повреждению памяти в условиях нехватки памяти. Конечный результат — выполнение кода от имени учётной записи, под которой работает веб-воркер.
CVE-2026-109619 построена на устаревшем глобальном состоянии. Она может привести к use-after-free в куче, раскрытию данных из памяти и выполнению кода без аутентификации. Для атакующего это особенно ценный класс багов: доступ к приложению не нужен, а уровень привилегий определяется настройками веб-сервера и PHP-пула. Если воркер имеет лишние права на файловую систему, внутренние сервисы или секреты окружения, последствия могут уйти далеко за пределы одного сайта.
Исправления уже вошли в PHP 8.5.12, 8.4.27, 8.3.36 и 8.2.35. Серверы на этих ветках следует обновить до соответствующего релиза как можно быстрее. Пользователям PHP 7 и более ранних версий рекомендовано перейти на поддерживаемую версию либо уточнить у поставщика ОС или LTS-сборки наличие бэкпорта. Официальный проект PHP больше не выпускает обновления для PHP 8.1 и старше, но подготовил минимальные исходные бэкпорты для 7.4, 8.0 и 8.1 — прежде всего для тех, кто собирает интерпретатор самостоятельно или не получает патчи от LTS-вендора.
Это не тот случай, когда можно ограничиться записью задачи в следующий спринт. За день до выхода обновлений разработчики PHP публично предупредили администраторов заранее, оставив за собой возможность выпустить патчи раньше при публикации технических деталей или признаках эксплуатации. После релиза CTO Cloudflare Дейн Кнехт подтвердил, что компания уже видела ранние попытки атак на PHP2Shell. Cloudflare развернула правила WAF для известных способов эксплуатации, но сам Кнехт подчеркнул: это временный барьер, а не замена обновлению.
Что проверить на проде до и после обновления
Для российской команды типичная зона риска — не только основной продукт, но и забытые PHP-сервисы: старый корпоративный портал, лендинг на CMS, панель партнёров, админка у подрядчика, отдельный сайт вакансий. Инвентаризация здесь важнее красивого дашборда: нужно найти версии PHP на хостах, контейнерах, виртуальных машинах и managed-хостинге, затем сопоставить их с путями обработки веб-запросов. CLI-интерпретатор без веб-нагрузки — не главный сценарий из описанных, тогда как FPM-пулы и mod_php требуют приоритета.
После обновления стоит убедиться, что перезапущены именно веб-воркеры, а не только пакет установлен в системе. Полезно также проверить версию из того же окружения, в котором обслуживается трафик: образ контейнера, FPM-пул и локальный PHP в shell нередко живут разной жизнью. Отдельно имеет смысл пересмотреть права сервисных аккаунтов, секреты в переменных окружения, сетевые разрешения и доступ PHP-процессов к каталогам загрузок. Патч закрывает первичное проникновение, но не исправляет избыточные привилегии, которые могут усилить ущерб при следующем инциденте.
Если обновление прямо сейчас невозможно, команда PHP опубликовала меры, уменьшающие экспозицию, но не устраняющие её. Для CVE-2026-109618 предлагается установить memory_limit=-1 так, чтобы приложение не могло переопределить параметр, например через php_admin_value в конфигурации FPM-пула или Apache. Также рекомендуется снизить post_max_size до 8 МБ для приложений без загрузки файлов либо до 32 МБ при необходимости загрузок, а ограничение доступности вынести в контейнер или cgroup. В идеале лимит должен завершать только затронутый воркер, а не весь сервис.
Для CVE-2026-109619 временный набор другой: отключить session.upload_progress.enabled и перезапустить все воркеры. В PHP 8.5 дополнительно предлагается задать fatal_error_backtraces=0; это перекрывает только подтверждённый путь через fatal backtrace. Разработчикам также советуют убрать некорректные или устаревшие настройки, которые применяются к запросу и выводят диагностические сообщения до инициализации, а также исправить достижимые извне фатальные ошибки и тайм-ауты. Подавление вывода через error_reporting, display_errors или оператор @ не считается защитой.
На фоне миллионов публично доступных PHP-хостов уязвимости PHP2Shell быстро станут проверкой зрелости эксплуатации: кто-то закроет их обычным rollout за часы, а кто-то обнаружит, что не знает, где работают его FPM-пулы и кто отвечает за обновление CMS. В этот раз временные настройки могут купить немного времени, но постоянный ответ один: обновить PHP и сократить привилегии веб-процессов до действительно необходимых.
