Очередной 0day без официального патча
Очередной 0day без официального патча Не успели админы во всем мире выпить валерьянки после миллионных сканов PHP2Shell, как команда PHP подкинула новый повод для бессонницы. В стеке обнаружена свежая RCE-дыра CVE-2026-115560, и официального бинарного патча под нее пока попросту нет. Разработчики решили не выпускать экстренный хотфикс, посчитав сценарий редким, но для баг-хантера любое «маловероятно» - это прямой вызов и повод расчехлить сканеры. Архитектурный рассинхрон Вектор атаки бьет в старый механизм отслеживания прогресса загрузки файлов (session upload progress), включенный в движке по умолчанию. Брешь активируется из-за конфликта грамматик десериализации сессий в памяти веб-сервера. Что сразу бросилось в глаза при препарировании логики: - Исходный параметр session.serialize_handler в php.ini задан как php_binary или php_serialize. - Приложение на лету динамически меняет обработчик через вызов ini_set('session.serialize_handler', 'php') строго до исполнения session_start(). - Встроенный функционал upload progress пишет служебные данные сессии в одном формате сериализации, а парсер пытается прочитать их по правилам другого. - Имя ключа в загрузке контролируется атакующим через POST-запрос, открывая прямой путь к serializer confusion. Вектор атаки и механика эксплуатации Для исполнения произвольного кода злоумышленнику достаточно отправить многочастный multipart/form-data запрос на эндпоинт, принимающий файлы. В скрытое поле с прогрессом загрузки внедряется сериализованный пейлоад с контролируемыми объектами. Из-за разницы в кодировании ключей между php_serialize и легаси-хендлером php движок путает границы данных. Служебный байт превращается в префикс нового объекта, вызывая мгновенную десериализацию контролируемого класса прямо в памяти рабочего процесса. В легаси-кодовой базе фреймворков десятилетней давности такой кульбит встречается куда чаще, чем думают разработчики ядра. Мнение специалиста о мнимом спокойствии Как специалист по информационной безопасности, предостерегаю от опасной иллюзии: аргумент «это специфическая конфигурация, поэтому патчить не к спеху» регулярно хоронит корпоративные периметры. В энтерпрайзе и самописных CMS разработчики сплошь и рядом переопределяют хендлеры сессий через ini_set(), чтобы подружить старые модули с новыми базами данных. Оставлять в ядре языка боевой вектор RCE без вендорского бинарника - это игра в русскую рулетку с автоматизированными ботнетами. Безопасность не терпит компромиссов: если уязвимость существует в коде, атакующие напишут под нее фаззер. Митигация и чеклист для защиты серверов Пока официальный апдейт отложен до следующего планового релиза, закрываем периметр вручную одной строкой конфига: ⚙🚨 - Открыть рабочий php.ini и жестко прописать директиву: session.upload_progress.enabled = 0. - Перезапустить демоны веб-серверов и пулы php-fpm для применения изменений в памяти. - Провести аудит исходников проекта командой grep -rn "session.serialize_handler" . на предмет runtime-смены хендлеров. - Настроить правила WAF на блокировку аномально длинных значений ключа прогресса загрузки в multipart-запросах.