На сервере, которым управлял атакующий, обнаружен набор инструментов для эксплуатации уязвимостей PHP2Shell. Каталог сервера был открыт без аутентификации, поэтому любой, кто знал адрес, мог прочитать его содержимое. Среди файлов нашлась цепочка удалённого выполнения кода, собранная и проверенная в лабораторных условиях. Рядом лежали скрипты, которые проверяли публичные сайты на условия, нужные этой цепочке.
Описание
По данным SOCRadar Threat Intelligence Unit (STRU), файлы собраны пассивно из открытого листинга каталога на одном из хостов, который платформа зафиксировала в ходе охоты на угрозы. С самими сайтами-целями исследователи не взаимодействовали, и весь разбор построен на содержимом каталога. Успешной эксплуатации не зафиксировано ни на одном проверенном сайте.
Основной файл - скрипт на Python, который автор называет эксплойтом для запуска в одно действие. Он рассчитан на PHP 8.4.26 под Apache с модулем mod_php и работает через обычные HTTP-запросы. Цепочка делится на три шага. Сначала скрипт перезапускает рабочий процесс PHP на цели. Затем раскрывает адреса памяти через cookie сессии и обходит рандомизацию адресного пространства (ASLR). Последний шаг использует обработку прогресса загрузки файлов в сессии для запуска команды в оболочке.
В комплекте идут два профиля настройки: один для официального контейнера PHP 8.4.26 с Apache, второй для собственной лабораторной сборки. По умолчанию целью выбран локальный хост. Это указывает на оператора, который проверял цепочку на подконтрольных контейнерах. Даже при выполнении всех условий нагрузка запускает лишь короткую команду, поэтому для реальной атаки нужен второй этап. Выбор mod_php совпадает с бюллетенем PHP, где такие установки отнесены к наиболее рискованным. Ужесточённые настройки остановили цепочку в лаборатории, но риск снимает только переход на исправленный выпуск.
К лабораторной работе примыкают три скрипта, которые переносят её на реальные сайты. Весь их трафик идёт через пул прокси на том же сервере, прокси меняются между целями. Первый скрипт прошёл по списку примерно из двадцати сайтов. География включает Европу, Северную Америку и Азию, в том числе Великобританию, Финляндию, Польшу, Францию, Канаду, США и Китай. Версию PHP он определяет по заголовкам ответа сервера, а затем отправляет небольшой составной запрос с полем прогресса загрузки и случайным идентификатором сессии. Так проверяется, возвращает ли сайт этот идентификатор.
Второй скрипт изучил одиннадцать сайтов из того же списка подробнее. Он запрашивает страницу, которая должна вызвать предупреждение PHP, и смотрит, показываются ли ошибки посетителям. Дальше идут шесть типовых адресов страницы с выводом настроек PHP, одиннадцать типовых параметров для включения файлов и загрузка файла с уникальным именем-меткой для проверки внедрения в сессию.
Сохранённые результаты охватывают эти одиннадцать сайтов: среди них университет, некоммерческие организации и небольшие компании. Шесть сайтов работали на выпусках PHP 8.4 старше исправления, четыре из них работали на 8.4.26. Остальные сообщали о ветках 8.3, 8.2 или о снятой с поддержки 5.6. При этом ни один сайт не показывал ошибки, не открывал страницу с настройками PHP, не обнаружил возможности включения файлов и не возвращал тестовый идентификатор сессии. Ни один из одиннадцати сайтов не выполнил условий, на которые рассчитана цепочка.
Целевой уязвимостью с умеренной уверенностью названа CVE-2026-109618: на это указывает использование механизма прогресса загрузки в сессии и привязка к 8.4.26, последнему уязвимому выпуску ветки. По состоянию на 22 октября 2026 года признаков доступа к оболочке ни на одном проверенном сайте не найдено. Автор инструментов не установлен. Другие файлы на том же сервере нацелены на криптовалютные и Web3-платформы, что говорит о финансовом мотиве.
Третий скрипт обратился к пяти сайтам на WordPress. Он собирает имена пользователей через REST API и перенаправления авторов, проверяет около двух десятков популярных плагинов, перечисляет методы XML-RPC и испытывает pingback, а также ищет открытые отладочные журналы.
Помимо PHP-эксплуатации, на сервере лежат средства для сбора ключей API и внутренних адресов из клиентского JavaScript сайтов. Там же есть перебор веб- и API-маршрутов, включая административные, на доступ без аутентификации, пул прокси и автоматическое решение капчи. Описанные признаки дают приблизительную картину: определение версии PHP по заголовкам и проверка ошибок могут ошибаться, а настройки сайтов меняются со временем. Отсутствие доступа к оболочке на одиннадцати сайтах не означает, что оператор не добился результата в других местах.
Индикаторы компрометации
