21 октября 2026 года PHP объявил о двух критических уязвимостях, которые могут позволить удалённое выполнение кода без аутентификации. В тот же день проект выпустил исправления для веток 8.5, 8.4, 8.3 и 8.2 и рекомендовал пользователям обновиться без промедления. Уязвимыми могут быть установки, обслуживающие веб-запросы, включая PHP-FPM, Apache mod_php, php-cgi, FrankenPHP и LiteSpeed, сообщает PHP.

Исправленные версии — PHP 8.5.12, 8.4.27, 8.3.36 и 8.2.35. Выпуски закрывают CVE-2026-109618, связанную с повреждением состояния при нехватке памяти, и CVE-2026-109619 — ошибку, при которой состояние одного запроса могло сохраниться в рабочем процессе и использоваться при обработке следующего. Версии ниже перечисленных затронуты; для PHP 8.1 и более старых веток проект больше не выпускает собственные обновления, поэтому администраторам таких систем следует проверить наличие исправлений у поставщика дистрибутива или LTS-поддержки.
Две ошибки в жизненном цикле веб-запроса
В случае CVE-2026-109618 обработка запроса может прерваться из-за нехватки памяти, пока внутренние данные ещё не прошли полную инициализацию. При завершении PHP затем может обратиться к некорректному состоянию. В advisory разработчики описывают, в частности, сценарии с multipart-запросами и исчерпанием лимита памяти. Для Apache mod_php подтверждён сценарий, при котором проблема возникает ещё до запуска кода приложения; PHP также отмечает, что риск для этой конфигурации выше.
CVE-2026-109619 затрагивает состояние, сохраняемое рабочим процессом между запросами. Если операция завершается ошибкой до очистки данных, память предыдущего запроса освобождается, а ссылка на неё остаётся. Следующий запрос, попавший в тот же процесс, может обратиться к устаревшему состоянию до обычной инициализации. В advisory проекта PHP описывает подтверждённые пути через ранние диагностические операции и обработку прогресса загрузки файлов; применимость конкретного пути зависит от конфигурации, приложения и используемых расширений.
Обе уязвимости получили оценку 9,2 по CVSS 4.0. По данным PHP, подтверждённое воздействие включает выполнение кода с привилегиями веб-воркера. В advisory для ошибки нехватки памяти подтверждён полноценный HTTP-сценарий против mod_php; для PHP-FPM источник описывает анализ кода и условия восприимчивости, поэтому эти данные важно различать при оценке конкретного развёртывания.
Что проверить администраторам
Сначала определите версии PHP, которые реально обслуживают веб-трафик: на одном сервере могут работать отдельные CLI-, FPM- и Apache-сборки, а контейнеры и узлы кластера обновляются независимо. Для каждой поддерживаемой ветки установите соответствующий исправленный выпуск либо пакет поставщика с подтверждённым патчем. Затем перезапустите все PHP-воркеры и проверьте их версию после перезапуска — замена файлов без перезапуска оставляет старые процессы работающими.
Для PHP 8.1 и старше проверьте статус поддержки и доступность обратного исправления у дистрибутива или LTS-провайдера. Если такого пакета нет, запланируйте переход на поддерживаемую ветку. PHP указывает, что поставщики Linux-дистрибутивов получили патчи заранее; номер версии пакета у них может отличаться от официального релиза PHP, поэтому сверяйте именно сведения о включённом исправлении.
Временные настройки и фильтрация запросов могут сократить отдельные пути атаки, но проект называет обновление единственным полным способом устранить обе проблемы. Практический приоритет для команд — инвентаризация всех веб-воркеров, установка исправленного пакета, перезапуск процессов и проверка результата на каждом узле. Именно это закрывает подтверждённые уязвимости, вместо того чтобы полагаться на одну лишь конфигурацию веб-сервера.