Экстренное обновление PHP закрывает критические дыры — миллионы сайтов под угрозой удаленного выполнения кода

22 Окт 2026 170

Более двенадцати лет — столько прошло с релиза PHP 5.4 — по умолчанию в интерпретаторе жил механизм, позволяющий захватить контроль над сервером без авторизации и загрузки файлов. 21 октября 2026 года команда разработчиков выпустила экстренные сборки 8.5.12, 8.4.27, 8.3.36 и 8.2.35, устраняющие пару критических уязвимостей с идентификаторами CVE-2026-109618 и CVE-2026-109619.

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

Два механизма компрометации: нехватка памяти и висячие указатели

Первая уязвимость (CVE-2026-109618) кроется в обработке нехватки памяти. Когда процесс исчерпывает лимит memory_limit, срабатывает обработчик, вызывающий longjmp(). Этот прыжок прерывает выполнение в момент, когда внутренние структуры запроса лишь частично инициализированы. Функция завершения запроса (shutdown) всё равно пытается обработать эти структуры как готовые, обращаясь к невыделенной памяти. Атакующий провоцирует это состояние, заливая серверmultipart-запросами без заголовка Content-Length или с избыточным числом заголовков, обходя post_max_size.

В mod_php эксплойт работает надежно, так как shutdown вызывается даже при крахе. В PHP-FPM дочерний процесс умирает, что усложняет атаку, но не исключает её теоретически.

Вторая проблема (CVE-2026-109619) — классическое use-after-free в глобальном состоянии, привязанном к запросу. Фатальная ошибка, таймаут или та же нехватка памяти оставляют указатели на освобожденную память активными. При обработке следующего запроса в том же воркере интерпретатор обращается к «мусору». Вектором становится обработчик прогресса загрузки session.upload_progress, который срабатывает автоматически при любом multipart/form-data. В PHP 8.5 усугубляет ситуацию новый обработчик fatal_error_backtraces, не сбрасывающий состояние трассировки. Этот вектор подтвержден для mod_php, а первый работает и в PHP-FPM.

Простые обходные пути не работают

В сети сразу появились рекомендации отключить session.upload_progress.enabled. Однако и представители проекта, и авторы PoC-эксплоитов подтверждают: этого недостаточно для блокировки обеих уязвимостей. Полная защита без патча требует блокировки всех multipart-запросов на уровне веб-сервера (Apache, nginx, Caddy), что ломает любую загрузку файлов.

Эксплоиты уже опубликованы: они подбирают смещения структур в памяти для популярных дистрибутивов, делая атаку практичной.

Многослойная защита до применения патчей

Разработчики и исследователи безопасности предлагают комплекс мер, снижающий риски, но не исключающий их полностью. Приоритет — установка обновлений. Пока пакеты не дошли до репозиториев дистрибутивов (Debian, Ubuntu, RHEL, Arch и др.), рекомендуется:

Установить memory_limit=-1, лишая атакующего возможности контролировать момент срабатывания OOM-хендлера.
Жестко ограничить post_max_size (например, 8M) и убедиться, что upload_max_filesize меньше.
Настроить лимиты памяти через cgroups (memory.max) на уровне контейнера или системы, избегая RLIMIT_AS/RLIMIT_DATA, которые провоцируют опасный longjmp.
Перевести PHP-FPM в режим pm.max_requests=1 и Apache в MaxRequestsPerChild 1 — это заставит воркеры перезапускаться после каждого запроса, сбрасывая грязное состояние.
Отключить session.upload_progress.enabled=0 и в PHP 8.5 — fatal_error_backtraces=0 строго в php.ini или конфиге пула, но не через .user.ini или ini_set().
Убрать из конфигов директивы, генерирующие предупреждения на ранней стадии (неверные open_basedir, устаревшие assert.*).
Исправить код приложения, устраняющий фатальные ошибки и таймауты в колбэках.
Понизить max_input_nesting_level и применить правила блокировки multipart в веб-сервере, если функционал загрузок не нужен.

Ситуация демонстрирует, как десятилетний технический долг в ядре интерпретатора превращается в вектор массовой компрометации. Обновление — единственное гарантированное решение; остальные меры лишь откладывают момент взлома. Администраторам следует мониторить страницы безопасности своих дистрибутивов и катить патчи в приоритетном порядке.