Команда PHP раскрыла уязвимость PHP, которая при редком сочетании настроек способна привести к удалённому выполнению кода. Патча для CVE-2026-115560 пока нет, но разработчики уже назвали временную меру: отключить отслеживание прогресса загрузки файлов в сессиях. Для команд, которые поддерживают старые PHP-приложения или нестандартно управляют конфигурацией во время выполнения, это повод проверить продакшен до очередного релизного окна.
Проблема затрагивает не любую установку PHP, а довольно специфическую схему работы с сериализацией сессий, сообщает BleepingComputer. В конфигурации приложения параметр session.serialize_handler должен быть изначально установлен в php_binary или php_serialize, затем изменён на php через ini_set() до вызова session_start(). Кроме того, в системе должен оставаться включён механизм отслеживания прогресса загрузки сессий.
Эксплойт требует редкой, но реальной конфигурации
По оценке команды PHP, такой набор условий встречается нечасто. Поэтому исправление CVE-2026-115560 не выпускают вне графика: полный бюллетень и патч обещают опубликовать в следующем регулярном релизе. Это не означает, что риском можно пренебречь. «Маловероятная» конфигурация нередко оказывается вполне обычной в системах с долгой историей: там, где настройки меняли для совместимости, код мигрировал между фреймворками, а поведение сессий когда-то корректировали точечно и забыли задокументировать.
Практическая рекомендация проста: установить session.upload_progress.enabled=0. Если администраторы уже отключали эту функцию в рамках защиты от других недавних проблем PHP, повторно менять ничего не нужно. Приложения, которые вообще не меняют обработчик сериализации сессий на лету, могут оставить upload progress включённым, указывают разработчики языка. Но это решение стоит принимать после проверки конфигурации и кода, а не по памяти о том, «как у нас обычно устроено».
Для инженерных команд полезно начать с поиска вызовов ini_set('session.serialize_handler', ...) и аналогичной логики в обёртках над настройками. Затем нужно сверить фактические значения в окружениях: локальная разработка, тестовый контур и production часто расходятся именно в PHP-конфигах. Отдельно стоит проверить контейнерные образы, шаблоны развёртывания и панели управления хостингом: временная мера работает лишь там, где параметр действительно применяется к запущенному процессу PHP.
Новая проблема появилась на фоне атак на PHP2Shell
Сообщение о CVE-2026-115560 вышло почти сразу после экстренных обновлений для двух других критических RCE-уязвимостей — CVE-2026-109618 и CVE-2026-109619, известных под общим названием PHP2Shell. Патчи к ним PHP выпустил в среду, 21 октября. До публикации обновлений в сети уже появлялись доказательства концепции, хотя команда PHP заявляла, что доступные на тот момент варианты не работали. Ситуацию осложнила утечка части сведений: в публичный доступ попали идентификаторы CVE и рекомендации по защите, ранее переданные некоторым операторам критической инфраструктуры.
Несколько компаний в области кибербезопасности, включая Cloudflare, watchTowr, Previdian, Hadrian и Patchstack, фиксировали неудачные попытки эксплуатации ещё до публичного раскрытия деталей. Amazon Threat Intelligence сообщила, что атаки на PHP2Shell начались за четыре дня до выхода патчей. По словам директора по информационной безопасности AWS Си Джея Мозеса, инфраструктура атакующих и полезные нагрузки различались, что может указывать на нескольких участников. При этом на момент публикации технический анализ продолжался, а успешность таких атак на реальных системах не была подтверждена.
Dataminr TRACE 22 октября описала наблюдаемую активность как сканирование, снятие отпечатков сервисов и применение нерабочих эксплойтов; известных компрометаций исследователи не увидели. Но в этом нет повода расслабляться: как только появляется рабочий код для массового сканирования, разрыв между публикацией бюллетеня и первыми попытками взлома обычно измеряется не неделями. Широкое распространение PHP делает этот риск особенно заметным: VirusTotal оценивает число доступных из интернета PHP-хостов более чем в 5,1 млн, а около 3,8 млн из них имеют хотя бы один открытый для атак порт.
Для бизнеса эта уязвимость PHP — напоминание, что управление обновлениями не сводится к установке свежей версии пакета. CVE-2026-115560 пока требует инвентаризации настроек и быстрой компенсационной меры, а PHP2Shell — проверки факта установки октябрьских обновлений и журналов на признаки сканирования. Для разработчиков главный вопрос теперь не в том, насколько экзотична конкретная цепочка с сериализацией, а в том, может ли команда быстро доказать отсутствие такой цепочки в своих сервисах. Чем старше стек и чем больше в нём конфигурации, накопленной «на всякий случай», тем дороже обходится этот вопрос.
