Команда PHP 23 октября сообщила о CVE-2026-115560 — отдельном пути к удалённому выполнению кода, связанном с отслеживанием загрузки файлов. Он возникает при редком сочетании конфигурации и действий приложения. Пока готовится штатное исправление, разработчики рекомендуют отключить session.upload_progress.enabled. Тем, кто сделал это после предыдущего предупреждения, настройку следует сохранить.
Где встречаются загрузка файла и сессия
Session upload progress позволяет приложению узнавать, какая часть файла уже принята сервером. Пока идёт загрузка, сведения о её ходе записываются в сессию; приложение может запрашивать их отдельно и показывать пользователю индикатор. В данных есть, например, время начала, объём запроса, число обработанных байтов и признак завершения.
Здесь важна последовательность: PHP записывает сведения о загрузке ещё до запуска скриптов приложения. Поэтому работа с этой функцией начинается раньше, чем страница или плагин выполнят собственный код управления сессией. Руководство PHP отдельно отмечает эту особенность — она объясняет, почему при проверке важны и серверная конфигурация, и дальнейшие действия программы.
Для новой уязвимости должны совпасть три условия: в конфигурации выбран session.serialize_handler=php_binary либо php_serialize, приложение через ini_set() переключает его на php до вызова session_start(), а отслеживание загрузки остаётся включённым.
Сам параметр session.serialize_handler определяет формат преобразования данных сессии для хранения и обратного чтения. Способ хранения, в свою очередь, задаёт session.save_handler. При разборе кода полезно искать именно смену формата сериализации и её положение относительно запуска сессии.
Что сделать администратору
Временная мера — установить session.upload_progress.enabled=0. Команда PHP особо обращается к тем, кто уже применил её после сообщения от 21 октября:
«Если вы применили эту меру тогда, оставьте её в силе: дополнительных действий не требуется».
Отключается встроенное отслеживание хода загрузки. Приложениям, использующим его для индикатора прогресса, нужно проверить соответствующую функцию интерфейса: именно она зависит от данных, которые PHP перестанет записывать в сессию.
Применять настройку следует до разбора запроса — через php.ini, конфигурацию PHP-FPM или сервера. В связанном бюллетене от 21 октября команда указывала на необходимость перезапустить все рабочие процессы PHP. Для проверки результата важны параметры того PHP, который обслуживает сайт: PHP в командной строке может оказаться другим экземпляром.
На стороне приложения нужно проверить действующие плагины и собственный код: где задаётся обработчик сериализации, меняется ли он во время запроса и когда запускается сессия. Так администратор и разработчик проверяют разные части одной цепочки.
Как это связано с предыдущими брешами
22 октября мы рассказывали о профилактических ограничениях доступа к сайтам в Латвии после обнаружения двух критических уязвимостей PHP. CERT.LV тогда оценивал число потенциально затронутых ресурсов примерно в 6000; ограничения вводили, чтобы дать администраторам время установить исправления.
Обновления от 21 октября закрывают CVE-2026-109618 и CVE-2026-109619 и остаются необходимыми. CVE-2026-115560 команда рассматривает в обычном цикле исправлений из-за редкости нужной комбинации; полный бюллетень обещан вместе со следующим выпуском. Практическая задача сейчас — сохранить ранее применённую меру и проверить настройки сессии вместе с кодом, который их меняет.
#SECURITY #TECH
@digitaltimeslv
Схема digital times по предупреждению PHP от 23 октября.
Original in Telegram: https://t.me/digitaltimeslv/11099