WP2Shell — критическая уязвимость в ядре WordPress (CVE-2026-63030)

В середине июля 2026 года в ядре WordPress нашли критическую дыру, которую быстро окрестили wp2shell. Это не плагин и не тема — баг в самом WordPress. Анонимный злоумышленник без логина и пароля мог через REST API добраться до SQL-инъекции, создать в базе нового администратора, зайти в админку и загрузить вредоносный плагин с PHP-шеллом. Звучит как страшилка, но цепочку уже эксплуатировали в дикой природе — массовые POST-запросы на /wp-json/batch/v1 пошли буквально на следующий день после disclosure.

Если вы пропустили новость или думаете «автообновление само всё поставило» — всё равно стоит проверить версию и пользователей. Патч вышел 17 июля в 6.9.5 и 7.0.2 (для ветки 6.8.x — 6.8.6, там закрыли только SQLi-компонент). WordPress даже включил принудительное автообновление — но на VPS, мультисайтах и «забытых» лендингах дыра нередко висит до сих пор.

Это не XSS2Shell

Чтобы не путаться: в начале августа вышел отдельный баг XSS2Shell (CVE-2026-64638) — reflected XSS на wp-login.php, патч в 7.0.3. Там другой вход и нужен залогиненный админ, которого уводят на фишинговую страницу. А wp2shell — полностью без авторизации, через batch-endpoint. В статьях и Medium их часто мешают в одну кучу, хотя это две разные истории. Ниже — про wp2shell.

В чём суть: две дыры в одной цепочке

CVE-2026-63030 — путаница маршрутов в batch-обработчике REST API (WP_REST_Server::serve_batch_request_v1). Batch-endpoint (/wp-json/batch/v1, а без ЧПУ — /?rest_route=/batch/v1) позволяет отправить несколько подзапросов одним POST. Если первый подзапрос падает с ошибкой при разборе URL, WordPress кладёт ошибку в один массив, но не синхронизирует второй. Индексы съезжают — и следующий подзапрос атакующего обрабатывается с чужими правами, мимо проверки «можно ли это без логина».

CVE-2026-60137 — SQL-инъекция в параметре author__not_in (в REST он приходит как author_exclude). Сама по себе она за auth-блоком. Но batch-баг протаскивает туда анонимный запрос. Инъекция слепая — в ответе данных нет, зато работает time-based oracle через SLEEP().

Одна без другой до полного RCE на типичном сайте не доводит. Вместе — критическая цепочка с CVSS 9.8.

Как выглядит атака: левый админ → плагин → шелл

Упрощённо, как описывают исследователи (Searchlight Cyber, публичные PoC вроде wp2shell на GitHub) и что видно в логах реальных инцидентов:

1. Анонимный POST на /wp-json/batch/v1 с «кривым» batch-envelope — срабатывает route confusion.
2. В том же batch — запрос с poisoned author_exclude, SQLi читает/меняет данные в БД (часто через blind SQLi и манипуляции с object cache / changeset — детали в PoC различаются).
3. Через REST создаётся новый пользователь с ролью administrator — логин обычно вида wp2_*, email иногда на подставных доменах вроде @wordpress-svc.internal. Brute bcrypt-хеша существующего админа для этого не нужен — аккаунт поднимают «с нуля».
4. Атакующий логинится под этой учёткой (в логах потом видны нормальные запросы в wp-admin с валидным nonce).
5. Через Загрузку плагина (update.php?action=upload-plugin) заливается ZIP с PHP — имена в инцидентах разные: media-optimization-core-*, sgio-wp2shell-* и т.п. Активировать плагин в списке не обязательно — PHP в wp-content/plugins/ часто доступен по URL напрямую.
6. Дальше — id, uname, выкачка wp-config.php, спам-рассылки, бэкдоры в mu-plugins, cron, переименование Wordfence.

Именно этот сценарий — «создали админа, зашли, залили шелл через плагины» — описан в публичных разборах wp2shell, в том числе на Medium. Не социнженерия и не «админ кликнул фишинг».

