Amazon зафиксировала попытку эксплуатации уязвимостей PHP2Shell 17 октября — за четыре дня до публичного раскрытия и выхода патчей. После публикации информации Cloudflare увидела уже миллионы запросов с эксплойтами: для российских команд это повод не ограничиваться обновлением PHP, а проверить логи и признаки компрометации как минимум с 17 октября.
Речь идёт о CVE-2026-109618 и CVE-2026-109619 с оценкой критичности 9,2 из 10. Ошибки связаны с обработкой памяти в самом рантайме PHP и потенциально позволяют неаутентифицированному атакующему выполнить произвольный код на сервере. По данным The Register, масштаб риска здесь заметно шире очередной дыры в плагине CMS: под ударом могут оказаться приложения на PHP независимо от того, используют ли они WordPress, Laravel, собственный фреймворк или вообще обходятся без CMS.
Глава Cloudflare Мэтью Принс сообщил, что компания заметила тысячи попыток эксплуатации ещё за десять часов до публичного анонса. Через 45 минут после раскрытия их число выросло до десятков тысяч, через два часа — до сотен тысяч, а затем дошло до миллионов. Такая динамика хорошо показывает, насколько коротким стал промежуток между появлением технических деталей и массовой автоматизированной атакой: резервное окно на «обновим на выходных» в этот раз могло исчезнуть ещё до начала рабочего дня.
Эксплойты меняются на ходу
Атакующие не просто повторяют один и тот же запрос. Cloudflare наблюдает, как они меняют полезную нагрузку, пытаясь обойти правила веб-фаервола. Судя по картине, злоумышленники используют ответы на заблокированные запросы как обратную связь и подбирают варианты, которые могут пройти защиту. WAF в такой ситуации полезен как временный барьер, но не как индульгенция от установки исправлений: правило защищает от известных техник, тогда как сам дефект остаётся в рантайме.
Компания Hadrian 21 октября также сообщила, что PHP2Shell эксплуатируется в реальных атаках в заметном масштабе. Большая часть наблюдаемых ею попыток использует путь PHP, связанный с индикатором прогресса загрузки в сессии. Исследователи ожидают появления и других путей эксплуатации — до выпуска исправлений и после него. Для защитников это означает, что поиск по одному шаблону запроса или единственному IP-адресу даст скорее ощущение контроля, чем полноценную картину.
Самая неприятная деталь пришла от Amazon Threat Intelligence. Сеть ханипотов MadPot получила попытку атаки 17 октября с анонимизированного IP-адреса, когда информация об ошибках ещё находилась под эмбарго. Amazon не утверждает, что этот запрос обязательно сработал бы против реальной инфраструктуры, и не знает, откуда оператор получил данные для эксплойта. Но попытка обращения к специально подготовленной ловушке выглядит как активность атакующего, а не случайный эксперимент разработчика.
21 октября MadPot увидел несколько proof-of-concept-эксплойтов. Самый ранний появился примерно в 02:00 UTC, то есть примерно за 12 часов до публикации патчей. В следующие шесть часов запросы шли через разную анонимизированную инфраструктуру и несли разные полезные нагрузки. Amazon считает, что это больше похоже на работу нескольких участников, а не одной группы. Иными словами, уязвимости PHP2Shell попали в оборот ещё до того, как большинство администраторов узнало об их существовании.
Патч — только начало расследования
Раскрытие уже сопровождалось спором вокруг цепочки поставки. PHP Foundation обвинила поставщика решений для безопасности цепочек поставки Chainguard в том, что тот выпустил исправленные сборки PHP раньше согласованного срока и тем самым мог помочь атакующим сориентироваться. Однако находка Amazon от 17 октября не позволяет свести всю историю к этому эпизоду: по крайней мере один актор, вероятно, начал проверять цель заранее.
Практический приоритет для владельцев PHP-инфраструктуры — установить доступные патчи на все затронутые серверы и убедиться, что обновились не только контейнерные образы или CI-сборки, но и реально работающие экземпляры. Затем стоит проверить журналы веб-серверов, WAF, PHP-FPM и средства мониторинга за период с 17 октября: необычные обращения к обработчикам загрузки, серии неудачных запросов с меняющимися параметрами, запуск незнакомых процессов и изменения файлов требуют отдельной проверки. Командам с внешними подрядчиками и несколькими контурами особенно важно сверить версии PHP по факту, а не по данным инвентаризации, которая иногда оптимистичнее реальности.
Эта история вновь делает видимым неудобный факт: критическая ошибка в популярном интерпретаторе — это не только задача для администратора, которому нужно поставить обновление. Это проверка скорости реагирования всей организации: кто получает уведомление, кто понимает охват, кто может без лишних согласований обновить продакшен и кто ищет следы атаки, если эксплойт появился раньше бюллетеня. Подробности массовой кампании и заявление Cloudflare можно сверить в материале ; главный открытый вопрос теперь не в том, начнутся ли новые сканирования, а в том, сколько серверов уже успели проверить до патча.
