Apareceu um usuário administrador ou plugin estranho no seu WordPress? Entenda o wp2shell

Você abre o painel do WordPress e encontra algo que não deveria estar ali: uma conta de administrador que ninguém reconhece, um plugin de nome aleatório ou uma alteração que ninguém da equipe realizou. Talvez o site também tenha parado de responder ou começado a devolver erro 403.

Esses sinais podem ter várias causas e, isoladamente, não identificam a origem do problema. Mas, se o site esteve em uma das versões vulneráveis em julho de 2026, eles justificam investigar uma cadeia crítica de falhas no próprio WordPress, conhecida como wp2shell.

Se a exploração for confirmada, isso não significa que alguém descobriu sua senha ou que você instalou um plugin inseguro. A vulnerabilidade estava no núcleo do WordPress e podia ser explorada, em uma instalação padrão, sem login e sem depender de tema ou plugin vulnerável.

O que é o wp2shell, em português e sem jargão

O wp2shell é o nome dado a uma cadeia de duas vulnerabilidades no core, o software-base executado por todo site WordPress. A Searchlight Cyber divulgou o caso publicamente em 17 de julho de 2026, após o processo de correção coordenada.

A primeira vulnerabilidade, CVE-2026-63030, era uma confusão de rota no endpoint em lote da API REST. Em determinadas condições, o WordPress validava uma requisição, mas executava outra rota.

A segunda, CVE-2026-60137, era uma injeção de SQL associada ao parâmetro interno author__not_in, usado pelo WP_Query para consultar o banco de dados.

Encadeadas, as duas falhas permitiam que um atacante anônimo manipulasse consultas, criasse um usuário administrador e chegasse à execução de código no servidor. A análise técnica da Searchlight Cyber descreve como registros forjados, cache de oEmbed e dados de personalização eram utilizados para avançar da injeção SQL até a tomada do site.

A cadeia completa atingia instalações padrão, sem plugins. Há uma ressalva técnica: o caminho público de exploração podia não completar a execução remota em sites que usavam cache persistente externo, como Redis ou Memcached. Isso não transforma o cache em correção, não elimina a injeção SQL e não reduz a necessidade de atualizar e investigar.

Quais versões foram afetadas

Versão do WordPress	Exposição	Versão corrigida
6.8.0 a 6.8.5	Injeção SQL, sem a cadeia pública completa de RCE	6.8.6
6.9.0 a 6.9.4	Cadeia completa de execução remota sem autenticação	6.9.5
7.0.0 a 7.0.1	Cadeia completa de execução remota sem autenticação	7.0.2
Anteriores à 6.8	Não afetadas por essas duas vulnerabilidades	—

O comunicado oficial do WordPress 7.0.2 classifica as correções como uma questão crítica e outra de alta severidade. Devido à gravidade, o WordPress.org ativou atualizações automáticas forçadas para instalações afetadas que suportavam esse mecanismo.

Ainda assim, não se deve presumir que a atualização chegou a todos os sites. Configurações da hospedagem, permissões, alterações no sistema de atualização ou um comprometimento prévio podem impedir ou atrasar sua aplicação.

Por que esse incidente foi diferente

Durante anos, a maior parte das recomendações de segurança para WordPress concentrou-se em plugins e temas desatualizados. Essa orientação continua válida, mas não explicava o que estava acontecendo neste caso.

O wp2shell estava no núcleo da plataforma. A versão estável mais recente no momento da divulgação, a 7.0.1, encontrava-se dentro do intervalo vulnerável. Portanto, um site que estivesse plenamente atualizado antes de 17 de julho ainda poderia estar exposto.

Isso também explica a velocidade do incidente. A Patchstack confirmou exploração ativa, e a Wiz observou ataques bem-sucedidos, incluindo acesso administrativo, upload de plugins maliciosos e instalação de webshells.

A Searchlight Cyber estima que mais de 500 milhões de sites utilizem WordPress. Esse número representa o universo total de sites WordPress, não a quantidade comprovadamente vulnerável ou comprometida. Não há uma contagem pública confiável de quantos sites foram efetivamente invadidos.

Como saber se o site pode ter sido comprometido

Não existe um único sinal capaz de confirmar ou descartar a invasão. O correto é combinar usuários, arquivos, banco de dados, registros de acesso e a cronologia do site.

Sinais fortes de comprometimento

