Критические уязвимости WordPress уже ушли из категории «срочно обновить» в категорию «вас, возможно, уже проверили на прочность». Речь о связке CVE-2026-63030 и CVE-2026-60137, которую исследователи называют wp2shell: она позволяет удаленно выполнить код без авторизации, а на практике злоумышленники ставят на серверы вебшеллы, вредоносные плагины и иногда даже создают новые админские учетные записи. Для русскоязычной IT-аудитории вывод простой: если WordPress у вас где-то живет «как маркетинговый сайтик на поддомене», это уже не мелочь, а полноценная точка входа.
О начале активной эксплуатации сообщает BleepingComputer. По данным издания, атаки пошли почти сразу после того, как компания SearchLight Cyber раскрыла проблему, а WordPress выпустил исправления в версиях 7.0.2, 6.9.5 и 6.8.6 и принудительно запустил автоматические security-обновления для поддерживаемых установок. Это важная деталь: когда проект такого масштаба не просто публикует патч, а форсирует автообновление, значит, ситуация уже вышла за пределы теоретической угрозы.
Технически цепочка атак использует механизм пакетной обработки в WordPress REST API. Полных деталей эксплойта публично не раскрывали, но proof-of-concept-эксплойты, по данным публикации, появились уже в выходные. Типичный сценарий выглядит неприятно знакомо: злоумышленник сначала находит уязвимую инсталляцию, затем получает возможность загрузить вредоносный плагин или разместить PHP-вебшелл, после чего закрепляется на сервере. То есть проблема не только в единичном выполнении команды, а в том, что компрометация быстро превращается в постоянное присутствие внутри сайта.
Как именно атакуют
Cloud security-компания Wiz описала, что именно наблюдает в реальных атаках. Во-первых, идет массовое сканирование WordPress-сайтов на предмет уязвимости; часть этого трафика, вероятно, исследовательская, но не весь. Во-вторых, атакующие злоупотребляют функцией загрузки плагинов, чтобы установить вредоносные дополнения. В-третьих, на взломанных хостах появляются PHP-вебшеллы: от примитивных однострочников до более тяжелых, замаскированных и обфусцированных вариантов, которые прикидываются плагинами. Параллельно злоумышленники обращаются к REST API, чтобы собрать имена пользователей-администраторов и их e-mail, а еще пытаются через local file inclusion добраться до wp-config через admin-ajax.php и вытащить учетные данные к базе и ключи аутентификации.
На этом набор не заканчивается. Wiz также зафиксировала установку вредоносного плагина, который открывает REST API-эндпоинт для удаленного выполнения команд, и успешные входы в административные панели WordPress. При этом компания отдельно оговаривает, что пока не видела латерального перемещения или эксфильтрации данных. Для владельца сайта это не повод выдыхать, а скорее плохой промежуточный статус: если на сервер уже поставили устойчивый бэкдор, кража данных может быть следующим этапом, а может и не потребоваться вовсе, если задача кампании — массовое закрепление и продажа доступа.
Отдельный отчет представил Йоханнес Б. Ульрих, Dean of Research в SANS Technology Institute. Он описал двухэтапные атаки, где сначала выполняется SQLi-проба для подтверждения уязвимости, а затем на сервер сбрасывается PHP-вебшелл. По его данным, шелл создавался в каталоге /wp-content/cache/ под случайным именем файла; это же имя использовалось как пароль, который передавался через переменную в URL-запросе. Если пароль не совпадал, страница показывала поддельный 404-ответ. Сам код вебшелла проверял доступность функций system(), passthru(), exec(), shell_exec(), popen() и даже backtick-оператора, то есть пытался найти любой рабочий путь до исполнения команд на сервере. Ульрих также пишет, что часть атак сопровождается созданием поддельных администраторских аккаунтов.
Почему это важно не только администраторам сайтов
Эта история касается не только людей, у которых в job title написано «WordPress-разработчик». В реальной инфраструктуре WordPress часто живет рядом с основным бизнесом: как карьерный раздел, блог компании, лендинг продукта, партнерский портал или сайт дочернего бренда. Формально это «не прод», а фактически тот же внешний периметр с доступом к корпоративным доменам, CRM-интеграциям, почтовым адресам администраторов, а иногда и общему хостингу. Если атакующий получает устойчивый доступ туда, дальше уже начинается скучная, но эффективная работа по расширению возможностей.
Хронология тоже показательна. WordPress-фирма Defiant сообщила, что первое зондирование, связанное с эксплуатацией, было замечено 17 июля в 23:29 UTC, а уже через 13 минут последовала явная попытка SQL-инъекции. Это хороший маркер скорости современного offensive-цикла: окно между публичным раскрытием и реальной эксплуатацией теперь измеряется не неделями, а часами, иногда минутами. И да, в 2026 году фраза «поставим патч после согласования в следующем спринте» звучит как приглашение в инцидент-канал.
Пока картина смешанная. Исследователь Yutaka Sejiyama из Macnica запустил дашборд для отслеживания темпов установки патчей, и на момент публикации там фигурировала цифра 81,6% обновленных сайтов в выборке из 124 580 ресурсов. С одной стороны, показатель высокий: экосистема WordPress умеет быстро реагировать, особенно когда включаются автоматические security-обновления. С другой, оставшиеся примерно 18% в абсолютных числах — это все еще очень большой резервуар для массовой эксплуатации. Для атакующих такой хвост особенно удобен: он долго не иссякает и обычно состоит из запущенных или плохо администрируемых инсталляций.
Практический список действий здесь предельно приземленный. Администраторам нужно не просто обновиться до исправленных версий, а проверить логи на запросы, связанные с wp2shell, просмотреть установленные плагины, поискать неожиданные PHP-файлы и отдельно изучить каталог /cache/. Не менее важно проверить, не появились ли новые админские пользователи, которых никто из команды не создавал. Для продуктовых и IT-руководителей урок еще шире: внешние CMS-площадки больше нельзя считать второстепенной витриной. Это такой же актив, как API-шлюз или VPN-концентратор, только обычно с худшей дисциплиной обновлений.
В этой истории есть и более неприятный долгий вывод. SearchLight Cyber отдельно выпустила разбор того, как была найдена цепочка wp2shell и как исследователи строили рабочий эксплойт, используя AI-инструменты. Для защитников это означает ускорение исследований и проверки гипотез. Для атакующих, очевидно, тоже. Поэтому главный вопрос уже не в том, сколько еще проживет конкретная связка уязвимостей WordPress, а в том, как быстро индустрия привыкнет к реальности, где путь от находки в коде до эксплуатационного артефакта становится короче с каждым кварталом.