
Детектор PoC и безопасный валидатор для цепочки уязвимостей WP2Shell WordPress: CVE-2026-63030 (путаница пакетных маршрутов REST) + CVE-2026-60137 (SQL-инъекция author__not_in). Только для авторизованного тестирования безопасности.
Охват CVE: CVE-2026-63030 и CVE-2026-60137 Назначение: Только авторизованное тестирование безопасности, защитная валидация и одноразовые локальные лаборатории
WP2Shell — это цепочка уязвимостей ядра WordPress, объединяющая баг путаницы пакетных маршрутов REST API до аутентификации (CVE-2026-63030) с примитивом SQL-инъекции author__not_in в WP_Query (CVE-2026-60137). Этот репозиторий предоставляет Python-сканер доказательства концепции и безопасный валидатор, чтобы защитники могли идентифицировать затронутые установки WordPress, подтвердить уязвимое поведение в изолированной лаборатории и проверить исправление — без необходимости извлечения данных или достижения выполнения кода.
Этот проект идентифицирует установки WordPress и проверяет два примитива уязвимости, связанных с цепочкой уязвимостей ядра WordPress WP2Shell:
WP_Query::author__not_in, что может привести к SQL-инъекции, когда подконтрольные злоумышленнику данные достигают параметра.Когда оба условия присутствуют, неаутентифицированный запрос может достичь уязвимой SQL-конструкции через конечную точку пакетного REST API WordPress. Публичные уведомления описывают совокупное воздействие как потенциально ведущее к удаленному выполнению кода.
Этот репозиторий следует использовать только на системах, которыми вы владеете или на тестирование которых у вас есть явное разрешение. Предпочтительнее использовать изолированную лабораторию Docker или виртуальной машины, привязанную к 127.0.0.1.
Текущий исходный файл содержит функциональность, изменяющую состояние, включая попытки извлечения данных из базы данных, попытки записи в файлы, рабочие процессы аутентификации, создание администратора, загрузку плагинов и выполнение команд.
Затронутые релизы WordPress могут терять согласованность между внутренними массивами, используемыми для отслеживания:
Когда искаженный элемент пакета принимается в один внутренний массив, но не в другой, последующие запросы могут быть связаны с неправильным обработчиком. Таким образом, запрос может быть проверен как один маршрут, но выполнен с использованием функции обратного вызова другого маршрута.
Влияние на безопасность:
author__not_inЗатронутая реализация WP_Query не всегда нормализует author__not_in перед использованием для построения SQL-условия NOT IN (...).
Параметр обычно ожидает список целочисленных идентификаторов авторов. Если скалярная строка попадает в уязвимую конструкцию запроса без предусмотренной проверки схемы REST, небезопасная SQL-структура может сохраниться в запросе к базе данных.
Влияние на безопасность:
| Ветвь WordPress | Затронуты | Исправленный релиз |
|---|---|---|
| 6.8.x | CVE-2026-60137 only: 6.8.0–6.8.5 | 6.8.6 |
| 6.9.x | Обе проблемы: 6.9.0–6.9.4 | 6.9.5 |
| 7.0.x | Обе проблемы: 7.0.0–7.0.1 | 7.0.2 |
| 7.1 prerelease | Бета 1 затронута | Бета 2 |
| Ранее 6.8 | Не затронуты этими двумя CVE | N/A |
WordPress выпустила исправления 17 июля 2026 года и включила принудительные автоматические обновления для затронутых установок из-за серьезности.
Unauthenticated client | v WordPress REST batch endpoint | v Malformed batch member creates request/handler misalignment | v Later request is validated against one route but dispatched using another route's handler | v Scalar author_exclude reaches WP_Query as author__not_in | v Unsafe value reaches SQL NOT IN (...) construction | v Blind SQL timing or Boolean oracle | v Potential database compromise | v Potential application-level compromise and RCE
Детектор должен остановиться после подтверждения примитивов route-confusion и SQL-инъекции. Ему не нужно извлекать данные или выполнять команды, чтобы установить, что скомпрометированная установка уязвима.
---
## Процесс обнаружения
### Этап 1 — Нормализация цели
Инструмент:
1. Добавляет схему по умолчанию `http` или `https`, если она отсутствует.
2. Нормализует путь установки WordPress.
3. Отклоняет неподдерживаемые схемы URL и встроенные учётные данные.
4. Применяет политики перенаправлений, прокси, TLS и тайм-аутов.
### Этап 2 — Идентификация WordPress
Сканер проверяет:
- ссылки на `wp-content/`;
- ссылки на `wp-includes/`;
- метаданные генератора WordPress;
- ссылки обнаружения REST API;
- структуру индекса WordPress REST;
- пространство имён `wp/v2`;
- необязательные фид и `readme.html`.
### Этап 3 — Определение версии
Доказательства версии могут поступать из:
- метаданных HTML-генератора;
- метаданных фид-генератора;
- строк запроса основных ресурсов WordPress;
- HTTP-заголовков генератора;
- `readme.html`;
- локального файла `wp-includes/version.php`.
Доказательства оцениваются и сопоставляются. Противоречивые удалённые индикаторы версии снижают достоверность.
### Этап 4 — Проверка доступности пакетного маршрута
Сканер пытается обнаружить `/batch/v1` через:```text
/?rest_route=/
/wp-json/
Маршрут можно указать, используя:```text /?rest_route=/batch/v1 /wp-json/batch/v1
### Фаза 5 — Безопасный зонд на путаницу маршрутов
Безопасный зонд содержит:
1. Намеренно искажённый внутренний путь.
2. Запрос к недействительному ID поста с безвредным вложенным публичным `GET`.
3. Последующий запрос `/batch/v1`.
Уязвимый сервер возвращает внешний ответ `207 Multi-Status`, в котором запрос к недействительному посту обрабатывается как вложенный пакетный запрос.
Детектор сообщает:```text
route-confusion-observed
when it sees:
parse_path_failed.207.responses, показывающий, что безвредный внутренний запрос выполнен.Нерарушающий валидатор SQLi должен отправлять парные запросы, отличающиеся только константным булевым условием:```text False control -> no deliberate database delay True test -> deliberate database delay
Валидатор должен: