O WordPress é a espinha dorsal de mais de 40% de toda a internet. De blogs pessoais a portais governamentais, ele é o motor que move a web. Normalmente, quando ouvimos falar de sites invadidos, o culpado é um plugin desatualizado ou uma senha administrativa fraca. Mas o que acontece quando a falha não está em um recurso opcional, mas no próprio coração do sistema?

Recentemente, a descoberta da cadeia de exploração batizada de wp2shell, composta pelas falhas CVE-2026-63030 e CVE-2026-60137, revelou um cenário alarmante. Trata-se de uma vulnerabilidade no núcleo, ou Core, o que significa que o erro está no código básico distribuído em todas as instalações do WordPress. O perigo é extremo porque o wp2shell permite o que chamamos de RCE, sigla para Execução Remota de Código: a capacidade de um invasor executar comandos no servidor e assumir o controle total do site sem possuir qualquer credencial ou depender da interação dos usuários.

Este artigo detalha como uma sofisticada cadeia de erros técnicos transformou recursos legítimos em uma arma digital, mudando as regras do jogo para a segurança cibernética global.

WordPress Core vs. plugins

Para entender a gravidade do wp2shell, é fundamental diferenciar as camadas do software. Imagine o WordPress como um edifício. O Core representa a fundação, as vigas e o sistema elétrico central. Os plugins e temas são a decoração, os móveis e os aparelhos eletrônicos adicionados pelos moradores.

Historicamente, a maioria das invasões ocorre por falhas nesses recursos adicionais, principalmente em plugins desenvolvidos por terceiros. O wp2shell, no entanto, atinge o edifício em sua estrutura básica.

• Impacto universal: Por estar no núcleo, a vulnerabilidade afeta instalações padrão, independentemente dos plugins que o proprietário do site tenha instalado.
• Ataque sem pré-requisitos: O invasor não precisa que o administrador cometa um erro de configuração ou instale algo malicioso, pois a falha está presente por padrão.
• Perigo invisível: Diferentemente de ataques direcionados a plugins específicos, o wp2shell atinge o mecanismo que processa cada solicitação feita ao site, tornando-o um alvo lucrativo para ataques automatizados em massa.

Onde o erro começa

A porta de entrada dessa ameaça é o batch REST endpoint, localizado em /wp-json/batch/v1. Esse recurso permite que um desenvolvedor envie várias solicitações ao site em um único pacote, ou lote, economizando tempo e processamento. Internamente, o WordPress organiza essas solicitações em filas paralelas, chamadas de arrays: uma para o conteúdo da solicitação e outra para as permissões de quem a enviou.

O erro crítico surgiu na forma como o sistema gerenciava essas filas quando uma das solicitações do lote falhava. Se a segunda solicitação de uma lista de três apresentasse um erro, o WordPress a removia da lista de execução, mas deixava de removê-la da lista de autorizações. Isso provocava um desalinhamento: a terceira solicitação acabava herdando a autorização que pertencia à segunda.

Analogia: Imagine uma fila de restaurante na qual cada cliente recebe uma nota fiscal para pagamento. Se o cliente número 2 sair da fila por causa de um erro, mas o sistema de notas fiscais não for atualizado, o cliente número 3 receberá a conta e as permissões de acesso que pertenciam ao cliente número 2.

Como consequência, todo o conjunto de manipuladores se desloca, permitindo que uma solicitação não verificada alcance destinos para os quais nunca foi validada.

O ataque de injeção de SQL

Depois que a confusão de rotas permite que uma solicitação ultrapasse a barreira de segurança, o invasor direciona o ataque ao banco de dados por meio do componente WP_Query. O objetivo é realizar uma injeção de SQL, ou SQL Injection, que ocorre quando comandos maliciosos são inseridos em campos nos quais o sistema esperava receber apenas dados comuns.

O ponto específico da falha está no parâmetro author__not_in. O sistema espera que esse campo receba uma lista de números, ou seja, um array. Por causa de uma falha conhecida como type juggling, ou confusão de tipos de dados, o WordPress somente limpa e sanitiza as informações quando elas chegam no formato de lista. Se o invasor enviar o dado como um texto simples, uma string ou um valor escalar, o mecanismo de limpeza array_map('absint') será ignorado.

Com essa proteção desativada, o texto malicioso enviado pelo invasor permanece intacto e é inserido diretamente na consulta SQL que o site envia ao banco de dados. Essa é a chave que abre a porta para a manipulação das informações mais importantes do sistema.

O truque de mestre, criando um administrador do nada

A parte mais engenhosa do wp2shell está na forma como ele transforma a manipulação do banco de dados em controle administrativo. O processo utiliza a hidratação de objetos: o invasor usa a injeção de SQL para forjar dados na memória, convencendo o WordPress de que publicações e configurações falsas são legítimas.

