PHP выпустила срочные патчи для двух критических уязвимостей PHP2Shell

21 октября команда PHP выпустила внеочередные обновления для двух критических уязвимостей в ядре языка. Проблемам присвоены идентификаторы CVE-2026-109618 и CVE-2026-109619, а их серьёзность оценена в 9,2 балла из 10. Исследователи назвали цепочку атак PHP2Shell: она позволяет удалённо выполнить код на сервере без учётной записи и без наличия ошибки в самом веб-приложении.

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

Как работают уязвимости

CVE-2026-109618 возникает при исчерпании memory_limit во время разбора входящих данных. Интерпретатор выходит из текущего контекста с помощью longjmp(), оставляя некоторые структуры недоинициализированными. На этапе завершения запроса эти данные могут быть ошибочно приняты за действующие, а часть содержимого контролируется атакующим.

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

Для эксплуатации требуется, чтобы запросы попали в один и тот же процесс-воркер, а атакующему пришлось подстроиться под раскладку памяти. Однако это не является полноценной защитой: подбор параметров можно выполнять серией попыток. Уязвимыми считаются серверы, принимающие HTTP-запросы и исполняющие PHP, включая PHP-FPM, Apache с mod_php, php-cgi, FrankenPHP и LiteSpeed. В режиме mod_php атака особенно опасна, поскольку может сработать до запуска кода приложения.

Масштаб проблемы и первые атаки

Проблема затрагивала все ветки PHP начиная с версии 5.4. Таким образом, за последнее десятилетие не существовало полностью защищённой версии языка. Исследователи Wiz продемонстрировали готовый эксплойт против свежих контейнеров WordPress, Drupal и Joomla, а Sansec сообщила о подтверждённом удалённом выполнении кода в Magento и других приложениях. Само по себе приложение не обязательно должно содержать уязвимость: целью может стать даже минимальная страница на уязвимой версии PHP.

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

Ситуация усугубилась тем, что сведения об уязвимостях появились до официального релиза исправлений. Видео с демонстрацией атаки распространилось по сети, а Cloudflare и watchTowr зафиксировали первые попытки эксплуатации в день публикации патчей.

Что нужно сделать администраторам

Исправления выпущены для следующих веток: PHP 8.2.35, 8.3.36, 8.4.27 и 8.5.12. Обновить пакеты можно через менеджер дистрибутива либо пересобрав контейнер. Плагины и темы обновлять специально из-за этой проблемы не требуется: уязвимость находится в самом PHP.

1. Установите исправленную версию PHP в зависимости от используемой ветки.
2. Перезапустите воркеры PHP-FPM или Apache. Одной установки новых пакетов недостаточно: старое состояние может сохраняться в уже запущенных процессах.
3. Для PHP 8.1 и более старых версий проверьте наличие бэкпорта от поставщика дистрибутива или подготовьте переход на поддерживаемую ветку. Официальные патчи для этих версий не заявлены.
4. До обновления ограничьте внешний доступ к серверу, если он доступен из интернета. Дополнительно можно отключить параметр session.upload_progress.enabled=0, который связан с одним из подтверждённых векторов атаки.
5. Проверьте журналы после обновления: ищите ошибки memory_limit при multipart-запросах, необычно большие значения PHPSESSID и необъяснимые падения воркеров.

Правила для WAF уже выпускали Cloudflare и Akamai, однако они могут лишь выиграть время. По оценке команды PHP, единственным надёжным способом закрыть проблему остаётся установка исправлений и перезапуск процессов, обслуживающих запросы.