Descobrir que uma aplicação WordPress foi comprometida é um dos cenários mais críticos para qualquer operação digital. Quando o ambiente envolve portais personalizados, áreas restritas e integrações com sistemas externos, o impacto de uma invasão não se limita à indisponibilidade de páginas: dados sensíveis de usuários e credenciais de APIs podem estar expostos. Nesses cenários, aplicar soluções paliativas, como rodar verificadores automatizados sem isolamento, raramente resolve o problema na raiz, pois backdoors residuais continuam ativos no sistema de arquivos ou no banco de dados.

A abordagem correta para restabelecer a integridade de um ambiente comprometido é a reconstrução limpa (clean rebuild), descartando arquivos suscetíveis e validando detalhadamente dados e regras de negócio.

1. Isolamento e Análise Forense Inicial

Antes de qualquer intervenção no código, o ambiente deve ser congelado para conter o avanço do ataque e evitar vazamento de dados adicionais:

1. Modo de Manutenção Forçado: Interrompa requisições públicas no nível do servidor (via Nginx ou Apache) retornando status 503 temporário.
2. Isolamento de Credenciais: Revogue acessos a bancos de dados, chaves de API, credenciais FTP/SSH e gere novos segredos em wp-config.php (AUTHKEY, SECUREAUTHKEY, LOGGEDINKEY, NONCEKEY, etc.).
3. Backup Forense: Crie uma cópia exata do ambiente afetado (banco e arquivos) fora do servidor de produção para auditoria posterior de logs e vetores de entrada.

2. Estratégia de Reconstrução com WP-CLI e Zero Trust

O princípio fundamental de um rebuild seguro é nunca confiar em nenhum arquivo PHP existente no servidor antigo. O núcleo do WordPress, plugins públicos e temas padrão devem ser completamente reinstalados diretamente de suas fontes oficiais.

Com acesso via SSH, o WP-CLI acelera o processo de verificação e reconstrução:

bash

Verificação de integridade dos arquivos de núcleo

wp core verify-checksums

Verificação dos plugins instalados

wp plugin verify-checksums