WP2Shell no WordPress: o que corrigir e como proteger seu site

Por William Pereira · 2026-10-21

Uma senha forte não resolve uma falha que permite atacar antes do login. Esse é o ponto que torna WP2Shell relevante para quem mantém um site em WordPress: duas vulnerabilidades do núcleo podem ser combinadas para chegar à execução de código no servidor, sem uma conta prévia.

Para uma empresa, o problema aparece como risco à continuidade do site, aos dados e à confiança de clientes. A resposta precisa reunir atualização e verificação de integridade. Trocar a senha do administrador, sozinho, deixa a causa aberta.

Apuração em 21 de outubro de 2026. A divulgação e as correções são de julho. A análise publicada pela Seqrite em outubro retoma o assunto; ela não marca a descoberta de uma nova falha.

O que está confirmado sobre WP2Shell

WP2Shell é o nome dado à combinação de uma confusão de rotas no processamento em lote da API REST com uma injeção SQL. A primeira desvia o processamento esperado de requisições; a segunda permite que uma entrada interfira em consultas ao banco. O resultado da combinação é mais grave que cada problema considerado isoladamente.

O aviso oficial de CVE-2026-63030 confirma a cadeia de execução remota e atribui a descoberta a Adam Kues, da Assetnote / Searchlight Cyber. O aviso de CVE-2026-60137 trata da injeção SQL no argumento author__not_in de WP_Query. Ambos foram publicados em 17 de julho de 2026.

A divulgação dos pesquisadores descreve exploração por usuário anônimo em instalação padrão, sem plugins. Portanto, remover um plugin vulnerável ou exigir autenticação em dois fatores no painel não corrige esta cadeia no núcleo. Isso também não significa que toda instalação exposta tenha sido invadida: possibilidade técnica e comprometimento comprovado são coisas diferentes.

Quais versões foram afetadas e corrigidas

Os avisos do WordPress permitem separar os cenários:

• 6.9.0 a 6.9.4: afetadas pela cadeia completa; correção em 6.9.5.
• 7.0.0 a 7.0.1: afetadas pela cadeia completa; correção em 7.0.2.
• 6.8.0 a 6.8.5: afetadas pela injeção SQL relacionada, sem a mesma cadeia completa de WP2Shell; correção em 6.8.6.

A versão 6.8 exige atenção justamente por essa diferença: estar fora da cadeia completa não significa estar livre da falha de SQL. O comunicado dos pesquisadores usa esse recorte mais estreito; para avaliar a SQLi, consulte também o aviso específico do WordPress.

O comunicado oficial da versão 7.0.2, de 17 de julho, também registra a correção em 7.1 beta2 e informa que versões anteriores a 6.8 não são afetadas por esses problemas. Isso não torna versões antigas uma opção recomendável: elas podem ter outros riscos. As versões corrigidas listadas aqui são marcos históricos desta vulnerabilidade, não uma indicação de que sejam as mais recentes em outubro. Atualize para uma versão estável atual e compatível, seguindo as orientações oficiais.

Qual é o impacto e o que já foi observado

Na análise de 16 de outubro, a Seqrite documenta uma demonstração que cria acesso administrativo e instala um plugin malicioso com capacidade de executar comandos. Esse é um comportamento demonstrado, não uma prova de que todos os sites afetados passaram pela mesma sequência.

Já a Wiz Research relatou em 20 de julho exploração observada em instalações WordPress na nuvem, incluindo instalação de backdoors persistentes. Há, portanto, evidência pública de exploração real. As fontes consultadas não permitem quantificar uma campanha global em andamento em 21 de outubro. Não é correto transformar essa limitação em uma afirmação de ausência de ataques.

Do ponto de vista operacional, uma conta administrativa desconhecida ou um plugin inesperado merece investigação. A execução de código pode ampliar o incidente além do painel, de acordo com as permissões do processo e o isolamento da hospedagem. O alcance precisa ser apurado no ambiente; não pode ser deduzido apenas pelo nome da vulnerabilidade.

O que fazer se você administra um site

1. Faça um inventário. Confira a versão efetivamente instalada, a hospedagem responsável e outras instalações do mesmo negócio, incluindo ambientes esquecidos. Peça ao fornecedor evidência da versão aplicada.
2. Atualize e valide. Preserve uma cópia de segurança e organize a atualização com urgência. Depois confira a versão em execução e teste páginas, formulários, loja e integrações. Uma notificação de atualização disponível não comprova que ela terminou.
3. Use contenção temporária quando necessário. Os pesquisadores recomendam bloquear acesso anônimo à API de lotes se não for possível atualizar imediatamente. A proteção precisa considerar tanto /wp-json/batch/v1 quanto a forma ?rest_route=/batch/v1. Coordene a regra com a hospedagem ou o responsável pelo WAF e teste funções legítimas; restringir a API REST pode quebrar integrações. Essa medida não substitui a correção nem cobre automaticamente todos os caminhos da SQLi isolada.
4. Verifique o histórico. Revise administradores, alterações de plugins e arquivos, registros de acesso e eventos da hospedagem no período em que o site esteve vulnerável.

Atualizar não encerra um incidente anterior

O patch fecha a vulnerabilidade, mas não remove necessariamente o que alguém já instalou. Se aparecerem mudanças sem explicação, preserve logs e cópias dos arquivos antes de limpar o ambiente. Envolva a hospedagem e uma equipe de resposta para conter o acesso, verificar persistência e recuperar uma base confiável.

A Seqrite descreve nomes de arquivos associados aos seus testes e à atividade analisada. Eles ajudam a orientar uma busca, mas não formam uma lista completa: um invasor pode mudar nomes. Da mesma forma, encontrar um arquivo PHP novo ou atividade do servidor web não prova, por si só, WP2Shell. Correlacione horário, autoria e alterações autorizadas antes de concluir.

Após a contenção, revise credenciais, sessões e segredos potencialmente expostos, com escopo definido pela investigação. Restaure a partir de uma origem confiável e valide a integridade antes de retomar a operação. A ausência de um indicador conhecido não demonstra que o ambiente está limpo.

A decisão de gestão por trás do patch

O trabalho útil começa com três entregas verificáveis: saber quais instalações existem, comprovar que receberam correção e investigar o período anterior quando houver sinais de comprometimento. Defina quem responde por cada uma e onde a evidência fica registrada. Sem isso, a manutenção vira uma expectativa compartilhada, sem responsável claro.

Para quem contrata desenvolvimento ou hospedagem, vale incluir essas responsabilidades na rotina de operação. Segurança de um site depende também de inventário, atualização e capacidade de recuperação depois da entrega.

Fontes e critério editorial

Os links ao longo do texto levam aos avisos oficiais, à divulgação dos descobridores e aos relatos técnicos usados na apuração. A pauta partiu da notícia do elhacker.NET, lida integralmente; as afirmações técnicas foram conferidas nas fontes primárias. Não executamos exploração em sites nem realizamos uma medição própria da prevalência de ataques. Este artigo apresenta uma síntese original para administradores, sem reproduzir procedimentos ofensivos.