wp2shell

💙 Apoie o Projeto

Se você aprecia meu trabalho, considere apoiar o projeto via USDT (TRC20): TQBA72kakjCZLnJt8fJYcD7dyQCEpzNtVN

Cadeia RCE de Pré-Autenticação do WordPress Core

wp2shell é uma prova de conceito de pesquisa em segurança que demonstra uma cadeia de vulnerabilidades de pré-autenticação no WordPress Core, combinando:

CVE-2026-63030 — confusão de rota batch da API REST
CVE-2026-60137 — injeção SQL em WP_Query

A cadeia demonstra como essas vulnerabilidades podem ser combinadas para evoluir de uma requisição não autenticada à API REST para injeção SQL, escalonamento de privilégios, criação de conta de administrador e, por fim, execução remota de código autenticada.

[!WARNING]

Somente Pesquisa de Segurança Autorizada

Este projeto destina-se a:

Pesquisa de vulnerabilidades

Validação defensiva

Testes de penetração autorizados

Laboratórios de segurança

O PoC é implementado como uma ferramenta de pesquisa em Python e usa a biblioteca padrão do Python sem exigir pacotes Python de terceiros. --- # Cadeia de Vulnerabilidades O projeto combina duas vulnerabilidades do WordPress Core.```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 ``` A propriedade de segurança importante é a interação entre as duas vulnerabilidades, em vez de qualquer uma delas isoladamente. --- # CVE-2026-63030 ## Confusão de Rotas no Batch da REST API A primeira vulnerabilidade afeta o processamento de requisições através do endpoint REST API Batch do WordPress. A implementação do batch mantém informações de correspondência e validação de requisições em estruturas paralelas indexadas pela posição da requisição. Uma sub-requisição malformada pode fazer com que essas estruturas fiquem dessincronizadas. Isso cria uma condição de despacho off-by-one em que uma requisição posterior pode ser processada usando um handler ou contexto de validação associado a outra requisição. Conceitualmente:```text Request A | +-- validation entry +-- matching entry | v Malformed request | +-- internal state becomes desynchronized | v Request B | +-- unexpected handler / validation context ``` O PoC realiza verificações comportamentais para determinar se a confusão de rota é realmente alcançável. --- # CVE-2026-60137 ## Injeção SQL no WP_Query A segunda vulnerabilidade afeta um caminho de processamento SQL do `WP_Query`. Uma vez estabelecida a primitiva de confusão de rota, a entrada controlada pelo atacante pode alcançar o caminho de consulta vulnerável. O PoC demonstra a injeção SQL resultante por meio de teste diferencial cego. A funcionalidade de pesquisa inclui: * Confirmação booleana cega * Corroboração opcional baseada em tempo * Identificação de banco de dados * Extração de escalares suportada * Pesquisa de dados de usuários do WordPress --- # Como a Cadeia Funciona ## 1. Confusão de Rota no REST Batch Uma solicitação não autenticada atinge o endpoint REST Batch do WordPress. Uma sub-requisição batch malformada faz com que o estado interno de correspondência e validação de solicitações se torne dessincronizado. Uma solicitação posterior pode, consequentemente, ser processada usando um contexto não pretendido. --- ## 2. Injeção SQL A primitiva de confusão de rota fornece o caminho necessário para a segunda vulnerabilidade. Um valor controlado pelo atacante pode alcançar o caminho de processamento vulnerável do `WP_Query`. Isso cria uma primitiva de injeção SQL cega. --- ## 3. Extração Cega de SQL A injeção SQL pode ser usada como um canal de extração booleano cego. O PoC contém funcionalidades para pesquisar informações do banco de dados e informações suportadas de usuários do WordPress. --- ## 4. Manipulação do Estado da Aplicação A cadeia usa resultados controlados pelo banco de dados para influenciar objetos de aplicação do WordPress e o processamento subsequente. Isso fornece as primitivas necessárias para o estágio de escalonamento de privilégios. --- ## 5. Escalonamento de Changeset A cadeia usa o processamento de changesets do WordPress para estabelecer um contexto de execução de administrador. Um objeto `customize_changeset` fabricado pode participar da sequência de escalonamento de privilégios. --- ## 6. Reentrada de Hook A cadeia reentra no processamento de solicitações do WordPress por meio do ciclo de vida de solicitações da aplicação. Isso permite que o processamento subsequente da API ocorra sob o contexto elevado. --- ## 7. Criação de Conta de Administrador O PoC de pesquisa implementa um estágio de criação de administrador pré-autenticação. Esta é a principal razão pela qual o Modo 3 é útil para validação de segurança: ele demonstra o impacto do escalonamento de privilégios sem avançar para o estágio de webshell/RCE. --- ## 8. Execução de Código Autenticado O Modo 4 estende a cadeia de pesquisa além da criação do administrador, chegando ao estágio de execução de código autenticado. Este estágio deve ser usado somente em um laboratório isolado ou em uma avaliação explicitamente autorizada. --- # Versões Afetadas ## Cadeia Completa de Pré-Autenticação | Versão do WordPress | Status | | ----------------- | -------------- | | 6.9.0 – 6.9.4 | **Vulnerável** | | 7.0.0 – 7.0.1 | **Vulnerável** | | 6.9.5 | **Corrigido** | | 7.0.2+ | **Corrigido** | O PoC identifica `6.9.0–6.9.4` e `7.0.0–7.0.1` como as versões documentadas vulneráveis de cadeia completa. ## Injeção SQL O componente de injeção SQL tem um limite de versão corrigida diferente da cadeia completa. A implementação da pesquisa identifica `6.8.6` como a correção da injeção SQL. A cadeia completa não autenticada depende adicionalmente do comportamento vulnerável do REST Batch. Sempre verifique as versões afetadas e corrigidas em relação ao aviso de segurança oficial relevante antes de tomar decisões de produção. --- # Pré-condições O PoC documenta estas condições para a cadeia completa: * API REST do WordPress está acessível * Sem cache de objetos Redis/Memcached * Pelo menos um post publicado Outros componentes de implantação podem afetar a reprodutibilidade: * Proxies reversos * Firewalls de Aplicação Web * Restrições da API REST * Plugins de segurança * Cache de objetos * Filtragem HTTP * Configuração de hospedagem Uma instalação do WordPress que corresponda à faixa de versões não significa automaticamente que a cadeia completa funcionará em todos os ambientes. --- # Funcionalidades `wp2shell` fornece um menu interativo contendo as seguintes funções de pesquisa:```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 ``` --- # Menu Interativo O menu principal foi projetado para suportar ambos: * Testar uma única instalação autorizada do WordPress * Testar uma lista autorizada de URLs do WordPress O fluxo de trabalho pode, portanto, ser usado tanto para alvos de pesquisa individuais quanto para conjuntos de dados de avaliação autorizados maiores. --- # Modo Recomendado — Modo 3 ## Por que o Modo 3? Para pesquisa de vulnerabilidades, **o Modo 3 é o modo recomendado quando o objetivo é demonstrar o impacto de segurança sem implantar um webshell**. O Modo 3 é:```text Pre-Auth Admin Creation ``` O PoC descreve esta etapa como:```text Unauthenticated UNION SQLi → new WordPress administrator ``` e o distingue explicitamente do estágio completo de webshell/RCE:```text No password cracking. No webshell. Non-destructive admin only. ``` Isso torna o Modo 3 particularmente útil quando você quer provar que a cadeia de vulnerabilidades atinge o comprometimento em nível de administrador, evitando o estágio adicional de execução de código. --- # Modo 3 — Criação de Admin Pré-Autenticação Selecionar o Modo 3 abre:```text ──────────────────────────────────────────────────────────── CREATE ADMIN — Pre-Auth Admin RCE Chain ──────────────────────────────────────────────────────────── ⚠ Unauthenticated UNION SQLi → new WordPress administrator. ⚠ No password cracking. No webshell. Non-destructive admin only. ``` O PoC então solicita várias opções de ambiente e saída. ## SQLite```text → Target uses SQLite? (WP-SQLite plugin) (y/N) [n]: ``` Defina isto como `y` quando o alvo autorizado usar uma configuração WordPress SQLite suportada pelo PoC. Para instalações normais de WordPress com MySQL/MariaDB, o padrão é:```text n ``` ## Verificação de Credenciais O PoC pode opcionalmente verificar as credenciais geradas ao tentar um login autenticado:```text → Verify the generated credentials by logging in? (Y/n) [y]: ``` O padrão é:```text y ``` Isso é útil quando você deseja que o resultado inclua a confirmação de que as credenciais de administrador geradas realmente autenticam. --- ## Arquivo de Saída O Modo 3 pode salvar os resultados em um arquivo local:```text → Output file (blank = skip, e.g. result.txt): ``` Por exemplo:```text logs.txt ``` Deixar o campo em branco omite a saída de arquivo. A opção de saída é útil ao realizar pesquisas autorizadas em vários alvos e desejar reter os resultados para análise posterior. --- ## Confusion Carrier O PoC oferece duas variantes de carrier:```text → Confusion carrier variant (posts/categories) [posts]: ``` Opções disponíveis:```text posts categories ``` O padrão é:```text posts ``` A variante `posts` é o caminho principal documentado. --- # Modo 1 — Impressão digital e Confirmação Modo 1 é:```text [1] Fingerprint + confirm vulnerability (non-destructive) ``` Este é o ponto de partida mais seguro para a validação de vulnerabilidades. Ele se concentra em determinar se o alvo exibe as condições comportamentais associadas à cadeia de vulnerabilidades. A etapa de verificação pode incluir: * Fingerprinting do WordPress * Verificações de endpoint REST Batch * Confirmação de confusão de rota * Confirmação de injeção SQL * Teste diferencial cego booleano * Corroboração opcional baseada em tempo Use o Modo 1 quando o objetivo for principalmente:```text "Is this target potentially vulnerable?" ``` em vez de demonstrar impacto de administrador. --- # Modo 2 — Extração Cega de SQL O Modo 2 é:```text [2] Blind SQL extraction (fingerprint / dump users) ``` Este modo demonstra a primitiva de injeção SQL por meio de extração cega. A funcionalidade de pesquisa inclui: * Fingerprinting do banco de dados * Versão do banco de dados * Usuário do banco de dados * Nome do banco de dados * Expressões SQL escalares suportadas * Informações de usuário do WordPress Use este modo apenas em um ambiente autorizado, pois ele demonstra o impacto de acesso a dados em vez de apenas detectar a vulnerabilidade. --- # Modo 3 — Criação de Admin Pré-Auth Modo 3 é:```text [3] Pre-Auth Admin creation ``` Este modo demonstra o impacto de escalada de privilégios da cadeia. A distinção importante é:```text Mode 3 | +-- Pre-authentication chain +-- Administrator creation +-- Optional login verification +-- No password cracking +-- No webshell ``` Para pesquisadores de segurança que precisam comprovar o impacto de nível de administrador da vulnerabilidade sem implantar um webshell, este é o modo preferido. --- # Modo 4 — Cadeia RCE Completa Modo 4 é:```text [4] Full RCE chain → admin creation + webshell ``` Isso estende a cadeia para além da criação de administrador, até a execução de código autenticada. Conceitualmente:```text Unauthenticated ↓ Route Confusion ↓ SQL Injection ↓ Privilege Escalation ↓ Administrator Creation ↓ Administrator Authentication ↓ Webshell ↓ Code Execution ``` Este modo deve ser restrito a laboratórios isolados e a testes de penetração explicitamente autorizados. Para validação comum de vulnerabilidades, o Modo 3 é preferível, pois demonstra o limite de impacto do administrador sem implantar um webshell. --- # Modo 5 — Facilitated Sink SQLi O Modo 5 é:```text [5] Facilitated sink SQLi (WordPress 6.8.x / custom) ``` Este modo destina-se a pesquisa envolvendo o sink de injeção SQL fora da cadeia completa de pré-autenticação. É útil para pesquisadores que investigam: * Ambientes WordPress 6.8.x * Configurações personalizadas * O primitivo de injeção SQL de forma independente * Reprodução de vulnerabilidades * Validação defensiva --- # Modo 6 — Verificação de URL com Threads O Modo 6 é:```text [6] Threaded scan over URL list ``` Este modo destina-se a avaliações autorizadas envolvendo múltiplos alvos WordPress. Em vez de testar manualmente um URL de cada vez, a ferramenta pode processar uma lista de URLs usando worker threads. Conceitualmente:```text urls.txt | +-- URL 1 +-- URL 2 +-- URL 3 +-- URL 4 +-- ... | v Threaded vulnerability checks | v Results ``` A funcionalidade de varredura pode usar opções como: * Número de threads de trabalho * Atraso de confirmação * Prova de versão opcional * Saída de relatório em JSON * Variante de portadora de confusão Use isso apenas com listas de URLs para as quais você tem autorização explícita. --- # Alvo Único vs Lista de URLs `wp2shell` pode ser usado de duas maneiras gerais. ## Alvo Único do WordPress Use um único alvo ao pesquisar uma instalação. Casos de uso típicos: * Laboratório local * Ambiente de homologação * Teste de penetração aprovado pelo cliente * Reprodução de vulnerabilidade * Verificação de CVE O alvo deve ser uma URL base do WordPress. --- ## Lista de URLs Para múltiplos alvos autorizados, o Modo 6 pode processar uma lista de URLs. Exemplo de arquivo conceitual:```text https://wordpress-lab-01.example https://wordpress-lab-02.example https://wordpress-lab-03.example https://wordpress-lab-04.example ``` O scanner com threads pode então processar a lista e registrar os resultados. A implementação da varredura também oferece suporte a uma opção de saída/relatório para reter as descobertas. --- # Guia de Seleção de Modo | Objetivo | Modo Recomendado | | -------------------------------------- | ---------------- | | Verificar se um alvo está vulnerável | **Modo 1** | | Demonstrar injeção de SQL | **Modo 2** | | Demonstrar impacto em nível de administrador | **Modo 3** | | Demonstrar a cadeia completa de RCE | **Modo 4** | | Pesquisar o sink de SQLi de forma independente | **Modo 5** | | Testar uma lista de URLs autorizadas | **Modo 6** | | Configurar proxy/TLS/timeout/delay | **Modo 7** | | Alterar o alvo atual | **Modo 8** | ### Fluxo de trabalho de pesquisa recomendado Para a maioria das avaliações de segurança:```text Mode 1 ↓ Confirm vulnerability ↓ Mode 3 ↓ Demonstrate administrator impact ``` Only continue to Mode 4 when full code-execution validation is explicitly required and authorized. --- # Mode 7 — Transport Settings Mode 7 is:```text [7] Transport settings (proxy, TLS, timeout, delay) ``` This section controls the HTTP transport behavior used by the tool. Supported research settings include: * Proxy configuration * TLS behavior * Request timeout * Request delay * Connection/retry behavior These options are useful when testing WordPress installations behind: * Proxies * TLS configurations * Slow connections * Rate-limiting infrastructure * Controlled lab environments --- # Modo 8 — Alterar URL de Destino O Modo 8 é:```text [8] Change target URL ``` Isto permite que o alvo atualmente selecionado seja alterado sem reiniciar todo o fluxo de trabalho interativo. É útil ao mover-se entre instalações de laboratório autorizadas. --- # Lógica de Detecção A PoC usa verificações comportamentais em vez de depender exclusivamente de uma string de versão do WordPress. ## Detecção de REST Batch A ferramenta verifica se o endpoint REST Batch está acessível. ## Detecção de Confusão de Rotas A ferramenta pode usar: * Marcadores de resposta * Comportamento estrutural da resposta A abordagem estrutural verifica se uma solicitação destinada a uma coleção REST é processada como outra coleção. ## Detecção de Injeção de SQL A ferramenta pode realizar um diferencial cego booleano. Um canal baseado em tempo pode adicionalmente ser usado como corroboração. --- # Cadeia Técnica A cadeia completa de pesquisa pode ser resumida como:```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 ``` --- # Variantes de Rota O PoC suporta duas variantes de portador de confusão:```text posts categories ``` O padrão é:```text posts ``` A variante `posts` é o principal transportador de ponta a ponta documentado. A variante `categories` fornece um caminho alternativo de confusão de rota para pesquisa. --- # Suporte a SQLite O PoC contém suporte de compatibilidade SQLite para ambientes que usam uma configuração WordPress SQLite. O Modo 3 expõe esta opção como:```text Target uses SQLite? (WP-SQLite plugin) ``` Padrão:```text n ``` Uso:```text y ``` when o alvo autorizado utiliza a configuração SQLite suportada. --- # Instalação O PoC utiliza a biblioteca padrão do Python. Nenhum pacote Python de terceiros é necessário. Ambiente necessário:```text Python 3.x ``` Clone o repositório e execute a ferramenta de pesquisa em um ambiente isolado ou explicitamente autorizado. --- # Estrutura do Projeto Uma estrutura de repositório recomendada é:```text wp2shell/ │ ├── wp2shell.py ├── README.md ├── LICENSE └── screenshots/ ``` A principal implementação da pesquisa é:```text wp2shell.py ``` --- # Impacto de Segurança Uma cadeia de exploração bem-sucedida pode potencialmente resultar em: * Injeção de SQL não autenticada * Divulgação de informações do banco de dados * Exposição de informações de usuários do WordPress * Escalação de privilégios * Criação de conta de administrador * Acesso administrativo total ao WordPress * Execução arbitrária de código autenticada * Potencial comprometimento ao nível do sistema operacional, dependendo do ambiente de hospedagem A cadeia completa, portanto, tem um impacto significativamente maior do que as vulnerabilidades individuais consideradas de forma independente. --- # Detecção Defensiva Os administradores devem investigar atividades suspeitas envolvendo: * Endpoints REST Batch do WordPress * Requisições de batch aninhadas anormais * Caminhos de requisição batch malformados * Parâmetros de consulta suspeitos * Criação inesperada de conta de administrador * Atividade inesperada de `customize_changeset` * Instalações inesperadas de plugins * Arquivos PHP inesperados * Modificações suspeitas de plugins * Comportamento semelhante a webshell Revisão:```text Web server logs + WordPress logs + Database audit logs + File integrity monitoring ``` especialmente em torno do momento de suspeita de exploração. --- # Mitigação A principal mitigação é atualizar o WordPress para uma versão corrigida. As instalações afetadas também devem: 1. Revise todas as contas de administrador. 2. Remova contas de administrador não autorizadas. 3. Revise plugins instalados ou modificados recentemente. 4. Revise os logs da API REST do WordPress. 5. Revise os logs de acesso do servidor web. 6. Procure por arquivos PHP inesperados. 7. Verifique os diretórios de plugins em busca de modificações não autorizadas. 8. Roteie as credenciais se houver suspeita de comprometimento. 9. Revise a integridade do banco de dados. 10. Remova mecanismos de persistência. 11. Reinstale componentes do WordPress comprometidos a partir de fontes confiáveis quando apropriado. --- # Fluxo de Trabalho de Pesquisa Responsável Para uma avaliação autorizada normal, a progressão recomendada é:```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 é geralmente o ponto preferido de demonstração de impacto porque estabelece comprometimento em nível de administrador sem implantar o estágio de webshell. --- # Pesquisa vs Produção Este projeto destina-se a pesquisa de segurança controlada. Não trate a ferramenta como um scanner de Internet de uso geral. Para ambientes de produção: * Obtenha autorização por escrito. * Defina o escopo do alvo. * Defina as ações permitidas. * Prefira verificação não destrutiva. * Pare depois que evidências suficientes forem coletadas. * Preserve logs e evidências. * Siga o processo de divulgação de vulnerabilidades aplicável. --- # Créditos Pesquisa / descoberta de vulnerabilidade: **Adam Kues** Assetnote / Searchlight Cyber Projeto: **wp2shell** A implementação da pesquisa identifica a cadeia de vulnerabilidades como:```text CVE-2026-63030 + CVE-2026-60137 ``` --- # Referências * CVE-2026-63030 * CVE-2026-60137 * GHSA-ff9f-jf42-662q * GHSA-fpp7-x2x2-2mjf * WordPress Core * WordPress REST API * WordPress `WP_Query` --- # Aviso Legal Este repositório contém pesquisa de segurança demonstrando uma cadeia de vulnerabilidades que afeta o WordPress Core. O software e a documentação são fornecidos para: * Fins educacionais * Pesquisa de segurança * Verificação de vulnerabilidades * Testes defensivos * Testes de penetração autorizados Os autores não são responsáveis pelo uso não autorizado ou malicioso deste material. **Teste apenas sistemas que você possui ou sistemas para os quais você possui autorização explícita.** --- # Palavras-chave```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 ``` --- ## Tópicos do Repositório Tópicos recomendados do repositório 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 ``` --- ## Resumo do Projeto```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 content was provided in the INPUT section, so there is no text to translate. Please provide the chunk content.``` disclaimer: this project is for educational purposes only ```

wp2shell-poc

Mais Populares

Índice

Visão Geral