WP-SHELLSTORM: открытый сервер атакующих раскрыл массовый взлом WordPress-сайтов через дыру в Breeze

Иногда о масштабной хакерской операции становится известно не из-за громкого взлома, а из-за банальной ошибки самих атакующих. Именно так вышло с кампанией, которую исследователи назвали WP-SHELLSTORM: злоумышленники по недосмотру оставили свой рабочий сервер в открытом доступе, и специалисты по кибербезопасности смогли заглянуть «за кулисы» — увидеть списки целей, эксплойты, журналы и уже установленные бэкдоры. Картина получилась тревожной для всех, кто держит сайт на WordPress.

Что произошло: сервер атакующих оказался в открытом доступе

11 июня 2026 года команда угроз-разведки компании SOCRadar обнаружила в интернете неправильно настроенный сервер на базе Python SimpleHTTPServer по адресу 137.175.93.126 (VPS в США). Из-за ошибки конфигурации каталог был доступен любому желающему: около 800 МБ данных в 434 файлах — веб-шеллы (web shell — вредоносный скрипт-«чёрный ход» для управления сервером через браузер), скрипты-эксплойты, логи и конфигурации управляющей инфраструктуры. Открытым сервер оставался примерно 22 дня, после чего в период со 2 по 4 июля операторы попытались «замести следы» и почистить каталог.

Этого времени хватило, чтобы восстановить полную картину операции. Речь идёт не о случайном скрипт-кидди, а о том, что исследователи называют webshell access brokerage — «брокерством доступа»: злоумышленники массово взламывают сайты, устанавливают на каждый скрытый бэкдор и затем перепродают этот доступ другим преступникам. Взломанный сайт становится товаром.

Масштаб: 1,4 миллиона целей и тысячи установленных бэкдоров

Цифры из утёкших данных впечатляют. В списках атакующих оказалось более 1,4 миллиона доменов — это цели, по которым отрабатывали автоматические сканеры. Не каждая цель была взломана, но результат всё равно масштабный: SOCRadar насчитала свыше 5 700 активных веб-шеллов, реально установленных на скомпрометированных ресурсах. Независимая команда Ctrl-Alt-Intel, которая нашла тот же сервер через платформу открытых директорий Hunt.io, подтвердила порядка 25 000 сайтов с признаками компрометации.

Всего в арсенале группы обнаружили 27 уязвимостей (CVE), поставленных «на поток»: 14 из них имеют критический уровень опасности, ещё 9 — высокий. Атака шла по конвейеру: сканеры получали списки целей из поисковика по интернет-устройствам FOFA, затем автоматически «простреливали» каждую цель набором эксплойтов и при успехе загружали веб-шелл.

Главный «пробойник»: Breeze и уязвимость CVE-2026-3844

Самой результативной оказалась дыра в популярном кэширующем плагине Breeze — CVE-2026-3844. Только по ней атакующие отработали более 45 000 сайтов и получили свыше 17 000 подтверждённых веб-шеллов. Это больше, чем у всех остальных уязвимостей кампании.

Уязвимость получила максимально серьёзную оценку — 9,8 балла из 10 по шкале CVSS (критический уровень). Проблема кроется в функции подгрузки аватаров Gravatar: плагин по указанному URL забирает изображение и сохраняет его локально. Но проверка того, что по ссылке действительно картинка, отсутствовала. Атакующий, контролирующий адрес-источник, мог заставить сервер скачать не изображение, а PHP-скрипт — то есть тот самый веб-шелл. Это классическая unauthenticated file upload (загрузка произвольного файла без аутентификации), ведущая к RCE (remote code execution — удалённому выполнению кода на сервере). Аутентификация при этом не требуется вовсе, а сама атака идёт по сети — то есть находится в самой «лёгкой» для эксплуатации категории.

Под ударом оказались все версии Breeze до 2.4.4 включительно; исправление вышло в версии 2.4.5. Плагин установлен более чем на 400 000 сайтов, так что потенциальная поверхность атаки огромна. Важная деталь: для срабатывания уязвимости должна быть включена опция «Host Files Locally – Gravatars» (локальное хранение аватаров). По умолчанию она выключена — но многие включают её ради ускорения загрузки, не подозревая о рисках.