• Administrador desconhecido ou usuário legítimo que recebeu privilégios administrativos sem explicação.
• Plugin comum ou plugin indispensável, também chamado de MU-plugin, que ninguém da equipe instalou.
• Arquivo PHP novo ou alterado em wp-content/plugins, wp-content/mu-plugins, wp-content/uploads ou diretórios de cache.
• Acesso bem-sucedido ao painel, upload de plugin ou chamada a um novo arquivo PHP logo depois de uma requisição ao endpoint /wp-json/batch/v1.
• Registros suspeitos de oembed_cache ou customize_changeset, IDs de conteúdo anormalmente altos, metadados de usuários órfãos ou lacunas inexplicáveis na sequência de IDs.

Indicadores associados a exploits públicos

Algumas ferramentas públicas criavam usuários com prefixos como wp2_ ou w2s_ e endereços terminados em @wp2shell.invalid ou @wp2shell.shellcode.lol. Esses padrões são indicadores relevantes, mas não são uma assinatura universal. Um atacante pode alterar os nomes, apagar a conta criada ou utilizar outro mecanismo de persistência.

Da mesma forma, nomes aleatórios de plugins ou arquivos, como os exemplos vistos em relatos desse período, merecem investigação. O nome por si só não atribui o ataque ao wp2shell.

Sinais inconclusivos

• Um erro 403 ou 500 isolado.
• Uma tentativa bloqueada pelo Wordfence, Imunify ou firewall.
• Muitas requisições para a API REST.
• Ter utilizado uma versão vulnerável por algum tempo.
• Um scanner não encontrar malware.

Um erro 403 generalizado pode acompanhar um comprometimento, como ocorreu no atendimento que motivou este artigo, mas também pode ser produzido por uma regra de segurança que bloqueou o ataque. É contexto para a investigação, não uma prova.

O que observamos no atendimento que motivou este artigo

Este material nasceu durante a recuperação de um site acompanhado pela OWN havia quase dez anos. Depois de uma restauração, contas administrativas ilegítimas continuavam presentes, embora o site já mostrasse uma versão corrigida do WordPress.

Ao cruzar a linha do tempo dos usuários, os registros de atividade, os arquivos e a data da divulgação, percebemos que três explicações comuns não se encaixavam: não havia evidência de que a entrada tivesse ocorrido por senha fraca, tema desatualizado ou plugin pirata. Os achados eram compatíveis com a exploração do wp2shell e com mecanismos de persistência deixados antes da atualização.

Se registros suspeitos aparecerem em áreas associadas a conteúdo ou plugins de formulário, isso não torna o Contact Form 7, o Flamingo ou outro plugin semelhante a porta de entrada. A cadeia conhecida usa registros internos do WordPress, incluindo conteúdos temporários e caches; dependendo da instalação, esses registros podem aparecer em telas de outros componentes.

Essa distinção importa: uma coincidência visual não é a mesma coisa que uma vulnerabilidade comprovada.

Atualizar fecha a porta, mas não limpa o que ficou

Aplicar a atualização de segurança impede novas entradas pela mesma vulnerabilidade. Mas, se o atacante agiu antes da correção, ele pode ter deixado:

• usuários administradores;
• plugins ou arquivos de webshell;
• sessões e senhas de aplicação;
• tarefas agendadas;
• alterações no banco de dados;
• mudanças no .htaccess, .user.ini ou wp-config.php;
• arquivos fora da pasta principal do WordPress.

A atualização não remove automaticamente esses elementos.

O mesmo cuidado vale para backups. Uma cópia feita depois da invasão pode trazer o comprometimento de volta. Mesmo um backup anterior pode conter uma versão vulnerável do WordPress.

O que fazer se você só tem acesso ao wp-admin

Se houver sinais fortes de ataque em andamento, avise a hospedagem imediatamente. Peça que ela preserve uma cópia do ambiente e, se necessário, restrinja temporariamente o acesso público enquanto a investigação é realizada.

1. Confirme e atualize a versão do WordPress

No painel, acesse Painel → Atualizações. Use no mínimo a versão corrigida da sua linha: 6.8.6, 6.9.5, 7.0.2 ou qualquer versão posterior compatível.

O verificador público da Searchlight Cyber ajuda a identificar externamente se uma versão parece vulnerável. Ele não informa se o site foi invadido antes da atualização.

2. Preserve evidências antes de excluir usuários ou arquivos

