PHP выпускает исправление двух уязвимостей удалённого выполнения кода в ветках 8.2-8.5

Две уязвимости удалённого выполнения кода в PHP имеют оценку 9.2 по CVSS 4.0 и не требуют аутентификации. Вектор атаки - сетевой, сложность высокая, присутствуют дополнительные требования к условиям эксплуатации. Уязвимы версии ниже 8.2.35, 8.3.36, 8.4.27 и 8.5.12; исправления вышли именно в этих сборках. Публичный эксплойт доступен, сведения об эксплуатации в реальных атаках уже есть. Команда PHP анонсировала релиз на 21 октября 2026 года и допускала досрочный выпуск, если детали станут публичными.

Исчерпание памяти и устаревшее состояние в PHP 8.2-8.5

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

Исчерпание памяти достигается в пределах заявленных лимитов. Составной запрос без пригодной длины тела проходит первичную проверку post_max_size и продолжает передавать декодированные данные. Одна часть формы может содержать неограниченное число заголовков, поэтому их представление внутри PHP занимает заметно больше памяти, чем передано по сети. Пустые поля выбора файлов не учитываются в max_file_uploads, но создают массивы метаданных; вложенные имена полей, в свою очередь, умножают эту работу.

Устаревшее состояние между запросами одного воркера

Вторая уязвимость, CVE-2026-109619, относится к классу "использование после освобождения" (use-after-free: обращение к уже освобождённой памяти). Воркер PHP хранит глобальное состояние - ошибки, сессии, объекты, расширения, - которое указывает на память одного запроса. Сбрасывать его нужно до освобождения памяти запроса. Часть операций ввода, конфигурации, сессий и обработки ошибок выполняется раньше обычной инициализации следующего запроса. Они обращаются к устаревшему состоянию, и подготовленная раскладка кучи (области динамической памяти) даёт полное удалённое выполнение кода.

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

Охват зависит от интерфейса сервера приложений (SAPI). Apache mod_php безусловно запускает завершение запроса даже при неудачном старте и подтверждён как цель. PHP-FPM завершает дочерний процесс при сбое старта, поэтому первый сценарий там не проходит; второй путь через сессии на FPM валидирован. FrankenPHP по анализу кода вызывает завершение безусловно, LSAPI повторяет модель FPM - оба остаются вероятными кандидатами. Вектор CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N фиксирует сетевую атаку без привилегий, высокую сложность и полное влияние на конфиденциальность, целостность и доступность.

Версии исправлений и настройки, снижающие риск

Полное исправление - обновление до 8.2.35, 8.3.36, 8.4.27 или 8.5.12. Патч убирает аварийный выход при нехватке памяти: вместо него вводится отложенная мягкая обработка на ближайшей безопасной точке виртуальной машины, а при достижении второго, более высокого порога процесс жёстко завершается. Для второй уязвимости патч расширяет сброс состояния. Ветка 8.6 пока представлена только тестовой сборкой 8.6.0 RC3, которую команда не рекомендует использовать в рабочей среде.

Установкам без возможности обновления доступны частичные меры. Для первой уязвимости это административно заданный memory_limit=-1: он снимает предсказуемый пер-запросный лимит, после чего нужно перезапустить все воркеры и убедиться, что ни один пул, каталог или настройка приложения не возвращает конечное значение. Консервативный post_max_size с независимой проверкой размера тела на фронтенде, снижение max_input_nesting_level и ограничение числа переменных, частей формы, заголовков и загрузок уменьшают риск отказа в обслуживании. Если приложение не использует составные формы, такие запросы блокируют на фронтенде.

Для второй уязвимости на PHP 8.5 отключают fatal_error_backtraces, а session.upload_progress.enabled=0 убирает показанный путь через сессии. Ограничение pm.max_requests=1 сокращает число запросов на воркер и сужает окно между операциями. Аудит с error_reporting=E_ALL и log_errors=On помогает найти повторяющиеся предупреждения до запуска скриптов; однако отсутствие записей в журнале не доказывает безопасность конфигурации.

Две независимые уязвимости дают неаутентифицированное выполнение кода на самых распространённых конфигурациях PHP. Оценка 9.2, доступный эксплойт и подтверждённая эксплуатация ставят обновление в первый приоритет для всех установок на ветках 8.2-8.5.

Исчерпание памяти и устаревшее состояние в PHP 8.2-8.5

Устаревшее состояние между запросами одного воркера

Версии исправлений и настройки, снижающие риск

Ссылки