Какие ещё плагины попали под удар

Breeze был не единственной мишенью. Вторым по «урожайности» стал набор ThemeREX Addons: около 3 378 шеллов на 46 600 целей. Помимо этого, в кампании задействовали целый список известных уязвимостей в плагинах и системах:

Custom CSS JS PHP (CVE-2026-6433), WavePlayer (CVE-2025-12057), Ninja Forms (CVE-2026-0740), устаревший, но всё ещё встречающийся WP File Manager (CVE-2020-25213), а также Simple File List, BerqWP, WPBookit и редактор JCE для Joomla (CVE-2026-48907). Отдельно атакующие охотились за серверами конфигураций Nacos с отключённой аутентификацией. Ключевой вывод: группа не искала «свежие» 0-day — она эксплуатировала уже известные и давно закрытые дыры, делая ставку на то, что тысячи сайтов просто не обновляются.

Кто за этим стоит

Прямой атрибуции нет, но собранные улики указывают на профессионально управляемую, финансово мотивированную киберпреступную группу с китайскими корнями. На это намекают использование FOFA (регистрация в нём требует китайского номера телефона), комментарии в коде на упрощённом китайском и характерные имена пользователей вроде «chen-kk» и «tance». Это не идеологи и не активисты — их цель проста: превратить чужие сайты в ликвидный товар.

Как понять, что ваш сайт взломан

SOCRadar и другие исследователи опубликовали индикаторы компрометации (IOC — indicators of compromise, следы присутствия злоумышленника). Проверьте свой сервер на их наличие:

Подозрительные файлы. Ищите веб-шеллы с характерными именами: .bd.php, .wp-log.php, файлы по маске .brq-*.php и .sd.php. Точка в начале имени делает такие файлы скрытыми в обычном списке — обращайте на это особое внимание.

Сетевые индикаторы. Заблокируйте и проверьте журналы на обращения к адресам 137.175.93.126, 43.108.17.80, 113.196.56.150 и домену xs.xxooonline.eu.cc.

Маскировка процессов. Атакующие маскировали свои процессы под системные, имитируя записи вида [kworker/X:Y] — если видите подозрительный «ядровый» процесс, который на деле таковым не является, это тревожный сигнал.

Что делать прямо сейчас

Первое и главное — обновить Breeze до версии 2.4.5 или новее. Если обновиться прямо сейчас нельзя, как временную меру отключите опцию локального кэширования аватаров Gravatar. Затем обновите все остальные плагины и темы: кампания живёт за счёт неустановленных патчей, и любая «забытая» уязвимость из списка выше — открытая дверь.

Далее проведите ревизию сайта на индикаторы компрометации: просканируйте файловую систему на веб-шеллы по указанным маскам, проверьте логи веб-сервера на подозрительные POST-запросы к плагинам и обращения к вредоносной инфраструктуре, заблокируйте перечисленные IP-адреса и домен. Если признаки взлома найдены, недостаточно просто удалить шелл: обязательно смените все пароли и ключи (администраторов WordPress, базы данных, FTP/SSH, API-ключи), поскольку доступ уже мог быть перепродан. Для серверов конфигураций Nacos включите аутентификацию (nacos.core.auth.enabled=true).

Почему это важно

История WP-SHELLSTORM — наглядная иллюстрация того, как устроен современный «бизнес» на взломанных сайтах. Атакующим не нужны сложные 0-day: им достаточно того, что миллионы сайтов месяцами не обновляют плагины. Один включённый «для удобства» переключатель в настройках кэша — и сайт превращается в товар на чёрном рынке. Регулярные обновления, принцип минимальных прав и периодическая проверка на индикаторы компрометации перестают быть «best practice для галочки» и становятся реальной линией обороны. А для разработчиков плагинов это ещё одно напоминание: любую загрузку файла по URL нужно строго валидировать по типу и содержимому, а не по расширению.