Если после уязвимости PHP2Shell вы обновили сайт компании до PHP 8.5.12, 8.4.27, 8.3.36 или 8.2.35, вы поступили правильно, но это закрывает не всё. 23 октября 2026 года проект PHP опубликовал новое предупреждение о третьей уязвимости, CVE-2026-115560, которую обновление 21 октября не исправляет. Для неё нужна необычная конфигурация, и PHP считает этот путь атаки маловероятным, но временное решение простое: попросите сегодня команду или хостинг установить session.upload_progress.enabled в 0 и перезапустить PHP, а затем письменно подтвердить, что обновление 21 октября действительно установлено.

Что PHP объявил 23 октября?

Через два дня после экстренного релиза проект опубликовал короткое информационное предупреждение об отслеживании «прогресса загрузки» в сессиях. Это функция, которая показывает пользователю, какая часть большого файла уже загружена. Согласно предупреждению, в одном конкретном случае она может открыть путь к удалённому выполнению кода, а исправление выйдет в следующем плановом релизе, а не экстренным обновлением, вместе с полным бюллетенем об уязвимости.

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

Уязвим ли ваш сайт?

Согласно предупреждению PHP, проблема возникает только при одновременном выполнении трёх условий:

  • Конфигурация PHP задаёт session.serialize_handler значение php_binary или php_serialize.
  • Код приложения во время работы меняет его на php через ini_set() до запуска сессии.
  • Отслеживание прогресса загрузки в сессиях по-прежнему включено, как и по умолчанию.

Большинство сайтов так не делают. Проблема в том, что владелец редко знает, что делает каждая строка в системе, созданной много лет назад, или в старом плагине. Поэтому самый безопасный выбор такой: если ваш сайт не показывает полосу прогресса при загрузке файлов, отключение функции ничего не сломает и закроет дверь. Если сайт от неё зависит, спросите разработчиков, меняет ли код эту настройку во время работы.

Три дня спустя: проверьте, что обновление 21 октября действительно применено

Исходные уязвимости, CVE-2026-109618 и CVE-2026-109619, по-прежнему представляют больший риск. Национальное управление кибербезопасности Саудовской Аравии (NCA) выпустило по ним предупреждение № 2026-7949, а американское агентство CISA рекомендовало провести инвентаризацию всех систем на PHP, в первую очередь обновить доступные из интернета и отключить систему, если её нельзя обновить сразу. CISA сообщило, что на момент публикации не наблюдало успешной эксплуатации, но это не значит, что время работает на вас.

Три момента, которые многие упускают:

  • Перезапуск, а не перезагрузка конфигурации. Бюллетень Red Hat указывает, что изменения конфигурации требуют перезапуска процессов PHP, а одной перезагрузки конфигурации недостаточно.
  • На серверах Linux номер версии может отличаться. Объявление PHP сообщает, что дистрибутивы Linux получили патчи заранее, поэтому вы можете увидеть номер, отличный, например, от 8.5.12, хотя исправление установлено. Попросите хостинг дать письменное подтверждение, а не только номер. Red Hat отмечает, что затронуты RHEL 8, 9 и 10.
  • Способ запуска PHP меняет уровень риска. Проект PHP считает риск наибольшим для mod_php на Apache, а Red Hat говорит, что со стандартным PHP-FPM эксплуатация на практике сложнее. Сложнее не значит невозможно, поэтому обновление нужно в обоих случаях.

5 вопросов, которые стоит отправить хостингу или команде сегодня

  1. Какая версия PHP работает на каждом нашем сайте и в каждой системе, и включает ли она исправления от 21 октября 2026 года?
  2. Были ли процессы PHP после обновления перезапущены, а не просто перезагружены?
  3. Установили ли мы session.upload_progress.enabled в 0? Если нет, нужна ли нам эта функция на самом деле?
  4. Меняет ли код нашего сайта session.serialize_handler во время работы?
  5. Есть ли у нас сайт на 8.1 или более старой версии? Эти ветки больше не поддерживаются, а таблица поддерживаемых версий показывает, что поддержка безопасности для 8.2 заканчивается 31 декабря 2026 года.

Взгляд Origami

Три предупреждения за три дня после серьёзной уязвимости — это нормально: когда исследователи изучают одну часть языка, они находят и то, что рядом. Но это говорит кое-что и о компаниях. Тот, кто обновился 21-го и закрыл вопрос, пропустит предупреждение 23-го. Безопасность здесь — это постоянное сопровождение, а не задача, которую выполняют один раз.

В саудовских компаниях мы видим, что трудный вопрос не «что за уязвимость?», а «кто у нас в пятницу утром читает предупреждение PHP и знает, какой сервер наш?». В Origami мы создаём сайты и системы и следим за их обновлениями с первого дня. Если вы хотите проверить сайт или применить эти настройки без остановки сервиса, свяжитесь с нами.

Итог

Обновление 21 октября обязательно и остаётся главным; новое предупреждение этого не меняет. Добавьте сегодня один недорогой шаг: отключите отслеживание прогресса загрузки, если оно вам не нужно, перезапустите PHP и получите письменное подтверждение от хостинга. Затем следите за следующим плановым релизом PHP, который принесёт окончательное исправление CVE-2026-115560.

Источники