Кого касается

Полная цепочка до RCE:

• WordPress 6.9.0 – 6.9.4
• WordPress 7.0.0 – 7.0.1

Только SQLi (без batch-RCE, но всё равно надо патчить): 6.8.0 – 6.8.5 → фикс в 6.8.6.

Версии ниже 6.8 batch-механизм в том виде, в каком его эксплуатируют, не затрагивают — но это не повод радоваться, если у вас вообще древний WP.

Нюанс из advisory: полный RCE-chain на практике чаще срабатывает, когда нет внешнего persistent object cache (Redis/Memcached). На обычном shared-хостинге это как раз большинство сайтов.

Как понять, что уже взломали

Картина похожа на массовые взломы через Elementor или Битрикс — только вход другой.

• Незнакомые администраторы в «Пользователи» — логины wp2_*, wpsvc_*, странные email.
• Новые папки в wp-content/plugins/ с «оптимизационными» или «сервисными» названиями и свежей датой.
• В access-логах — массовые POST на batch/v1, ответы 207 Multi-Status, User-Agent вроде wp2shell-rce/1.0.
• После входа «левого» админа — запросы на upload-plugin, активация плагинов, дефейс главной.
• Пersistence: cron у пользователя веб-сервера, записи в wp_options, must-use plugins в wp-content/mu-plugins/.

Из разбора реального инцидента (deface «Hacked by CoupDeGrace»): сайт обновили до 7.0.2, но бэкдоры продолжали работать — патч закрывает вход, но не чистит сервер. Как с Битриксом: обновили CMS, а webshell из прошлого взлома остался.

Что делать

1. Обновить ядро. Единственный нормальный способ, как разработчики и задумывали: 6.9.5, 7.0.2 или новее (на сегодня логично сразу до актуального security-release — 7.0.4 и аналогов в своей ветке). Анонс: WordPress 7.0.2 Security Release. Advisory: GHSA batch-route confusion и GHSA SQL injection.

2. Убедиться, что автообновление реально сработало. Зайдите в Консоль → Обновления и посмотрите версию. «Должно было само» ≠ «обновилось».

3. Проверить пользователей. Удалите всех незнакомых админов. Смените пароли нормальным администраторам, отзовите Application Passwords.

4. Пройтись по файлам. plugins/, mu-plugins/, uploads/, лишние .php в корне. Сравните с чистым архивом той же версии WP, если есть сомнения в целостности ядра.

5. Посмотреть логи. POST на batch/v1 с июля 2026 — повод считать сайт скомпрометированным, даже если визуально всё чисто.

6. Временная мера, если обновиться прямо сейчас нельзя: заблокировать на WAF/nginx /wp-json/batch/v1 и ?rest_route=/batch/v1 для анонимов. Как временный запрет POST на отдельные файлы у Битрикса — не 100%, но лучше, чем ничего.

Важно: если взлом подтвердился — сначала чистка и ротация секретов (БД, FTP, SMTP), потом спокойное обновление. Восстановление из бэкапа только если копия точно старше первого POST на batch и гарантированно чистая.

UPD — август: XSS2Shell и Imagick RCE

После wp2shell WordPress выпустил ещё security-релизы:

• 7.0.3 (6 августа) — XSS2Shell, CVE-2026-64638, XSS на экране входа с цепочкой через Application Password (другой сценарий, нужен фишинг админа).
• 7.0.4 (12 августа) — CVE-2026-65640, RCE через загрузку Postscript при Imagick + Ghostscript, нужен пользователь с upload_files.

Если вы на 7.0.2 после wp2shell — докатите до актуального патча своей ветки. Это уже не wp2shell, но дыры тоже серьёзные.

Нужна помощь — проверить версию, найти левых админов и шеллы, обновить WordPress под ключ — пишите через контакты на сайте.

Другие статьи по теме:

• Критическая уязвимость в Elementor Pro – популярном плагине WordPress
• Contact Form 7 – удаляем значок Google reCaptcha со страниц сайта.
• Массовый взлом сайтов на Битрикс 2023