Tabela de comparação

[1] Apenas timing/cego como canal de leitura; a primitiva de fake-post UNION existe dentro da ponte, mas não é exposta como oráculo de extração. [2] A sonda ingênua de disponibilidade (0) UNION SELECT …) é silenciosamente descartada durante a hidratação do cache de objetos, available() retorna falso, e toda a ponte pré-autenticação é abortada - veja §1. [3] O próprio README do projeto lista "sem cache de objetos persistente (Redis/Memcached)" em Pré-condições. [4] Variante pública espelhada no Sploitus (link abaixo): leitura cega mais um dropper INTO OUTFILE como etapa de RCE, usando um carrier de categorias per_page=-1. [5] O caminho de RCE por OUTFILE não depende da renderização de fake-posts, então caches de objetos não o bloqueiam - quem o bloqueia são o privilégio FILE do MySQL e um diretório gravável compartilhado. Hospedagem gerenciada quase nunca concede FILE ao usuário do banco do WordPress, e secure_file_priv costuma estar definido.

1. O problema do cache de objetos (o verdadeiro diferencial)

A primitiva de fake-post UNION depende de como o WP_Query retorna linhas:

• Modo de linha completa - o SQL retorna linhas inteiras de wp_posts; uma linha injetada via UNION torna-se um WP_Post diretamente. A falsificação é renderizada.
• Modo dividido (somente IDs) - o SQL retorna apenas IDs, e cada ID é hidratado depois pelo cache de objetos persistente / banco de dados. O ID da linha forjada não existe, então a hidratação o descarta silenciosamente. Sem erro, sem post forjado.

Em hosts com cache de objetos persistente, uma base de resultados populada coloca o WP_Query em modo dividido. A sonda padrão usada pelos PoCs públicos -

• deixa a base de resultados populada (post_author NOT IN (0) corresponde a todas as linhas), então atrás de um cache de objetos a linha forjada evapora: a sonda de disponibilidade gera falsos negativos, available() retorna falso, e toda a ponte pré-autenticação é reportada como "morta" em um host que, na verdade, é totalmente explorável. O unificador público documenta o mesmo limite ao listar "sem cache de objetos persistente" como uma pré-condição rígida.

Este repositório esvazia a base de resultados em vez disso:

Com zero linhas na base, a linha forjada é a única linha; a consulta permanece em modo de linha completa; nenhuma busca de hidratação é executada. Uma única palavra-chave injetada (AND 1=0) é toda a diferença entre "canal UNION morto" e "RCE pré-autenticação completo" em hosts com cache de objetos - que são a maioria dos ambientes gerenciados de WordPress em produção. O diagnóstico, a matriz de sondas (per_page × forma de injeção).

Nota de escopo: o canal de leitura cego/por timing não é sensível ao cache de objetos (contar linhas no SQL não envolve hidratação de fake-posts), então a leitura cega de todos os PoCs funciona em qualquer lugar. O que o cache de objetos mata nos outros PoCs é especificamente a parte dependente de UNION: a extração in-band e a ponte SQLi-para-admin.

Uma segunda lição relacionada, documentada no estudo de caso: quando ambos os canais funcionam, trate a leitura UNION in-band como autoritativa - o oráculo de timing em produção produziu inversões de bits sob jitter em um valor que a leitura in-band resolveu de forma inequívoca.

2. Escolha do caminho de RCE

Existem três caminhos de RCE pré-autenticação entre os PoCs públicos:

Este repositório implementa a ponte: ela não exige privilégios de banco além do que o WordPress já tem, funciona quando as camadas de banco e web não compartilham nada, e não deixa nenhum arquivo para o caminho baseado no privilégio FILE depender. O trade-off é a complexidade - a ponte é um grafo de posts envenenados de sete linhas - que é exatamente onde o falso negativo de cache de objetos da §1 costumava esconder o caminho.

3. Padrões de segurança para uso autorizado

Construído para execução contra sistemas de produção sob autorização, não apenas laboratórios:

• O check é não destrutivo por padrão - fingerprint passivo mais um batch de marcadores benigno; nenhum payload SQL é enviado a menos que --confirm-sqli seja fornecido. Após a correção, o tripleto de marcadores que desaparece serve também como validação da correção.
• Tagging de atribuição - --user-agent em todos os comandos para que todo o tráfego de exploração seja identificável nos logs (uma regra prática de engajamentos que as ferramentas públicas não adotam por padrão).
• Limpeza automática - a webshell é protegida por token em um caminho aleatório e se remove; um administrador criado pela ponte é excluído em seguida, com seu conteúdo reatribuído à conta admin emprestada. Falhas na limpeza são reportadas de forma bem visível, não engolidas.
• Contabilização de requisições - todos os comandos imprimem quantas requisições enviaram.

4. O que este repositório não afirma

• Nenhuma vulnerabilidade nova. Ambos os bugs são os CVEs divulgados publicamente; o formato de batch duplamente aninhado, o sink author_exclude → author__not_in, a primitiva UNION de WP_Post falso e o conceito de ponte via customizer são todas técnicas públicas (linhagem reconhecida abaixo).
• Nenhuma primitiva de exploração nova. A diferença sobre o panorama público é: a correção de cache de objetos com base esvaziada, com evidências de produção, os padrões seguros para produção e a documentação de detecção - robustez e segurança operacional, não novidade de técnica.
• Strings de IoC são arbitrárias. Prefixos de login, slugs de plugins, marcadores de shell e valores de User-Agent diferem em cada variante e a cada execução;

Referências

• Icex0/wp2shell-poc - implementação de cadeia completa compartilhada pela linhagem deste repositório - https://github.com/Icex0/wp2shell-poc
• sergiointel/wp2shell-poc - primeiro PoC público; origem da técnica de criação de admin sem quebra de hash - https://github.com/sergiointel/wp2shell-poc
• 0xsha/wp2shell - unificador de arquivo único de seis PoCs públicos, com laboratórios Docker e uma matriz versão×banco (documenta a pré-condição do cache de objetos) - https://github.com/0xsha/wp2shell
• Variante OUTFILE (leitura cega + dropper INTO OUTFILE), espelhada no Sploitus - https://sploitus.com/exploit?id=7CD079AD-E27B-5C54-A696-60635BFDB241
• Lista curada de PoCs públicos e verificadores (para defensores) - https://www.cyberkendra.com/2026/07/wp2shell-guide.html
• GHSA-ff9f-jf42-662q / GHSA-fpp7-x2x2-2mjf; anúncio do lançamento do WordPress 7.0.2 - veja as referências no README.md.