Две критические уязвимости в ядре PHP — CVE-2026-109618 и CVE-2026-109619 (CVSS v4.0 9.2) — спровоцировали волну сканирования и попыток эксплуатации в течение часов после раскрытия 21 октября 2026 года. Уязвимости позволяют неаутентифицированное удалённое выполнение кода через специально сформированные HTTP-запросы и затрагивают все версии PHP до 8.2.35, 8.3.36, 8.4.27 и 8.5.12. По данным нескольких независимых исследовательских групп — Sophos, Arctic Wolf и Hunt.io — ни одна из наблюдаемых попыток не привела к подтверждённой компрометации. Мы уже писали о технических деталях этих уязвимостей и мерах защиты; данный материал сосредоточен на анализе реальной активности атакующих и причинах, по которым эксплуатация оказалась сложнее ожидаемого.
Природа уязвимостей и масштаб поверхности атаки
Согласно бюллетеню CERT/CC (VU#763488), CVE-2026-109618 представляет собой уязвимость повреждения памяти в механизме обработки нехватки памяти (OOM) PHP: при определённых условиях частично инициализированные данные запроса могут быть доступны во время очистки. CVE-2026-109619 — это уязвимость типа «использование после освобождения» (use-after-free), при которой устаревшее глобальное состояние, принадлежащее одному запросу, повторно используется последующим запросом того же рабочего процесса.
Уязвимый код присутствует в PHP начиная с версии 5.4 (2012 год), что означает, что проблема затрагивает не конкретное приложение, а сам движок PHP. Любой сайт на WordPress, Drupal или Joomla с чистым прикладным кодом остаётся уязвимым, если PHP не обновлён. Затронуты конфигурации PHP-FPM, Apache mod_php, php-cgi, FrankenPHP и LiteSpeed. По данным CERT/CC, Apache mod_php представляет наибольший риск, поскольку эксплуатация может произойти до выполнения кода приложения.
По оценкам Censys, на момент 23 октября 2026 года более 34,4 миллиона PHP-сервисов оставались потенциально уязвимыми из общего числа свыше 56,6 миллиона веб-свойств, использующих PHP. Организации на PHP 7.4, 8.0 или 8.1 не получают официальных обновлений безопасности от PHP Project и нуждаются в бэкпортах от дистрибутивов или миграции на поддерживаемую ветку.
Активность атакующих: много шума, ноль результатов
Широкомасштабное сканирование и попытки эксплуатации начались в течение 45 минут после публичного раскрытия уязвимостей. По данным Arctic Wolf, наблюдаемая активность варьировалась от базовых проверок уязвимого поведения механизма отслеживания прогресса загрузки сессий PHP до попыток подтвердить выполнение команд ОС.
Принципиально важный факт: Sophos первоначально сообщила об успешной эксплуатации PHP2Shell у своих клиентов, но затем скорректировала эту оценку, указав, что телеметрия показала только сканирование и неудачные попытки без доказательств успешной компрометации. Hunt.io независимо подтвердила этот вывод: единственный обнаруженный оператор массовой эксплуатации совершил десять проходов по 123 серверам и не получил ни одного шелла. Эту же картину фиксируют Wordfence, Previdian, Beelzebub и Dataminr.
Основная причина неудач атакующих — необходимость обхода ASLR (Address Space Layout Randomization), механизма рандомизации адресного пространства, который делает непредсказуемым расположение кода в памяти. VulnCheck разработала метод, цепляющий обе уязвимости для обхода ASLR на x86-64 системах с рекомендуемыми производственными настройками PHP, однако подчеркнула, что создание такого эксплойта «далеко от тривиального». Это объясняет разрыв между массовым сканированием и отсутствием успешных атак.
Ботнет Potassium и инфраструктура атак
Наблюдаемый трафик эксплуатации связан с Potassium — вариантом ботнета Mirai, впервые зафиксированным платформой Synthient в марте 2026 года. Связь установлена на уровне инфраструктуры и образцов вредоносного ПО тремя независимыми исследовательскими группами (Sophos, Arctic Wolf, Hunt.io), однако конкретный ответственный злоумышленник не идентифицирован. Важно подчеркнуть: доказательства связывают PHP2Shell-запросы с инфраструктурой Potassium, но не подтверждают, что ассоциированные образцы были загружены и выполнены через эти уязвимости.
По данным Sophos, образец Potassium устанавливает TCP-соединение с C2-сервером 134.199.154[.]64, отправляет HTTP-запрос и ожидает в ответ Linux ELF-бинарник. Ботнет поддерживает 24 команды для проведения DDoS-атак по протоколам ICMP, TCP, UDP и OpenVPN. Среди технических особенностей — использование ChaCha20 для шифрования статической таблицы конфигурации (впервые для вариантов Mirai), DNS-схема перенаправления с перестановкой 16-битных половин каждой записи A, а также неактивная, но встроенная поддержка разрешения C2-инфраструктуры через Ethereum Name Service (ENS).
Отдельно SOCRadar обнаружила на открытом сервере атакующего (206.188.197[.]105:9999) набор инструментов для эксплуатации PHP2Shell, включая скрипт aslr_exploit.py — эксплойт для PHP 8.4.26 под Apache mod_php, работающий в три этапа: перезапуск PHP-воркера, утечка адресов памяти через cookie сессии для обхода ASLR, и злоупотребление механизмом отслеживания прогресса загрузки сессий для выполнения команды.
Индикаторы компрометации
Ключевые IOC из исследований:
- IP-адреса источников атак: 85.11.167[.]243, 217.60.242[.]76, 45.198.224[.]169
- Инфраструктура загрузки: 92.118.112[.]100, 206.188.197[.]105
- C2-сервер: 134.199.154[.]64 (TCP-порт 50792)
- Домены: thunder[.]godofthunder[.]st, hackattackkaboom[.]botlesscucks[.]st
- Хеши образцов: 0c5486f06620e26e316f4b33f318b0d646d5e1133789331aa2fed012360d1486, e2529d4afa39ae4db2eb05d5176317c906289abf09660c75bdeec43e54c55aa3
Практическое обнаружение попыток эксплуатации
По данным Hunt.io и Arctic Wolf, для разграничения попыток сканирования и реальной компрометации следует коррелировать несколько сигналов:
- User-Agent, содержащий строки вида
php2shell-scan/109618илиphp2shell-109618 - Multipart POST-запросы с полем
PHP_SESSION_UPLOAD_PROGRESSи аномально большим телом - Всплески ошибок «Allowed memory size exhausted» в логах PHP-FPM
- Последующая активность: создание процессов, изменения в корневом каталоге веб-сервера, исходящие сетевые соединения к перечисленным C2-адресам
Наличие первых трёх признаков указывает на попытку эксплуатации; четвёртый — на возможную компрометацию, требующую немедленного расследования.
Рекомендации
- Немедленно обновите PHP до версий 8.2.35, 8.3.36, 8.4.27 или 8.5.12, как рекомендует CERT/CC
- Организации на PHP 8.1 и ниже не получают обновлений от PHP Project — необходима миграция на поддерживаемую ветку или применение бэкпорта от дистрибутива
- Проверьте логи веб-серверов на наличие перечисленных IOC и паттернов эксплуатации
- Заблокируйте сетевые соединения к указанным C2-адресам и доменам на уровне периметра
- Для конфигураций Apache mod_php рассмотрите временный переход на PHP-FPM, который предоставляет дополнительную изоляцию процессов
Текущая ситуация с PHP2Shell напоминает ранние дни Log4Shell: уязвимый код существует более десяти лет, затрагивает движок, а не приложение, и не имеет патчей для устаревших веток. Отсутствие подтверждённых компрометаций на данный момент — следствие технической сложности обхода ASLR, а не безопасности уязвимых систем. VulnCheck уже продемонстрировала, что этот барьер преодолим. Приоритет для каждой организации, использующей PHP, — обновление до исправленной версии до того, как надёжные эксплойты станут доступны более широкому кругу атакующих.