Exporte os registros do plugin de atividades, faça capturas das telas e anote datas, nomes, e-mails, funções e alterações suspeitas. Se possível, peça à hospedagem um snapshot de arquivos e banco de dados.

Não mantenha o site vulnerável no ar apenas para preservar evidências. A contenção vem primeiro; a orientação é evitar apagar rastros desnecessariamente durante a correção.

3. Revise todos os usuários e suas funções

Comece pelos administradores. Confirme com a equipe quem criou cada conta e se alguma função foi alterada. A tela nativa do WordPress não exibe a data de registro como coluna; use os registros de atividade, um relatório da hospedagem ou apoio técnico para montar a cronologia.

Uma conta de assinante recém-criada pode ser legítima, principalmente em sites com cadastro público. Trate-a como evidência complementar, não como confirmação equivalente a um administrador desconhecido.

4. Verifique plugins, MU-plugins e drop-ins

Em Plugins, procure itens desconhecidos nas listas de plugins instalados e indispensáveis. Revise também drop-ins, mas com contexto: arquivos como object-cache.php e advanced-cache.php são comuns em soluções legítimas de cache.

Não apague um arquivo apenas porque o nome parece estranho. Registre-o e peça uma análise quando não souber sua origem.

5. Revogue senhas de aplicação desconhecidas

Edite o perfil de cada usuário privilegiado e localize Senhas de aplicação. Revogue qualquer credencial que a equipe não reconheça. Uma senha de aplicação não permite login comum no wp-admin, mas pode manter acesso programático à API.

6. Invalide acessos e troque credenciais

Troque as senhas dos usuários privilegiados e, se houver risco de leitura do banco, considere a redefinição de todos os usuários. Também devem ser rotacionadas as credenciais da hospedagem, SFTP, painel de controle, banco de dados e serviços de implantação.

As chaves e salts do wp-config.php devem ser renovados para encerrar sessões existentes. Essa etapa normalmente exige acesso à hospedagem. Troque as credenciais novamente depois que a limpeza for concluída, pois um código malicioso ainda ativo poderia capturar a primeira mudança.

Ative autenticação em dois fatores como parte do endurecimento pós-limpeza. Ela protege contas, mas não remove um webshell já instalado.

7. Use verificações complementares

Uma ferramenta como o Wordfence pode fazer uma varredura ampla e comparar muitos arquivos do core, temas e plugins do repositório oficial. A cobertura é mais limitada para componentes personalizados ou comerciais.

O Compromise Scanner for wp2shell procura artefatos específicos deixados pela cadeia conhecida. Ele é útil para triagem, mas seu próprio autor ressalta que um resultado limpo não constitui garantia.

Use as duas abordagens como fontes de evidência, não como certificado de segurança.

8. Peça à hospedagem as verificações que o painel não alcança

Solicite:

• preservação dos logs de acesso e erro;
• relação de arquivos PHP criados ou alterados desde 17 de julho;
• inspeção de wp-content/mu-plugins, uploads, cache e diretórios fora da instalação;
• verificação de tarefas agendadas e processos;
• revisão de .htaccess, .user.ini e wp-config.php;
• comparação de integridade dos arquivos;
• rotação de credenciais e chaves.

Quando chamar um profissional

Procure apoio especializado se houver administrador desconhecido, plugin ou arquivo malicioso, alteração recorrente após restauração, redirecionamento, indisponibilidade generalizada ou qualquer dúvida sobre a abrangência da limpeza.

O mesmo vale quando o site sustenta vendas, armazena dados de clientes ou está integrado a outros sistemas. Nesses cenários, não basta remover o sintoma visível: é necessário delimitar o período do incidente, o que pode ter sido acessado e quais credenciais precisam ser substituídas.

Se houver possibilidade de envolvimento de dados pessoais, o controlador deve avaliar também as obrigações previstas na LGPD. Segundo a orientação da ANPD, a mera existência da vulnerabilidade não é um incidente; uma exploração confirmada que envolva dados pessoais e possa causar risco ou dano relevante pode exigir comunicação à ANPD e aos titulares. Essa análise deve ser conduzida pelo responsável da organização, com apoio jurídico ou do encarregado de dados quando necessário.

