Публичные эксплойты для цепочки уязвимости WordPress под названием wp2shell уже опубликованы, а первые признаки атак в реальной среде уже заметили исследователи. Для администраторов, агентств и продуктовых команд это не абстрактная история про CVE в блоге вендора: под ударом WordPress 6.9.x и 7.0.x, а эксплуатация в части сценариев заявлена как pre-auth RCE, то есть без логина, пароля и лишних церемоний.
Речь идет о двух уязвимостях, которые можно связать в одну цепочку удаленного выполнения кода, сообщает BleepingComputer. Первая, CVE-2026-63030, связана с путаницей маршрутов в batch-механизме REST API и появилась в WordPress 6.9. Вторая, CVE-2026-60137, это SQL-инъекция в параметре author__not_in внутри WP_Query. По отдельности это уже неприятный набор, а вместе они превращаются в сценарий, после которого чужой PHP-код на сервере перестает быть теорией.
Что именно сломалось
По данным Searchlight Cyber, связка работает против стандартной установки WordPress без плагинов и дополнительных условий. Это, пожалуй, самая тревожная часть истории: обычно индустрия любит успокаивать себя формулировками вроде «эксплуатация возможна только при редкой конфигурации» или «нужна специфическая цепочка с устаревшим расширением». Здесь такого утешения нет. Исследователи прямо говорят о возможности атаки анонимным пользователем на «стоковый» WordPress.
Полная цепочка wp2shell затрагивает версии WordPress 6.9.0-6.9.4 и 7.0.0-7.0.1. Исправления выпущены в WordPress 6.9.5 и 7.0.2. Отдельно SQL-инъекция CVE-2026-60137 задевает и ветку 6.8.0-6.8.5, но там нельзя дотянуться до RCE через эту же цепочку: уязвимый batch-route в REST API появился только начиная с 6.9. Это важная деталь для тех, кто сейчас судорожно инвентаризирует парк сайтов и пытается понять, где просто плохо, а где совсем плохо.
Из-за серьезности проблемы команда безопасности WordPress включила принудительные автоматические обновления для поддерживаемых установок на уязвимых версиях. Сам по себе этот шаг показателен. В WordPress не каждый день включают режим, при котором платформа фактически говорит владельцам сайтов: «мы не будем долго спорить, просто обновляйтесь». Для экосистемы, где совместимость, старые темы и самописные плагины часто превращают каждый минорный релиз в маленькую миграцию, это почти аварийная сирена.
Масштаб потенциального эффекта тоже понятен без особой драматургии. Searchlight Cyber оценивает аудиторию WordPress более чем в 500 миллионов сайтов. Понятно, что не все они сидят на уязвимых ветках, и не каждый ресурс одинаково интересен злоумышленникам. Но при такой базе даже скромный процент неуспевших обновиться превращается в очень заметный рынок целей: интернет-магазины, лендинги с формами заявок, корпоративные блоги, базы пользователей, панели администрирования, связанные с CRM и платежками.
Почему ситуация быстро перешла в практическую плоскость
Searchlight Cyber пока не публикует технические детали полной цепочки и вместо этого запустила сайт для проверки уязвимости инсталляций. Логика понятна: дать администраторам время на патчинг, а не раздавать готовую инструкцию всем желающим. Проблема в том, что окно уже почти закрылось. На GitHub появились публичные proof-of-concept-эксплойты. Часть из них идет обходным путем: через SQL-инъекцию вытаскивает хэши паролей WordPress, затем предполагает взлом пароля администратора, вход в панель, загрузку вредоносного плагина и выполнение команд. Но есть и PoC, авторы которых заявляют именно pre-auth RCE без административных учетных данных. То есть ближе к тому сценарию, который описывает Searchlight Cyber.
Параллельно security-компания watchTowr заявила, что уже видит признаки эксплуатации в реальных атаках после публикации PoC. Это, вероятно, главный маркер для рынка. Пока уязвимость живет только в advisories и приватных обсуждениях, часть бизнеса привычно откладывает обновление на окно обслуживания или на «после согласования». Как только появляются публичные эксплойты и первые инциденты в дикой природе, дискуссия заканчивается. Дальше уже вопрос не в том, случится ли сканирование интернета под эту цепочку, а в том, насколько быстро оно доберется до конкретного сайта.
Для команд, которые не могут обновиться немедленно, Searchlight Cyber предлагает временные меры: либо полностью блокировать анонимный доступ к REST API, либо резать на уровне WAF запросы к /wp-json/batch/v1 и ?rest_route=/batch/v1. Cloudflare, со своей стороны, уже включила WAF-защиту для обеих уязвимостей на всех тарифах, включая бесплатный, если трафик идет через ее прокси. Это полезный буфер, но не лекарство. Cloudflare прямо подчеркивает ту мысль, которую администраторы и так знают, но иногда удобно забывают: WAF снижает риск, а не заменяет обновление ядра.
Для русскоязычной IT-аудитории из этого следует очень прикладной вывод. Если у вас агентство на WordPress, продуктовый контент-хаб, маркетинговые сайты или витрина, привязанная к CRM и аналитике, то инцидент уже должен быть не в ленте новостей, а в чек-листе дежурной команды. Нужна инвентаризация версий, проверка автопатчей, аудит публичных узлов, разбор WAF-правил и журналов доступа. Особенно если WordPress в компании формально «не критичный актив», а по факту через него проходят лиды, заявки, cookie, формы обратной связи и админские учетки с повторно используемыми паролями. Такие системы часто считаются второстепенными ровно до первого компрометационного письма от хостера.
История с wp2shell неприятна не только из-за самих уязвимости WordPress, но и потому, что бьет по старой управленческой иллюзии: будто ядро WordPress само по себе предсказуемо, а основная головная боль живет только в плагинах и темах. На этот раз проблема в Core, публичные эксплойты уже гуляют, а окно между публикацией исправления и началом реальных атак снова оказалось коротким. Для рынка это еще одно напоминание: патч-менеджмент для массовых CMS давно надо считать не задачей веб-мастера на полставки, а нормальной частью инфраструктурной безопасности. Подробности инцидента собраны в материале .