17 июля 2026 WordPress выпустил экстренные патчи: 6.9.5, 7.0.2 и бэкпорт 6.8.6. Причина: цепочка из двух дыр в ядре, которую назвали wp2shell. На обычной установке без плагинов она даёт удалённое выполнение кода без авторизации.
Patchstack, Hexastrike и WatchTowr уже фиксируют реальные атаки. WordPress.org включил принудительные автообновления для уязвимых версий. Это не «теоретический баг из changelog», а рабочая история, которую нужно закрывать сразу.
Что это за баг
Это не дыра в плагине. Это ядро.
Две уязвимости работают вместе:
- CVE-2026-63030: путаница маршрутов в REST API batch-эндпоинте
/wp-json/batch/v1(или/?rest_route=/batch/v1). Из-за неё запрос может попасть не туда, куда его проверяли. - CVE-2026-60137: SQL-инъекция в параметре
author__not_inуWP_Query. Сама по себе она требует авторизации или помощи плагина. Вместе с первой дырой ограничение обходится.
В итоге анонимный запрос через batch-эндпоинт может привести к созданию администратора и дальнейшему выполнению кода. Плагины и темы для этого не нужны.
Кого касается
Полная цепочка (неавторизованный RCE) работает на:
- WordPress 6.9.0 – 6.9.4
- WordPress 7.0.0 – 7.0.1
SQL-инъекция (CVE-2026-60137) затрагивает ещё и ветку 6.8.x до 6.8.6. На версиях старше 6.8 этой конкретной цепочки нет.
Исправлено в:
- 6.8.6
- 6.9.5
- 7.0.2
Что делать прямо сейчас
Сначала узнайте точную версию.
wp core version
Или посмотрите в админке: Консоль → Обновления.
Если версия из списка уязвимых, обновляйтесь сразу:
- 6.9.x → 6.9.5
- 7.0.x → 7.0.2
- 6.8.x → 6.8.6
Через WP-CLI:
wp core update wp core update-db
После обновления ещё раз проверьте версию. На этом этапе важна не «галочка в обновлениях», а фактический номер ядра.
Принудительные автообновления
WordPress.org включил forced updates для затронутых версий. На многих сайтах обновление уже прошло само, даже если автообновления ядра были отключены.
На автоматику лучше не полагаться. Особенно на сайтах с кастомными ограничениями, staging-окружениями или отключённым wp-cron. Проверьте руками, что версия действительно стала 6.9.5 / 7.0.2 / 6.8.6.
Что смотреть в логах
Ищите обращения к batch-эндпоинту:
grep -E "batch/v1|rest_route=/batch" /var/log/nginx/access.log # или grep -E "batch/v1|rest_route=/batch" /var/log/apache2/access.log
Обратите внимание на ответы 207 Multi-Status: они часто встречаются при успешной работе batch-запросов. Также смотрите на появление новых администраторов, неизвестных плагинов и подозрительных файлов в wp-content.
Если сайт долго стоял на уязвимой версии после 17 июля, имеет смысл дополнительно проверить:
- список пользователей с ролью administrator;
- активные плагины и темы на предмет неизвестных;
- изменённые файлы ядра через
wp core verify-checksums.
wp core verify-checksums wp user list --role=administrator
Короткий вывод
Дыра в ядре, работает без плагинов, атаки уже идут. Патчи вышли 17 июля. Принудительные обновления помогают, но не заменяют ручную проверку.
Проверьте версию, обновитесь, посмотрите логи на /wp-json/batch/v1. На этом этапе большинство сайтов закрывается. Если сайт долго был уязвим, не ограничивайтесь только update: проверьте пользователей, checksums и странные плагины.