Para consolidar o ataque, os invasores abusam do recurso oEmbed, utilizado para incorporar vídeos e outros conteúdos. Eles empregam códigos como [embed][/embed] para criar entradas de cache com identificadores previsíveis, gerados por meio de um cálculo de hash MD5.

O golpe final ocorre por meio de salvamentos aninhados. O invasor inicia um processo de salvamento pelo Customizer que, por um breve instante, define o contexto do sistema como pertencente a um administrador. Enquanto esse contexto de alto privilégio permanece ativo, o ataque aciona uma segunda tarefa técnica, que carrega a API REST por meio de parse_request. Como o sistema acredita que um administrador está executando a ação, ele aceita a criação de uma nova conta de usuário com privilégios totais, sem exigir uma autenticação válida.

Trata-se de uma cadeia de exploração técnica altamente complexa, na qual cada pequeno erro de lógica é combinado para derrubar todas as defesas do sistema.

Nota técnica: Sites que utilizam sistemas externos de cache, como Redis ou Memcached, possuem um caminho de gravação diferente, o que pode limitar a execução de código. Ainda assim, eles permanecem vulneráveis ao roubo de dados por meio de SQL Injection.

O perigo para o visitante comum

O impacto do wp2shell vai muito além do proprietário do site, pois também atinge diretamente quem navega pela internet. Depois que o invasor cria uma conta administrativa, o site legítimo transforma-se em uma fachada para atividades criminosas.

Os riscos para os visitantes incluem:

• Roubo de credenciais: O invasor pode inserir telas falsas de login, semelhantes às do Google ou do Microsoft 365, sobre o conteúdo real para capturar nomes de usuário e senhas dos visitantes.
• Distribuição de malware: O site pode ser configurado para forçar o download de vírus ou explorar falhas no navegador do usuário de forma invisível.
• Golpes de redirecionamento: Ao clicar em um link comum, o visitante pode ser levado a páginas de fraudes financeiras, falsos serviços de suporte técnico ou sorteios inexistentes.

O perigo está no fato de que o usuário confia no endereço acessado, sem saber que o mecanismo daquele site foi sequestrado.

Como se proteger

A segurança cibernética exige rapidez. Se você administra um site em WordPress, siga estes passos imediatamente:

1. Atualização de segurança: Verifique se o WordPress foi atualizado para uma das versões corrigidas: 6.9.5, 7.0.2 ou 6.8.6. Não confie cegamente na atualização automática. Confirme manualmente a versão instalada no painel administrativo.
2. Bloqueio preventivo com WAF: Caso não seja possível atualizar imediatamente, utilize um firewall de aplicação web para bloquear o acesso ao endpoint de lote. É essencial bloquear tanto o caminho direto /wp-json/batch/v1 quanto a variante que utiliza o parâmetro de consulta ?rest_route=/batch/v1.
3. Investigação de indicadores de comprometimento, ou IoCs: Mesmo depois da atualização, verifique se o site já foi comprometido. Procure por contas administrativas desconhecidas e examine as tabelas wp_posts e wp_options em busca de entradas suspeitas ou códigos incomuns.

Conclusão

O ataque wp2shell demonstra que a segurança digital não é um estado estático, mas um processo dinâmico. Ele mostrou como erros pequenos e isolados, como uma falha na organização de listas ou a aceitação de um texto em um campo que deveria receber um número, podem ser combinados para comprometer o sistema de gerenciamento de conteúdo mais popular da web.

A principal lição é que a rapidez na resposta representa a melhor defesa. Em um mundo no qual vulnerabilidades críticas podem ser exploradas poucas horas após sua descoberta, manter os sistemas atualizados e monitorados não é apenas uma boa prática, mas uma necessidade de sobrevivência digital.

Você já verificou a saúde digital e a versão do seu WordPress hoje?

Leia também

Para aprofundar a proteção contra vulnerabilidades, invasões e falhas em plataformas digitais, confira estes conteúdos relacionados.

• Vulnerabilidades críticas no WordPress: Entenda os riscos no King Addons e ACF Extended
• MiniPlasma: como uma falha de 2020 voltou para assombrar o Windows 11
• Falha na IA da Meta permitiu invasão de contas do Instagram

Consultoria em segurança digital

Uma estratégia de segurança exige atualização, monitoramento e resposta rápida a incidentes. Para avaliar a proteção do seu ambiente digital e definir medidas adequadas, fale conosco.

Nota: Todas as imagens utilizadas neste artigo foram geradas com o auxílio de inteligência artificial por meio do ChatGPT 5.6 e Nano Banana 2, com o objetivo de ilustrar o conteúdo de forma didática e acessível aos nossos leitores.