Опубликованы корректирующие выпуски PHP 8.5.12, 8.4.27, 8.3.36 и 8.2.35, а также патчи для уже не поддерживаемых веток PHP 7.4, PHP 8.0 и PHP 8.1, в которых исправлены две критические уязвимости:

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

  Основным вектором атаки является манипуляция с multipart-запросами для создание условий для исчерпания доступной процессу памяти. Для обхода лимита post_max_size может не указываться заголовок Content-Length и передаваться огромное число HTTP-заголовков. Возможно проведение и точечных атак на конкретные операции в php-приложениях, чрезмерно расходующих память. Наличие эксплоита подтверждено для mod_php, так как он вызывает функцию shutdown() даже при сбое. PHP-FPM при сбое завершат дочерний процесс, что затрудняет проведение атаки, но теоретически её не исключает.

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

  Для эксплуатации может использоваться создание условий исчерпания доступной памяти при обработке multipart-запроса в коде для индикации прогресса загрузки (session.upload_progress). При этом в качестве основного и подтверждённого вектора атаки упоминается обработчик fatal_error_backtraces в PHP 8.5, который не сбрасывает состояние трассировки при завершении. В первом случае атака возможна на mod_php и PHP-FPM, а во втором только на mod_php. Также упоминается неподтверждённая возможность проведения атаки в конфигурациях, в настройках которых имеются директивы, приводящие к выводу предупреждений на ранней стадии обработки запроса (например, предупреждения об использовании устаревших параметров).

Заявлено, что полное блокирование уязвимостей возможно только через установку обновления. Следующие меры позволяют снизить вероятность успешного проведения атак, но не делают систему полностью безопасной:

• Выставление в php.ini параметра "memory_limit=-1", что затрудняет возможность атакующего контролировать исчерпание лимитов на память.
• Выставление параметра "post_max_size = 8M", если нет необходимости в загрузке больших файлов. Значение параметра "upload_max_filesize" должно быть меньше параметра "post_max_size".
• Задание лимита на допустимое потребление памяти на системном уровне, через cgroup memory.max или параметры потребления памяти контейнером, но не через системные лимиты RLIMIT_AS и RLIMIT_DATA, которые лишь провоцируют проблемный вызов longjmp().
• Если производительность не важна можно ограничить число запросов, обрабатываемых одним рабочим процессом через pm.max_requests=1 в PHP-FPM и MaxRequestsPerChild в Apache httpd.
• Выставление на уровне php.ini или конфигурации сервера (не через ini_set() или FPM .user.ini, так как параметр должен действовать до начала обработки запроса) параметра "session.upload_progress.enabled=0".
• При использовании выпуска PHP 8.5 следует установить параметр "fatal_error_backtraces=0".
• Удаление привязанных к отдельным запросам устаревших или ошибочных настроек (типа assert.* и неверных путей в open_basedir), приводящих к выводу диагностических сообщений до инициализации.
• Устранение в PHP-коде ситуаций, приводящих к достижению таймаутов и фатальных ошибок, например, связанных со сбоями в callback-обработчиках и обработкой загрузок.
• Для блокирования первой уязвимости в коде старых версий PHP можно заменить вызов longjmp() в обработчике исчерпания свободной памяти на _exit().
• Дополнительно можно уменьшить значение параметра max_input_nesting_level в php.ini и блокировать multipart-запросы, как было показано в предварительном анонсе.