21 октября разработчики PHP экстренно закрыли две критические RCE-уязвимости — CVE-2026-109618 и CVE-2026-109619 (9,2 по CVSS 4.0). Обе позволяют при определенных условиях выполнить код без авторизации.Мы не стали выпускать новость в первые часы: анонсов было достаточно, и первым делом необходимо было поставить патч. Нам было важнее понять, как искать следы атаки и что делать, если злоумышленник уже проник в инфраструктуру.
Что выяснилось за пять дней?
1. Атаки начались раньше раскрытия
Amazon Threat Intelligence обнаружила попытки эксплуатации еще 17 октября — за четыре дня до выхода исправлений. Это первая известная дата в их телеметрии, а не начало всех атак.Поэтому при ретроспективном Threat Hunting предлагаем проверять события минимум с 17 октября, а при наличии журналов — с 17 сентября. Дополнительные 30 дней — запас для поиска разведки и подготовки, а не установленный средний срок атаки.
И важный момент: патч устраняет уязвимость, но что делать, если эксплуатация уже произошла?
2. Известно, какие запросы стоит проверять
Многие вендоры уже опубликовали дополнительные механизмы обнаружения PHP2Shell.
Среди признаков:
• необычные POST-запросы с multipart/form-data
• подозрительные сочетания PHP_SESSION_UPLOAD_PROGRESS с параметрами загрузки
• нетипичные размеры и серии запросов
• HTTP 500 вместе с сообщениями PHP о нехватке памяти.
Один POST или HTTP 500 еще не означают атаку. Но аномальные последовательности — повод для проверки. Здесь полезен поведенческий анализ WAF.
С помощью ИИ-генератора ловушек HoneyCorn мы оперативно разработали ловушку на CVE-2026-109618, чтобы видеть подобные атаки на периметр и автоматически их блокировать.
3. После взлома трафик может выглядеть обычным
Представим: атакующий использовал PHP2Shell, получил выполнение кода и создал механизм постоянного доступа.
Первоначальный эксплойт ему больше не нужен. Он может использовать обычный HTTPS, права веб-сервера и доступные приложению подключения. Часть запросов будет выглядеть легитимно. WAF их пропускает, сигнатуры PHP2Shell молчат, сайт продолжает работать.
А злоумышленник все еще внутри.
Поэтому мало искать следы конкретной CVE. Нужно проверять признаки закрепления, внутренней разведки и горизонтального перемещения.
4. Как искать того, кто уже проник?
Здесь полезна связка SOC + Deception.
HoneyCorn размещает ложные сервисы и приманки, не нужные штатным бизнес-процессам. Если атакующий начнет разведку и обратится к такой цели, это создаст дополнительный сигнал о его активности.Аналитики SOC сопоставляют событие с данными WAF, EDR и сетевого мониторинга и восстанавливают картину возможной атаки.
Отсутствие срабатываний не доказывает, что злоумышленников нет. Но такой подход помогает обнаруживать активность, которую не видно по сигнатурам первоначального эксплойта.
Что сделать сейчас?
• Обновить PHP до исправленной версии: 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 или установить патч поставщика.
• Проверить историю запросов, ошибок PHP и событий безопасности с 17 октября; по возможности — с 17 сентября.
• Искать неизвестные файлы, подозрительные процессы, аномальные соединения и обращения к внутренним ресурсам.
• Проверить, способны ли действующие средства защиты увидеть активность после первоначального проникновения.
Уязвимость закрыта. Сигнатуры обновлены. Критических событий нет. Но злоумышленник может оставаться внутри.
Вы уверены, что в вашей инфраструктуре сейчас нет посторонних? И на основании каких данных?
Мы можем помочь с аналитикой инцидента: коммерческий SOC и HoneyPot & Deception на базе HoneyCorn помогут проверить признаки присутствия злоумышленника, подозрительную активность и определить дальнейшие шаги.
Важно не только закрыть уязвимость, но и выяснить, не успели ли ею воспользоваться.
