A injeção SQL: Duas chamadas de batch aninhadas exploram isso. O batch externo contorna a allow-list de métodos (que normalmente bloqueia GET). O batch interno entrega uma string escalar author_exclude para GET /wp/v2/posts - a dessincronização a roteia além da validação, e o WP_Query interpola a string não sanitizada diretamente no SQL, produzindo uma injeção cega baseada em UNION.

Envenenamento de cache: A SQLi retorna objetos WP_Post forjados, que o WordPress armazena em cache na memória. Esses posts falsos contêm shortcodes [embed] que fazem o WordPress criar linhas reais de oembed_cache no banco de dados a partir das referências falsas.

Escalação de changeset: Usando a SQLi, o atacante forja um post customize_changeset em memória com "user_id": 1 em seu JSON. Um gadget de detecção de ciclo dispara wp_update_post() sem sobrescrever post_content, preservando o payload do atacante. A aplicação do changeset assume temporariamente a identidade do administrador.

Reentrada de hook: Um post fabricado com status parse e tipo request dispara o hook parse_request, reproduzindo toda a requisição de batch com o papel de admin assumido. Desta vez, uma sub-requisição POST /wp/v2/users é bem-sucedida, criando uma nova conta de admin.

Execução de código: O atacante faz login como o admin criado e envia um plugin malicioso para executar comandos arbitrários.

Versões afetadas

Uso

Para usar este PoC, o único requisito é Python 3.8+.

Execute-o a partir do diretório do repositório para realizar uma verificação de vulnerabilidade:

Modo Check (padrão)

Realiza uma única verificação de vulnerabilidade. Envia uma sonda de marcador de batch benigna que detecta o bug de confusão de rota sem executar payloads de SQLi. Um alvo vulnerável retorna HTTP 207 com o padrão de erro parse_path_failed, block_cannot_read e rest_batch_not_allowed.

Use --confirm-sqli para também enviar um payload ativo de confirmação de SQLi. A confirmação tenta primeiro a reflexão UNION, depois recorre a sondas baseadas em timing.

Verificar alvo único (modo padrão)

Verificar com modo explícito

Verificar com confirmação de SQLi

Modo Read - Extrair dados através de injeção SQL

Extrai dados do banco de dados usando a injeção SQL pré-autenticação. Por padrão usa --technique auto, que tenta os métodos disponíveis nesta ordem:

• union - forja uma linha WP_Post falsa via UNION e lê seu título de volta da resposta REST como ||HEX(value)||. Uma requisição por valor. Mais rápido.
• error - usa EXTRACTVALUE/UPDATEXML para vazar ~15 bytes por requisição. Funciona quando o alvo reflete erros do MySQL (por exemplo, WP_DEBUG_DISPLAY ativado).
• blind - busca binária booleana, ~8 requisições por caractere. Lê o cabeçalho X-WP-Total como o sinal de verdadeiro/falso. Funciona mesmo quando nenhum dado é refletido.

Force uma técnica específica com --technique union|error|blind. Esses caminhos de leitura são somente leitura e não escrevem no banco de dados.

Fingerprint do servidor (consulta padrão)

Dump de logins e hashes de senha

Consulta SQL personalizada

Forçar técnica blind

Extrair com técnica baseada em erro

Modo Shell

Executa comandos no servidor alvo. Funciona em dois modos:

Com credenciais (faz login como admin existente e envia plugin shell):

Executar comando específico

Shell interativo

Executar comando único

Shell interativo

O webshell do plugin é enviado com um caminho aleatório e um token por execução. O webshell enviado é removido automaticamente. Quando a ponte pré-autenticação cria um administrador, essa conta gerada é removida automaticamente após o término da sessão de shell.

Lista de todas as flags:

Referências:

1. https://slcyber.io/research-center/exploit-brokers-pay-500000-for-a-wordpress-rce-i-found-one-with-gpt5-6/
2. https://www.picussecurity.com/resource/blog/cve-2026-63030-and-cve-2026-60137-wp2shell-wordpress-rce-explained

Aviso legal

Esta ferramenta foi criada exclusivamente para fins educacionais ou de bug bounty. O uso não autorizado fora de ambientes controlados é estritamente proibido.