PHP предупреждает о новой RCE-уязвимости CVE-2026-115560 через два дня после экстренного исправления PHP2Shell

23 октября PHP Foundation опубликовал информационное уведомление о новой уязвимости удалённого выполнения кода — CVE-2026-115560. Проблема появилась спустя всего два дня после экстренного выпуска патчей для двух критических уязвимостей PHP2Shell (CVE-2026-109618 и CVE-2026-109619, CVSS 9.2). Новая уязвимость затрагивает веб-приложения с нетипичной конфигурацией обработчика сессий и не исправлена выпущенными ранее обновлениями. PHP не планирует экстренного патча и рекомендует отключить функцию session upload progress до следующего планового релиза. Ранее мы уже подробно разбирали уязвимости PHP2Shell — новая проблема расширяет поверхность атаки, хотя и при более узких условиях.

Технические детали CVE-2026-115560

Уязвимость CVE-2026-115560 может привести к удалённому выполнению кода, но только при одновременном выполнении нескольких условий. Приложение должно:

• Установить параметр session.serialize_handler в значение php_binary или php_serialize в конфигурации;
• Изменить этот параметр на php во время выполнения через вызов ini_set();
• Сделать это до вызова session_start();
• При этом функция session upload progress должна оставаться включённой (значение по умолчанию).

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

Важно разграничить масштаб воздействия: в отличие от CVE-2026-115560, уязвимости PHP2Shell (CVE-2026-109618 и CVE-2026-109619) затрагивают PHP в конфигурациях по умолчанию и позволяют неаутентифицированному атакующему выполнить произвольный код. Согласно бюллетеню GHSA-w8hw-w9fx-j79w, CVE-2026-109618 связана с повреждением памяти при исчерпании ресурсов (CWE-416, use-after-free). CVE-2026-109619, описанная в бюллетене GHSA-6wmf-4rv5-p3rp, позволяет глобальному состоянию запроса указывать на освобождённую память и быть использованным последующим запросом того же рабочего процесса. Обе оценены PHP Group в 9.2 по CVSS v4.0 и исправлены в версиях PHP 8.5.12, 8.4.27, 8.3.36 и 8.2.35. Версии PHP 8.1 и старше больше не получают обновлений безопасности от проекта PHP.

Активность злоумышленников

На момент публикации уведомления попыток эксплуатации CVE-2026-115560 не зафиксировано. Однако две ранее исправленные уязвимости PHP2Shell активно сканируются. По данным Cloudflare, количество попыток эксплуатации выросло с десятков тысяч в первые 45 минут после раскрытия 21 октября до миллионов к утру 22 октября. Sophos и Arctic Wolf сообщали о попытках установки варианта ботнета Mirai через эти уязвимости, хотя подтверждённого успешного выполнения кода зафиксировано не было — построение надёжного эксплойта оказалось сложнее, чем ожидалось.

По данным CYFIRMA, зафиксирована кампания целенаправленного сканирования с 21 скомпрометированного узла, направленная на 216 хостов в государственном секторе, финансовых организациях, логистике, авиации и производстве в США, Японии, Южной Корее и других странах. Сканирование ведётся в режиме «low-and-slow» — малыми объёмами с ротацией узлов, что затрудняет обнаружение пороговыми системами оповещения. CYFIRMA с умеренной уверенностью связывает кампанию с корейскоязычным оператором, предположительно аффилированным с экосистемой Lazarus Group, однако эта атрибуция не подтверждена независимыми источниками, а массовая компрометация через PHP2Shell не зафиксирована.

Следует отметить, что Unit 42 (Palo Alto Networks) отозвал своё первоначальное заявление о том, что атака на европейское правительственное учреждение была связана именно с уязвимостями PHP2Shell, — подтвердить эту связь не удалось. Это важная поправка: на данный момент нет независимо подтверждённых случаев успешной эксплуатации PHP2Shell для получения начального доступа.

Рекомендации по обнаружению

Поскольку наблюдаемая кампания использует тактику медленного сканирования с ротацией IP-адресов, стандартные пороговые правила оповещения могут её пропустить. Защитникам целесообразно:

• Проводить ретроспективный анализ журналов веб-серверов и сетевого трафика за расширенный период;
• Отслеживать цепочки процессов, порождённых рабочими процессами PHP (PHP-FPM, mod_php);
• Искать в логах запросы с маркерами PHP_SESSION_UPLOAD_PROGRESS и multipart-загрузки без полезной нагрузки;
• Обращать внимание на последовательность: POST-запрос с ответом 500, ошибка исчерпания памяти PHP, повреждение кучи и аварийное завершение рабочего процесса Apache.

Unit 42 опубликовал поисковые запросы для обнаружения потенциальной постэксплуатационной активности в контексте PHP-серверов, а также входящих попыток эксплуатации с использованием multipart-запросов и upload progress.

Практические рекомендации

1. Обновите PHP до версий 8.5.12, 8.4.27, 8.3.36 или 8.2.35 — это закрывает CVE-2026-109618 и CVE-2026-109619.
2. Отключите session upload progress, установив session.upload_progress.enabled=0 в конфигурации PHP и перезапустив все рабочие процессы. Эта мера одновременно смягчает CVE-2026-115560 и является рекомендованным обходным решением для CVE-2026-109619. PHP предупреждает, что отключение этой настройки не покрывает все варианты устаревшего состояния.
3. Проверьте конфигурацию приложений: если ваш код не переключает session.serialize_handler во время выполнения через ini_set(), вы не подвержены CVE-2026-115560 через этот вектор.
4. Аудит устаревших версий: PHP 8.1 и старше не получают обновлений безопасности от проекта PHP. Уточните у вашего дистрибутива или поставщика LTS-поддержки наличие бэкпортированных исправлений.

Обновление PHP на хосте — единственный полноценный способ устранения уязвимостей PHP2Shell. Изменение кода приложения, обновление плагинов CMS или правила WAF не заменяют патч рантайма. Организациям, которые уже отключили session upload progress после рекомендаций от 21 октября, дополнительных действий для CVE-2026-115560 не требуется. Тем, кто этого не сделал, следует применить эту настройку немедленно и запланировать обновление PHP до ближайшего планового релиза, который будет содержать полное исправление.