21 октября 2026 года разработчики PHP выпустили экстренные исправления для CVE-2026-109618 и CVE-2026-109619, получивших общее название PHP2Shell. Обе ошибки связаны с управлением памятью и при определённых условиях позволяют выполнить произвольный код на сервере без авторизации. Риск касается сайтов на PHP, включая конфигурации с Nginx и PHP-FPM; для Ubuntu уже опубликованы отдельные исправленные пакеты.
PHP2Shell затрагивает сам движок PHP и может обойти защиту приложения
Название PHP2Shell объединяет две уязвимости с критической оценкой 9,2 балла по CVSS 4.0. Термин remote code execution (RCE) означает, что злоумышленник способен запустить собственный код на удалённом сервере. В данном случае для возможной атаки не требуется предварительно входить в панель управления сайтом.
Речь идёт об ошибках внутри PHP — языка, который обрабатывает серверную часть сайтов на WordPress, Drupal, Joomla и многих других системах. Поэтому качество кода конкретного сайта само по себе не устраняет риск: опасный путь может находиться глубже, в механизме обработки запросов.
До раскрытия PHP2Shell администратор мог исходить из того, что обновлённая CMS и закрытая административная панель существенно ограничивают пути атаки. Опубликованные 21 октября технические бюллетени описывают сценарии, в которых уязвимость возникает ещё во время обработки HTTP-запроса самим PHP. При успешной эксплуатации последствия зависят от прав процесса, обслуживающего веб-сайт: возможны доступ к файлам приложения, секретам подключения к базе данных и дальнейшее развитие атаки.
CVE-2026-109618 — сбой при нехватке памяти приводит к повреждению внутреннего состояния
Первая уязвимость связана с обработкой ситуации, когда PHP исчерпывает доступный ему лимит памяти. Такой случай обозначают как out of memory (OOM). При определённом прерывании запроса часть служебных данных остаётся заполненной лишь частично, а процедура завершения пытается использовать её как корректную.
Исследователи продемонстрировали, что повреждение памяти можно довести до удалённого выполнения кода. Для Apache с модулем mod_php подтверждён сценарий, в котором опасная ситуация возникает ещё до запуска кода сайта.
Для PHP-FPM картина отличается. Разработчики PHP указывают, что при некоторых ошибках на раннем этапе FPM завершает рабочий процесс, но приложение всё ещё может привести движок к уязвимому состоянию после обычного запуска запроса. PHP Foundation отдельно подтвердила выполнение кода через такие пути на PHP-FPM.
Исправление меняет обработку нехватки памяти, чтобы служебные структуры не оставались в повреждённом состоянии после аварийного выхода.
CVE-2026-109619 — следующий запрос может получить доступ к уже освобождённой памяти
Вторая ошибка возникает из-за внутреннего состояния, которое PHP сохраняет между запросами в одном рабочем процессе. После завершения запроса память освобождается, но при определённых ошибках отдельные указатели могут продолжать ссылаться на старые данные.
Следующий запрос попадает в тот же процесс и обращается к памяти, которая ему уже не принадлежит. Такой класс проблем называют use-after-free — использование памяти после освобождения. Он способен вызвать сбой процесса, утечку данных или, при подходящих условиях, выполнение постороннего кода.
Почему два последовательных запроса здесь так существенны? PHP-FPM и другие серверные режимы используют рабочие процессы повторно, чтобы не создавать новый процесс при каждом обращении к сайту. Такая обычная оптимизация производительности объясняет, откуда появляется связь между запросами разных посетителей.
В официальном описании CVE-2026-109619 разработчики отдельно рассматривают ошибки, возникающие при работе с настройками, сессиями и обработкой исключений. Исправление устраняет опасное обращение к устаревшему состоянию.
Nginx, Apache и популярные CMS — какие серверы затронуты
PHP официально относит к потенциально уязвимым все установки, обрабатывающие веб-запросы, включая PHP-FPM, Apache с mod_php, php-cgi, FrankenPHP и LiteSpeed. Наиболее высокий риск команда PHP выделяет для mod_php, где подтверждён путь атаки до выполнения кода приложения.
При типичной связке Nginx + PHP-FPM Nginx принимает HTTP-запрос, а динамическую часть передаёт процессу PHP. Поэтому сам факт использования Nginx не защищает от PHP2Shell. Важны версия и происхождение установленного PHP, а также то, какие исправления фактически присутствуют в выполняемом коде.
WordPress, Laravel и Drupal не обязаны иметь собственную ошибку для того, чтобы сайт оказался под угрозой: достаточно уязвимого PHP в серверном окружении. При этом само наличие старой версии не доказывает, что сервер уже взломан.
Для PHP 8.2–8.5 вышли исправленные версии, а старые ветки требуют отдельной проверки
21 октября команда 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 более ранние версии этих веток считаются уязвимыми. Например, PHP 8.3.5 не содержит исправлений, появившихся в PHP 8.3.36.
PHP 8.1 и более старые ветки больше не получают обычных обновлений от проекта. Для PHP 7.4, 8.0 и 8.1 разработчики опубликовали минимальные исходные патчи, а некоторые поставщики Linux поддерживают собственные исправленные сборки. Поэтому проверять безопасность по короткому номеру версии без учёта поставщика пакета бывает ошибочно.
В Ubuntu 24.04 LTS исправление пришло через backport PHP 8.3
В день раскрытия Canonical опубликовала бюллетень USN-8948-1, охватывающий Ubuntu 22.04 LTS, 24.04 LTS, 26.04 LTS и 26.10. Для Ubuntu 24.04 LTS исправленная сборка php8.3-fpm имеет номер 8.3.6-0ubuntu0.24.04.13. Такой же номер указан для соответствующих пакетов php8.3-cli, php8.3-cgi и модуля Apache.
Номер 8.3.6 ниже, чем 8.3.36 в официальной линейке PHP. Ubuntu использует backport: переносит исправление безопасности в поддерживаемый дистрибутивом пакет, сохраняя его основную версию. Именно поэтому для пакетов из официальных репозиториев Ubuntu важен полный номер сборки, включая окончание 0ubuntu0.24.04.13.
Если PHP установлен из стороннего PPA, контейнерного образа или собран вручную, бюллетень Canonical сам по себе не подтверждает безопасность такой установки. Для неё действуют сведения соответствующего поставщика.
Временные ограничения PHP снижают риск, но не заменяют патч
До появления исправлений распространялся совет отключить механизм session.upload_progress, связанный с отслеживанием загрузки файлов. Официальный бюллетень PHP подтверждает, что эта настройка с последующим перезапуском рабочих процессов перекрывает один из известных путей CVE-2026-109619. Другие варианты эксплуатации при этом остаются возможными.
Для CVE-2026-109618 разработчики описали ограничения размеров входящих запросов и отдельные настройки памяти как временные меры. Они затрагивают конкретные способы достижения ошибочного состояния, но не устраняют всю проблему. Менять лимиты памяти без понимания последствий для приложения и сервера тоже небезопасно.
Полное исправление обеих уязвимостей обеспечивают патчи PHP или их проверенные версии, перенесённые поставщиком дистрибутива. Обновление одной CMS, веб-сервера Nginx либо установка дополнительных правил фильтрации не исправляют код уязвимого интерпретатора PHP.
Почему обнаружение PHP2Shell привело к экстренному выпуску патчей
История PHP2Shell началась задолго до октябрьского предупреждения. PHP Foundation сообщила, что признаки первой проблемы с обработкой нехватки памяти разработчики заметили ещё в 2024 году после внешнего аудита. Тогда конкретный путь удалённого захвата оставался неподтверждённым. Работа над исправлением затянулась из-за сложности изменения базовых механизмов PHP.
В августе 2026 года исследователи Calif, OpenAI и Wiz представили дополнительные результаты, показавшие практическую опасность ошибки. При исследовании применялись инструменты искусственного интеллекта. Специалисты PHP Foundation и участники координации затем проверяли варианты атаки, совместимость исправлений и подготовку обновлений для поставщиков.
Первоначально раскрытие планировали на 22 октября. После публикации идентификаторов CVE на форумах 20 октября команда PHP перенесла выпуск на 21 октября, 14:00 UTC. В сети также фигурировала оценка 10 баллов, но разработчики официально установили для обеих уязвимостей 9,2 по CVSS 4.0.
PHP Foundation признала, что длительная работа над ошибкой, признаки которой обнаружили в 2024 году, выявила недостатки в процессе принятия решений и нехватку специалистов, глубоко знающих устройство движка.
После выхода исправлений главным различием стало происхождение установленного PHP
PHP2Shell затронула базовые механизмы обработки запросов, общие для большого количества сайтов и серверных конфигураций. К 21 октября появились исправления для четырёх поддерживаемых веток PHP и отдельных пакетов Linux-дистрибутивов; при этом их номера могут заметно различаться из-за переноса патчей.
Дальнейший масштаб инцидента зависит от того, как быстро обновления попадут на реальные серверы, контейнеры и системы со встроенным PHP. Наличие исправленного пакета в репозитории ещё не показывает, сколько работающих сайтов уже перешли на защищённую сборку.
Источники
- PHP — официальный бюллетень безопасности от 21 октября 2026 года
- PHP Security Advisory — CVE-2026-109618
- PHP Security Advisory — CVE-2026-109619
- PHP Foundation — разбор обнаружения уязвимостей и подготовки исправлений
- Ubuntu Security Notice USN-8948-1 — исправленные пакеты PHP
- Wiz Research — исследование PHP2Shell