Na OWN, tratamos WordPress como infraestrutura de negócio. Nosso serviço de recuperação e manutenção WordPress parte do diagnóstico da causa e da persistência, não apenas da remoção do arquivo visível. Também documentamos nossa metodologia de manutenção WordPress e mantemos um guia mais amplo sobre o que fazer quando um site WordPress foi hackeado.

O que fica de aprendizado

Houve fatores positivos: divulgação responsável, correções coordenadas e atualização automática forçada para muitas instalações. Ao mesmo tempo, exploits públicos e ataques reais surgiram rapidamente. Isso deixou uma janela curta entre a correção e a exploração em massa.

Por isso, o episódio não deve ser resumido como falha de quem “não cuidou do site”. Mesmo uma operação atenta podia estar exposta antes do lançamento da correção. A diferença prática esteve na capacidade de confirmar a atualização, detectar sinais, preservar evidências e recuperar o ambiente com método.

Se você chegou aqui por causa de um usuário ou plugin que apareceu sem explicação, comece pela versão do WordPress e pelos administradores. Se encontrar um sinal forte, trate o caso como incidente: contenha, preserve e investigue.

Perguntas frequentes sobre wp2shell

O que é o wp2shell?

O wp2shell é uma cadeia de duas vulnerabilidades no núcleo do WordPress, identificadas como CVE-2026-63030 e CVE-2026-60137. Quando combinadas em versões afetadas, elas permitiam que um atacante sem login chegasse à execução de código no servidor.

Quais versões do WordPress foram afetadas?

A cadeia completa de execução remota afetou o WordPress 6.9.0 a 6.9.4 e 7.0.0 a 7.0.1, corrigidos nas versões 6.9.5 e 7.0.2. As versões 6.8.0 a 6.8.5 continham a injeção SQL isolada e foram corrigidas na 6.8.6. Versões anteriores à 6.8 não foram afetadas por essas duas vulnerabilidades.

Um administrador com prefixo wp2_ confirma a invasão?

É um indicador forte quando ninguém reconhece a conta, pois exploits públicos usaram prefixos como wp2_ e w2s_ e e-mails terminados em @wp2shell.invalid. Ainda assim, a confirmação deve combinar usuários, arquivos, banco de dados, logs e cronologia. A ausência desse padrão também não prova que o site esteja limpo.

Um erro 403 significa que o wp2shell teve sucesso?

Não. Um erro 403 pode ser causado por código malicioso, mas também pode indicar que um firewall ou plugin de segurança bloqueou a tentativa. Ele deve ser analisado junto com outros sinais e não confirma, sozinho, uma invasão.

Atualizar o WordPress remove o malware?

Não. A atualização fecha as vulnerabilidades, mas não remove usuários, webshells, plugins, tarefas agendadas, sessões ou alterações no banco deixadas antes da correção. Um site exposto antes da atualização precisa ser verificado.

O verificador do wp2shell.com confirma que o site está limpo?

Não. O verificador ajuda a identificar se a versão exposta parece vulnerável. Ele não realiza uma investigação forense e não determina se o site foi comprometido antes de receber a atualização.

É possível limpar o site usando apenas o wp-admin?

O painel permite atualizar o WordPress, revisar usuários, plugins e senhas de aplicação e executar verificações iniciais. Porém, ele não alcança todos os arquivos, logs, processos, tarefas do servidor ou alterações externas à instalação. Diante de sinais fortes, envolva a hospedagem ou um profissional de resposta a incidentes.

Preciso comunicar o incidente à ANPD?

Nem toda vulnerabilidade ou tentativa bloqueada precisa ser comunicada. O controlador deve avaliar a comunicação quando houver incidente confirmado envolvendo dados pessoais que possa causar risco ou dano relevante aos titulares. A ANPD informa prazo de três dias úteis para os casos que preencham esses critérios, ressalvada legislação específica.

Fontes e referências

• WordPress 7.0.2 Security Release
• Searchlight Cyber: wp2shell — Pre Authentication RCE in WordPress Core
• Searchlight Cyber: análise técnica da descoberta
• Patchstack: Unauthenticated SQL Injection in WordPress Core Fixed in 7.0.2
• Wiz Research: Exploitation in the Wild of wp2shell
• Eye Security: wp2shell incident response guide
• WordPress.org: Compromise Scanner for wp2shell
• WordPress.org: Application Passwords
• ANPD: Comunicação de Incidente de Segurança

Publicado em 24 de julho de 2026. Última atualização: 24 de julho de 2026.