wp2shell-scan

Обнаружение и устранение компрометации wp2shell (CVE‑2026‑63030) на одном или множестве сайтов WordPress.

wp2shell — это уязвимость удалённого выполнения кода без аутентификации, исправленная в WordPress 7.0.2 / 6.9.5 / 6.8.6 (2026‑07‑17). Публичный PoC появился в течение суток, а массовая эксплуатация началась примерно через 48 часов. Установка патча закрывает дыру — но сайт, эксплуатированный до установки патча, уже скомпрометирован, и обновление не удаляет закрепление злоумышленника.

Этот инструмент находит и удаляет такое закрепление. Это единый Bash-скрипт с минимумом зависимостей, который по умолчанию работает в режиме только чтения и способен сканировать тысячи сайтов за один проход.

⚠️ Это защитный инструмент. Он не содержит кода эксплойта. Сделайте снимок сайта перед запуском --clean.

Что он обнаруживает

После эксплуатации инструменты wp2shell обычно оставляют два артефакта закрепления, и этот инструмент находит оба:

1. Сторонний администратор — встречались несколько вариантов: user_login = wpsvc_<hex> / wp2_<hex> / w2s_<hex>, либо email на домене злоумышленника (@wp2shell.*, @shellcode.*, @wordpress-svc.internal, @wordpress-noreply.net, @x.lol), с ролью administrator. (Примечание: @system.local — это легитимный placeholder-email администратора на некоторых управляемых хостингах — он намеренно не считается IOC.)
2. Веб-шелл, замаскированный под плагин — wp-content/plugins/<plausible-name>-<6hex>/<same>.php: крошечный (~1.3 KB) PHP-файл с поддельным заголовком Author: WordPress.org Community, защищённый токеном и предоставляющий интерфейс ?c=<command>.

Он также обнаруживает общий случай: любой небольшой PHP-файл в wp-content/, который передаёт $_GET['c'] в командный/eval-сток.

Установка

curl -fsSLO https://raw.githubusercontent.com/InstaWP/wp2shell-scan/main/wp2shell-scan.sh
chmod +x wp2shell-scan.sh

Требуются bash, find, grep и клиент mysql/mariadb. WP‑CLI используется при наличии (более чистое удаление пользователей), но не обязателен — для обнаружения веб-шеллов база данных вообще не нужна.

Использование

# Scan ONE site (read-only)
./wp2shell-scan.sh --path /var/www/example.com

# Scan EVERY WordPress install under a base directory (bulk)
./wp2shell-scan.sh --base /var/www
./wp2shell-scan.sh --base /home            # shared hosting

# Auto-detect common layouts (/var/www/*, /home/*/public_html, ...)
./wp2shell-scan.sh

# Machine-readable
./wp2shell-scan.sh --base /var/www --json > report.json

# CLEAN — quarantine + remove backdoors, rotate wp-config salts (logs everyone out)
./wp2shell-scan.sh --base /var/www --clean --yes

# Vet a BACKUP / SNAPSHOT / TEMPLATE dump before restoring it (see warning below)
./wp2shell-scan.sh --sql /path/to/backup.sql

Удалённые артефакты перемещаются в карантинный каталог (а не удаляются безвозвратно), чтобы вы сохранили доказательства. Код выхода — 1, когда обнаружена компрометация (scan) или выполнена очистка (clean), 0, когда чисто — удобно для cron/CI.

Пример вывода

[COMPROMISED] /var/www/example.com  — 2 backdoor admin(s), 2 webshell(s)
      admin: ID=41 wpsvc_2e1487df8abb <[email protected]> (2026-07-19 06:41:48)
      webshell: .../wp-content/plugins/security-headers-manager-8d1d21/security-headers-manager-8d1d21.php
[clean] /var/www/other-site.com
----------------------------------------------------------------
scanned=812  clean=811  compromised=1  cleaned=0

⚠️ Не забывайте о резервных копиях, снимках и шаблонах

Очистка работающего сайта НЕ очищает ваши резервные копии. Резервная копия, снимок или шаблон staging/blueprint, созданный в момент, когда сайт был скомпрометирован, по-прежнему содержит учётную запись администратора злоумышленника — его восстановление (или развёртывание нового сайта на его основе) мгновенно приводит к повторному заражению. Мы убедились в этом на собственном горьком опыте: после очистки каждого затронутого работающего сайта продолжали появляться совершенно новые сайты с бэкдором, потому что они развёртывались из отравленного снимка шаблона.

Проверяйте дамп перед его восстановлением:

./wp2shell-scan.sh --sql /path/to/backup.sql
./wp2shell-scan.sh --sql backup1.sql --sql backup2.sql.gz   # repeatable, .gz supported

Код выхода — 1, если какой-либо дамп заражён. Если это так: не восстанавливайте его — сначала очистите рабочий сайт, затем сделайте свежую резервную копию и удалите/замените любой снимок или шаблон, созданный в течение окна компрометации.

После очистки

--clean удаляет администратора и веб-шелл и меняет соли. Вы всё ещё должны:

1. Обновить ядро WordPress до 7.0.2 / 6.9.5 / 6.8.6 (это и есть настоящее исправление).
2. Сбросить все пароли администраторов и переустановить/проверить ядро и плагины (wp core verify-checksums).
3. Сменить все секреты, к которым сайт имел доступ — пароль БД, API-ключи, учётные данные SMTP — считайте, что они утекли.
4. Изучите, что выполнял шелл — в логах доступа записаны значения команд ?c=.
5. Заблокируйте маршрут batch на вашем edge/origin, пока все сайты не пропатчены (/wp-json/batch/v1, ?rest_route=/batch/v1, включая %2f‑кодированные). Разместите блокировку на origin, если CDN может пропускать REST-путь.

Проверьте вручную (без инструмента)

Подозрительные администраторы:

SELECT u.ID,u.user_login,u.user_email,u.user_registered
FROM wp_users u JOIN wp_usermeta m ON u.ID=m.user_id
WHERE m.meta_key='wp_capabilities' AND m.meta_value LIKE '%administrator%'
ORDER BY u.user_registered DESC;

Плагины веб-оболочки:

find wp-content/plugins -maxdepth 1 -type d -regextype posix-extended -regex '.*-[0-9a-f]{6}$'
grep -rl "\$_GET\['c'\]" wp-content/plugins/

Предпочитаете AI-агента?

См. CLEANUP-WITH-CLAUDE.md — готовый к вставке промпт, который проводит Claude Code (или любого способного агента для программирования) через ту же процедуру обнаружения и очистки на одном сайте, с подтверждением человеком перед каждым деструктивным шагом.

Лицензия

MIT — см. LICENSE. Предоставляется как есть, без гарантий. Создано и проверено в боевых условиях во время реального инцидента командой InstaWP.