
wp2shell — PoC цепочки Pre-Auth RCE в ядре WordPress для CVE-2026-63030 и CVE-2026-60137
Если вы цените мою работу, вы можете поддержать проект через USDT (TRC20): TQBA72kakjCZLnJt8fJYcD7dyQCEpzNtVN
wp2shell — это исследовательский Proof-of-Concept, демонстрирующий цепочку уязвимостей до аутентификации в ядре WordPress, объединяющую:
WP_QueryЦепочка демонстрирует, как эти уязвимости можно объединить, чтобы перейти от неаутентифицированного запроса к REST API к SQL-инъекции, повышению привилегий, созданию учётной записи администратора и, в конечном итоге, к аутентифицированному удалённому выполнению кода.
[!WARNING]
Только авторизованные исследования безопасности
Этот проект предназначен для:
- Исследования уязвимостей
- Защитной валидации
- Авторизованного тестирования на проникновение
- Лабораторий безопасности
- CTF и образовательных сред
Тестируйте только те системы, которыми вы владеете или на оценку которых у вас есть явное письменное разрешение.
Не используйте этот проект против сторонней инфраструктуры без авторизации.
wp2shell — это единый инструмент исследования безопасности ядра WordPress,
предназначенный для изучения взаимодействия двух уязвимостей:```text
CVE-2026-63030
|
v
REST API Batch Route Confusion
|
v
Validation / Dispatch Confusion
|
v
CVE-2026-60137
|
v
WP_Query SQL Injection
|
v
Blind SQL Access
|
v
Application / Object-State Manipulation
|
v
Privilege Escalation
|
v
Administrator Account Creation
|
v
Authenticated Code Execution
The PoC реализован как исследовательский инструмент на Python и использует стандартную библиотеку Python без необходимости в сторонних пакетах Python.
---
# Цепочка уязвимостей
Проект объединяет две уязвимости ядра WordPress.```text
Unauthenticated Request
|
v
+----------------------+
| CVE-2026-63030 |
| REST Batch Route |
| Confusion |
+----------+-----------+
|
v
Validation Confusion
|
v
+----------------------+
| CVE-2026-60137 |
| WP_Query SQLi |
+----------+-----------+
|
v
Blind SQLi
|
v
Application-State Abuse
|
v
Privilege Escalation
|
v
Administrator Access
|
v
Authenticated RCE
```
Важным свойством безопасности является взаимодействие между двумя
уязвимостями, а не каждая из уязвимостей по отдельности.
---
# CVE-2026-63030
## Путаница маршрутов пакетного REST API
Первая уязвимость затрагивает обработку запросов через
конечную точку пакетной обработки REST API WordPress.
Реализация пакетной обработки хранит информацию о сопоставлении и проверке
запросов в параллельных структурах, индексируемых по позиции запроса.
Некорректный подзапрос может привести к рассинхронизации этих структур.
Это создаёт состояние диспетчеризации со смещением на единицу (off-by-one),
при котором более поздний запрос может
обрабатываться с использованием обработчика или контекста проверки,
связанного с другим запросом.
Концептуально:```text
Request A
|
+-- validation entry
+-- matching entry
|
v
Malformed request
|
+-- internal state becomes desynchronized
|
v
Request B
|
+-- unexpected handler / validation context
```
PoC выполняет поведенческие проверки, чтобы определить, действительно ли
путаница маршрутов достижима.
---
# CVE-2026-60137
## SQL-инъекция WP_Query
Вторая уязвимость затрагивает путь обработки SQL в `WP_Query`.
После установления примитива путаницы маршрутов управляемые атакующим
входные данные могут достичь уязвимого пути запроса.
PoC демонстрирует результирующую SQL-инъекцию с помощью слепого
дифференциального тестирования.
Исследовательский функционал включает:
* Подтверждение методом Boolean-blind
* Дополнительное подтверждение на основе времени
* Снятие отпечатка базы данных
* Извлечение поддерживаемых скалярных значений
* Исследование пользовательских данных WordPress
---
# Как работает цепочка
## 1. Путаница маршрутов REST Batch
Неаутентифицированный запрос достигает конечной точки WordPress REST Batch.
Некорректный подзапрос batch приводит к рассинхронизации внутреннего
состояния сопоставления и проверки запросов.
Последующий запрос вследствие этого может быть обработан с использованием
непредусмотренного контекста.
---
## 2. SQL-инъекция
Примитив путаницы маршрутов предоставляет путь, необходимый для второй
уязвимости.
Управляемое атакующим значение может достичь уязвимого пути обработки
`WP_Query`.
Это создаёт примитив слепой SQL-инъекции.
---
## 3. Слепое извлечение данных через SQL
SQL-инъекция может использоваться как канал извлечения данных методом
boolean-blind.
PoC содержит функционал для исследования информации о базе данных и
поддерживаемой информации о пользователях WordPress.
---
## 4. Манипуляция состоянием приложения
Цепочка использует управляемые базой данных результаты, чтобы влиять на
объекты приложения WordPress и последующую обработку.
Это предоставляет примитивы, необходимые для этапа повышения привилегий.
---
## 5. Эскалация через changeset
Цепочка использует обработку changeset в WordPress для установления
контекста выполнения администратора.
Сфабрикованный объект `customize_changeset` может участвовать в
последовательности повышения привилегий.
---
## 6. Повторный вход через хуки
Цепочка повторно входит в обработку запросов WordPress через жизненный
цикл запросов приложения.
Это позволяет последующей обработке API выполняться в контексте с
повышенными привилегиями.
---
## 7. Создание учётной записи администратора
Исследовательский PoC реализует этап создания администратора до
аутентификации.
Это ключевая причина, по которой Режим 3 полезен для проверки
безопасности: он демонстрирует эффект повышения привилегий, не переходя к
этапу веб-шелла/RCE.
---
## 8. Выполнение кода после аутентификации
Режим 4 расширяет исследовательскую цепочку за пределы создания
администратора, переходя к этапу выполнения кода после аутентификации.
Этот этап следует использовать только в изолированной лаборатории или при
явно разрешённой оценке безопасности.
---
# Затронутые версии
## Полная цепочка до аутентификации
| Версия WordPress | Статус |
| ----------------- | -------------- |
| 6.9.0 – 6.9.4 | **Уязвима** |
| 7.0.0 – 7.0.1 | **Уязвима** |
| 6.9.5 | **Исправлена** |
| 7.0.2+ | **Исправлена** |
PoC определяет `6.9.0–6.9.4` и `7.0.0–7.0.1` как задокументированные
уязвимые версии для полной цепочки.
## SQL-инъекция
Компонент SQL-инъекции имеет другую границу исправленных версий, чем
полная цепочка.
Исследовательская реализация определяет `6.8.6` как версию с исправлением
SQL-инъекции.
Полная неаутентифицированная цепочка дополнительно зависит от уязвимого
поведения REST Batch.
Всегда сверяйте затронутые и исправленные версии с соответствующим
официальным бюллетенем безопасности, прежде чем принимать решения для
production-среды.
---
# Предварительные условия
PoC фиксирует следующие условия для полной цепочки:
* REST API WordPress доступен
* Отсутствует объектный кэш Redis/Memcached
* Опубликована как минимум одна запись
Другие компоненты развёртывания могут влиять на воспроизводимость:
* Обратные прокси-серверы
* Межсетевые экраны веб-приложений
* Ограничения REST API
* Плагины безопасности
* Объектное кэширование
* Фильтрация HTTP
* Конфигурация хостинга
Установка WordPress, соответствующая диапазону версий, не означает
автоматически, что полная цепочка будет работать в любом окружении.
---
# Возможности
`wp2shell` предоставляет интерактивное меню со следующими
исследовательскими функциями:```text
[1] Fingerprint + confirm vulnerability (non-destructive)
[2] Blind SQL extraction (fingerprint / dump users)
[3] Pre-Auth Admin creation
[4] Full RCE chain → admin creation + webshell
[5] Facilitated sink SQLi (WordPress 6.8.x / custom)
[6] Threaded scan over URL list
[7] Transport settings (proxy, TLS, timeout, delay)
[8] Change target URL
[0] Quit
```
---
# Интерактивное меню
Главное меню предназначено для поддержки обоих сценариев:
* Тестирование одной авторизованной установки WordPress
* Тестирование авторизованного списка URL-адресов WordPress
Таким образом, рабочий процесс может использоваться как для отдельных исследовательских целей, так и для более крупных авторизованных наборов данных оценки.
---
# Рекомендуемый режим — Режим 3
## Почему режим 3?
Для исследования уязвимостей **режим 3 рекомендуется, когда
цель — продемонстрировать влияние на безопасность без развертывания
веб-шелла**.
Режим 3 — это:```text
Pre-Auth Admin Creation
```
PoC описывает этот этап следующим образом:```text
Unauthenticated UNION SQLi → new WordPress administrator
```
и явно отличает его от полной стадии webshell/RCE:```text
No password cracking.
No webshell.
Non-destructive admin only.
```
Это делает Mode 3 особенно полезным, когда вы хотите доказать, что
цепочка уязвимостей достигает компрометации на уровне администратора,
избегая дополнительного этапа выполнения кода.
---
# Mode 3 — Создание администратора без аутентификации
При выборе Mode 3 открывается:```text
────────────────────────────────────────────────────────────
CREATE ADMIN — Pre-Auth Admin RCE Chain
────────────────────────────────────────────────────────────
⚠ Unauthenticated UNION SQLi → new WordPress administrator.
⚠ No password cracking. No webshell. Non-destructive admin only.
```
Затем PoC запрашивает несколько параметров окружения и вывода.
## SQLite```text
→ Target uses SQLite? (WP-SQLite plugin) (y/N) [n]:
```
Установите это значение `y`, если авторизованная цель использует конфигурацию WordPress SQLite, поддерживаемую PoC.
Для обычных установок WordPress на MySQL/MariaDB по умолчанию используется:```text
n
```
## Проверка учетных данных
PoC может опционально проверить сгенерированные учетные данные, попытавшись выполнить аутентифицированный вход:```text
→ Verify the generated credentials by logging in? (Y/n) [y]:
```
По умолчанию:```text
y
```
Это полезно, когда вы хотите, чтобы результат включал подтверждение того, что
сгенерированные учётные данные администратора действительно проходят аутентификацию.
---
## Выходной файл
Режим 3 может сохранять результаты в локальный файл:```text
→ Output file (blank = skip, e.g. result.txt):
```
Например:```text
logs.txt
```
Оставление поля пустым пропускает вывод в файл.
Опция вывода полезна при проведении авторизованного исследования по
нескольким целям и необходимости сохранить результаты для последующего анализа.
---
## Confusion Carrier
PoC предоставляет два варианта носителя:```text
→ Confusion carrier variant (posts/categories) [posts]:
```
Доступные варианты:```text
posts
categories
```
По умолчанию:```text
posts
```
The `posts` variant is the primary documented path.
---
# Mode 1 — Fingerprint and Confirm
Mode 1 is:```text
[1] Fingerprint + confirm vulnerability (non-destructive)
```
Это самая безопасная отправная точка для валидации уязвимости.
Она направлена на определение того, проявляет ли цель поведенческие условия, связанные с цепочкой уязвимостей.
Этап проверки может включать:
* Фингерпринтинг WordPress
* Проверки конечных точек REST Batch
* Подтверждение route-confusion
* Подтверждение SQL-инъекции
* Дифференциальное тестирование boolean-blind
* Необязательное подтверждение на основе временных задержек
Используйте режим 1, когда цель в первую очередь:```text
"Is this target potentially vulnerable?"
```
а не демонстрируя воздействие администратора.
---
# Режим 2 — Слепое извлечение SQL
Режим 2 — это:```text
[2] Blind SQL extraction (fingerprint / dump users)
```
Этот режим демонстрирует примитив SQL-инъекции через слепое
извлечение.
Исследовательский функционал включает:
* Определение типа СУБД (fingerprinting)
* Версия базы данных
* Пользователь базы данных
* Имя базы данных
* Поддерживаемые скалярные SQL-выражения
* Информация о пользователях WordPress
Используйте этот режим только в авторизованной среде, поскольку он демонстрирует
влияние на доступ к данным, а не просто обнаруживает уязвимость.
---
# Режим 3 — Создание администратора без предварительной аутентификации
Режим 3 — это:```text
[3] Pre-Auth Admin creation
```
Этот режим демонстрирует влияние цепочки на повышение привилегий.
Важное различие заключается в следующем:```text
Mode 3
|
+-- Pre-authentication chain
+-- Administrator creation
+-- Optional login verification
+-- No password cracking
+-- No webshell
```
For security researchers who need to prove the vulnerability's
administrator-level impact without deploying a webshell, this is the
preferred mode.
---
# Mode 4 — Full RCE Chain
Mode 4 is:```text
[4] Full RCE chain → admin creation + webshell
```
Это расширяет цепочку за пределы создания администратора до аутентифицированного выполнения кода.
Концептуально:```text
Unauthenticated
↓
Route Confusion
↓
SQL Injection
↓
Privilege Escalation
↓
Administrator Creation
↓
Administrator Authentication
↓
Webshell
↓
Code Execution
```
Этот режим должен быть ограничен изолированными лабораториями и явно санкционированными тестами на проникновение.
Для обычной проверки уязвимостей предпочтительнее Режим 3, поскольку он демонстрирует границу воздействия на администратора без развертывания веб-шелла.
---
# Режим 5 — Facilitated Sink SQLi
Режим 5 — это:```text
[5] Facilitated sink SQLi (WordPress 6.8.x / custom)
```
Этот режим предназначен для исследований, связанных с примитивом SQL-инъекции вне полной цепочки предварительной аутентификации.
Он полезен исследователям, изучающим:
* среды WordPress 6.8.x
* пользовательские конфигурации
* примитив SQL-инъекции независимо
* воспроизведение уязвимости
* защитную валидацию
---
# Режим 6 — Многопоточное сканирование URL
Режим 6 — это:```text
[6] Threaded scan over URL list
```
Этот режим предназначен для авторизованных оценок, включающих несколько
целей WordPress.
Вместо ручного тестирования одного URL за раз инструмент может обрабатывать
список URL, используя рабочие потоки (worker threads).
Концептуально:```text
urls.txt
|
+-- URL 1
+-- URL 2
+-- URL 3
+-- URL 4
+-- ...
|
v
Threaded vulnerability checks
|
v
Results
```
Функция сканирования может использовать такие параметры, как:
* Количество рабочих потоков
* Задержка подтверждения
* Необязательное подтверждение версии
* Вывод JSON-отчёта
* Вариант носителя confusion
Используйте это только со списками URL, для которых у вас есть явное разрешение.
---
# Одиночная цель и список URL
`wp2shell` можно использовать двумя основными способами.
## Одиночная цель WordPress
Используйте одиночную цель при исследовании одной установки.
Типичные сценарии использования:
* Локальная лаборатория
* Промежуточное окружение
* Тест на проникновение, одобренный заказчиком
* Воспроизведение уязвимости
* Проверка CVE
Целью должен быть базовый URL WordPress.
---
## Список URL
Для нескольких авторизованных целей режим 6 может обрабатывать список URL.
Пример концептуального файла:```text
https://wordpress-lab-01.example
https://wordpress-lab-02.example
https://wordpress-lab-03.example
https://wordpress-lab-04.example
```
Многопоточный сканер затем может обработать список и записать результаты.
Реализация сканирования также поддерживает опцию вывода/отчёта для сохранения результатов.
---
# Руководство по выбору режима
| Цель | Рекомендуемый режим |
| -------------------------------------- | ------------------- |
| Проверить, уязвима ли цель | **Режим 1** |
| Продемонстрировать SQL-инъекцию | **Режим 2** |
| Продемонстрировать воздействие на уровне администратора | **Режим 3** |
| Продемонстрировать полную цепочку RCE | **Режим 4** |
| Исследовать SQLi-приёмник независимо | **Режим 5** |
| Протестировать авторизованный список URL | **Режим 6** |
| Настроить прокси/TLS/таймаут/задержку | **Режим 7** |
| Изменить текущую цель | **Режим 8** |
### Рекомендуемый исследовательский процесс
Для большинства оценок безопасности:```text
Mode 1
↓
Confirm vulnerability
↓
Mode 3
↓
Demonstrate administrator impact
```
Переходите к Режиму 4 только тогда, когда полная проверка выполнения кода явно
требуется и разрешена.
---
# Режим 7 — Настройки транспорта
Режим 7 — это:```text
[7] Transport settings (proxy, TLS, timeout, delay)
```
Этот раздел управляет поведением HTTP-транспорта, используемого инструментом.
Поддерживаемые исследовательские настройки включают:
* Конфигурация прокси
* Поведение TLS
* Таймаут запроса
* Задержка запроса
* Поведение подключения/повторов
Эти параметры полезны при тестировании установок WordPress, работающих за:
* Прокси
* TLS-конфигурациями
* Медленными соединениями
* Инфраструктурой с ограничением скорости
* Контролируемыми лабораторными средами
---
# Режим 8 — Изменение целевого URL
Режим 8 — это:```text
[8] Change target URL
```
Это позволяет изменить выбранную в данный момент цель без
перезапуска всего интерактивного рабочего процесса.
Это полезно при переходе между авторизованными лабораторными установками.
---
# Логика обнаружения
PoC использует поведенческие проверки вместо того, чтобы полагаться
исключительно на строку версии WordPress.
## Обнаружение REST Batch
Инструмент проверяет, доступна ли конечная точка REST Batch.
## Обнаружение путаницы маршрутов
Инструмент может использовать:
* Ответные маркеры
* Структурное поведение ответа
Структурный подход проверяет, обрабатывается ли запрос, предназначенный
для одной коллекции REST, как другая коллекция.
## Обнаружение SQL-инъекций
Инструмент может выполнять булевый слепой дифференциальный анализ.
В качестве дополнительного подтверждения может также использоваться канал на основе времени.
---
# Технологическая цепочка
Полную цепочку исследований можно кратко описать следующим образом:```text
1. REST API reachable
|
v
2. Batch route confusion
|
v
3. Validation / dispatch confusion
|
v
4. SQL injection reaches WP_Query
|
v
5. Blind SQL channel
|
v
6. Application-state manipulation
|
v
7. Changeset privilege escalation
|
v
8. Administrator context
|
v
9. Administrator account creation
|
v
10. Authenticated code execution
```
---
# Варианты маршрутизации
PoC поддерживает два варианта носителя путаницы:```text
posts
categories
```
По умолчанию:```text
posts
```
Вариант `posts` является основным документированным сквозным переносчиком.
Вариант `categories` предоставляет альтернативный путь путаницы маршрутов
для исследований.
---
# Поддержка SQLite
PoC содержит поддержку совместимости с SQLite для сред, использующих
конфигурацию WordPress с SQLite.
Режим 3 предоставляет эту опцию в виде:```text
Target uses SQLite? (WP-SQLite plugin)
```
По умолчанию:```text
n
```
Использование:```text
y
```
когда авторизованная цель использует поддерживаемую конфигурацию SQLite.
---
# Установка
PoC использует стандартную библиотеку Python.
Сторонние пакеты Python не требуются.
Требуемое окружение:```text
Python 3.x
```
Клонируйте репозиторий и запускайте исследовательский инструмент в изолированной или
явно авторизованной среде.
---
# Структура проекта
Рекомендуемая структура репозитория:```text
wp2shell/
│
├── wp2shell.py
├── README.md
├── LICENSE
└── screenshots/
```
Основная исследовательская реализация:```text
wp2shell.py
```
---
# Влияние на безопасность
Успешная цепочка эксплуатации может потенциально привести к:
* Неаутентифицированной SQL-инъекции
* Раскрытию информации из базы данных
* Раскрытию информации о пользователях WordPress
* Повышению привилегий
* Созданию учётной записи администратора
* Полному административному доступу к WordPress
* Аутентифицированному выполнению произвольного кода
* Потенциальной компрометации на уровне операционной системы в зависимости
от хостинг-среды
Таким образом, полная цепочка имеет значительно большее воздействие, чем
отдельные уязвимости, рассматриваемые независимо.
---
# Защитное обнаружение
Администраторам следует проверять подозрительную активность, связанную с:
* Пакетными конечными точками REST WordPress
* Аномальными вложенными пакетными запросами
* Некорректными путями пакетных запросов
* Подозрительными параметрами запроса
* Неожиданным созданием учётной записи администратора
* Неожиданной активностью `customize_changeset`
* Неожиданной установкой плагинов
* Неожиданными PHP-файлами
* Подозрительными модификациями плагинов
* Поведением, похожим на веб-шеллы
Проверка:
---```text
Web server logs
+
WordPress logs
+
Database audit logs
+
File integrity monitoring
```
особенно в период предполагаемой эксплуатации.
---
# Меры по смягчению последствий
Основной мерой является обновление WordPress до исправленной версии.
Затронутые установки также должны:
1. Проверить все учётные записи администраторов.
2. Удалить несанкционированные учётные записи администраторов.
3. Проверить недавно установленные или изменённые плагины.
4. Проверить журналы WordPress REST API.
5. Проверить журналы доступа веб-сервера.
6. Поискать неожиданные PHP-файлы.
7. Проверить каталоги плагинов на предмет несанкционированных изменений.
8. Сменить учётные данные при подозрении на компрометацию.
9. Проверить целостность базы данных.
10. Удалить механизмы закрепления.
11. Переустановить скомпрометированные компоненты WordPress из доверенных источников, когда
это уместно.
---
# Процесс ответственного исследования
Для обычной авторизованной оценки рекомендуется следующая последовательность:```text
START
|
v
┌─────────────────┐
│ MODE 1 │
│ Detect / Confirm│
└────────┬────────┘
|
Vulnerable?
/ \
No Yes
| |
STOP v
┌───────────────┐
│ MODE 3 │
│ Admin Impact │
└───────┬───────┘
|
Need full RCE?
/ \
No Yes
| |
STOP v
┌───────────────┐
│ MODE 4 │
│ Full RCE Lab │
└───────────────┘
```
Mode 3 generally is the preferred impact-demonstration point because it
establishes administrator-level compromise without deploying the
webshell stage.
---
# Research vs Production
This project is intended for controlled security research.
Do not treat the tool as a general-purpose Internet scanner.
For production environments:
* Obtain written authorization.
* Define the target scope.
* Define allowed actions.
* Prefer non-destructive verification.
* Stop after sufficient evidence has been collected.
* Preserve logs and evidence.
* Follow the applicable vulnerability disclosure process.
---
# Credits
Vulnerability research / discovery:
**Adam Kues**
Assetnote / Searchlight Cyber
Project:
**wp2shell**
The research implementation identifies the vulnerability chain as:```text
CVE-2026-63030
+
CVE-2026-60137
```
---
# Ссылки
* CVE-2026-63030
* CVE-2026-60137
* GHSA-ff9f-jf42-662q
* GHSA-fpp7-x2x2-2mjf
* WordPress Core
* WordPress REST API
* WordPress `WP_Query`
---
# Отказ от ответственности
Данный репозиторий содержит исследование безопасности, демонстрирующее цепочку уязвимостей, затрагивающую WordPress Core.
Программное обеспечение и документация предоставлены для:
* Образовательных целей
* Исследований в области безопасности
* Проверки уязвимостей
* Защитного тестирования
* Авторизованного тестирования на проникновение
Авторы не несут ответственности за неавторизованное или вредоносное использование данного материала.
**Тестируйте только те системы, которые принадлежат вам, или системы, на которые у вас есть явное разрешение.**
---
# Ключевые слова```text
wp2shell
WordPress
WordPress Core
WordPress Security
WordPress Vulnerability
WordPress RCE
Pre-Auth RCE
Pre-Authentication RCE
CVE-2026-63030
CVE-2026-60137
REST API
REST Batch
REST API Batch
Route Confusion
WP_Query
SQL Injection
SQLi
Blind SQL Injection
Privilege Escalation
Administrator Creation
Remote Code Execution
RCE
Proof of Concept
PoC
Security Research
Penetration Testing
```
---
## Темы репозитория
Рекомендуемые темы репозитория GitHub:```text
wp2shell
wordpress
wordpress-core
wordpress-security
wordpress-vulnerability
wordpress-rce
cve
cve-2026-63030
cve-2026-60137
poc
proof-of-concept
rce
sql-injection
sqli
blind-sqli
rest-api
security-research
penetration-testing
privilege-escalation
```
---
## Краткое описание проекта```text
wp2shell is a WordPress Core pre-authentication vulnerability-chain PoC
combining CVE-2026-63030 (REST API Batch route confusion) and
CVE-2026-60137 (WP_Query SQL injection), demonstrating the progression
from unauthenticated access to SQL injection, privilege escalation,
administrator creation, and authenticated code execution.
```
[No input content provided to translate.]```
disclaimer: this project is for educational purposes only
```