WordPress Invadido: o Que Fazer nas Primeiras 24 Horas

Descobrir que o WordPress invadido é o seu costuma acontecer do pior jeito: um cliente liga dizendo que o site abre uma página de cassino, o Google exibe "este site pode ter sido invadido" ou a hospedagem suspende a conta sem aviso. As próximas 24 horas decidem se o estrago fica num susto de um dia ou vira semanas de reinfecção, perda de ranking e um incidente de LGPD mal documentado. Este é o plano que eu sigo, hora a hora.

TL;DR

• Não apague nada na primeira hora. Documente, tire um snapshot do servidor e só então comece a mexer. Evidência destruída é porta de entrada que você nunca vai achar.
• Contenha antes de limpar: troque todas as senhas (painel, banco, SFTP/SSH, hospedagem, e-mail), regenere os salts do wp-config.php e derrube as sessões ativas.
• Ache a porta de entrada. Em 2025, 91% das vulnerabilidades novas do ecossistema WordPress estavam em plugins, segundo a Patchstack. Limpar sem fechar a porta garante a reinfecção.
• Às vezes reconstruir sai mais barato que limpar. Core e plugins limpos a partir da fonte oficial, conteúdo importado do banco auditado.
• LGPD corre junto: se houve dado pessoal exposto, o prazo para comunicar a ANPD é de 3 dias úteis a partir do conhecimento.

Escrevo como desenvolvedor full stack e fundador da Agathas Web. Opero servidores Linux com WordPress, Laravel, Moodle e Next.js desde 2008, e boa parte dos chamados de emergência que chegam aqui começa com a mesma frase: "a gente não tem ninguém de infraestrutura". Este guia é para essa empresa — que tem site ou sistema em servidor próprio (VPS, dedicado ou cloud) e nenhum sysadmin de plantão.

Sinais de WordPress invadido: confirme antes de agir

Nem todo site lento ou fora do ar é um WordPress invadido de fato. Antes de acionar o plano de incidente, confirme. A documentação oficial do WordPress lista os sinais clássicos: o site aparece em listas de bloqueio do Google, a hospedagem desativa a conta, antivírus dos visitantes disparam alerta, surgem usuários que ninguém criou ou alguém avisa que o seu servidor está atacando outros sites.

Sinais que você vê

• Redirecionamento só para quem vem do Google ou do celular. O malware testa o referer e o user agent: o dono, que digita a URL direto no desktop, vê o site normal.
• Páginas de spam indexadas. Pesquise site:seudominio.com.br no Google. Páginas de remédio, aposta ou réplica de marca em japonês são o sintoma mais comum de SEO spam.
• Pop-up falso de "verificação do Cloudflare" pedindo para colar um comando no computador. É uma variante de ataque que usa o seu site para infectar o visitante.
• Alerta no Google Search Console, no relatório "Problemas de segurança".

Sinais que só aparecem no servidor

• Administradores novos em Usuários, muitas vezes com nome parecido com o seu.
• Arquivos .php dentro de wp-content/uploads/, onde só deveria haver imagem e PDF.
• Processo consumindo CPU alta sem tráfego que explique (minerador ou disparo de spam).
• Fila de e-mail do servidor com milhares de mensagens que ninguém enviou.

Se dois ou mais desses sinais aparecem juntos, trate como WordPress invadido e siga o relógio abaixo.

Hora 0 a 1: pare, documente e preserve a evidência

Diante de um WordPress invadido o instinto é apagar o arquivo estranho e restaurar o backup de ontem. Não faça isso ainda. Quem restaura por cima de um servidor comprometido apaga a única pista de como o invasor entrou — e o backup de ontem pode já estar infectado.

A primeira hora é de registro:

1. Anote o que viu, quando e em qual fuso horário. A própria documentação do WordPress recomenda começar por aqui: o que levou você a suspeitar, a hora exata e o que mudou recentemente (plugin novo, troca de tema, atualização).
2. Tire um snapshot do servidor inteiro — disco e banco — pelo painel do provedor de cloud. Na AWS, Hetzner ou DigitalOcean isso leva minutos e custa centavos por GB.
3. Copie os logs para fora do servidor: access.log e error.log do Apache ou Nginx, auth.log do SSH e o log do PHP-FPM. Logs costumam ser rotacionados em poucos dias; se o invasor tiver acesso root, podem ser apagados.
4. Exporte a lista de usuários do WordPress com data de criação.

Quando não seguir este passo

Se o site está ativamente distribuindo malware para visitantes ou disparando spam em massa, a contenção vem antes da documentação completa. Tire o snapshot (5 minutos) e já vá para a hora 1. O resto você reconstrói a partir do snapshot.

Hora 1 a 4: conter o ataque antes de limpar

No WordPress invadido, conter significa impedir que o invasor continue lá dentro enquanto você investiga. A ordem importa.

Tire o site do ar para o público, não para você

Coloque uma página de manutenção no servidor web (regra no Nginx/Apache ou no Cloudflare), liberando apenas o seu IP. Visitante não deve continuar sendo infectado, e o Google não deve continuar indexando spam.

Troque todas as credenciais — todas mesmo

Credencial	Por que trocar	Armadilha comum
Senhas de todos os administradores do WP	Acesso direto ao painel	Trocar só a sua e esquecer a do ex-funcionário
Usuário e senha do banco de dados	Estão em texto puro no wp-config.php	Esquecer de atualizar o wp-config.php e derrubar o site
SFTP / SSH / chaves SSH autorizadas	Acesso direto aos arquivos	Não revisar o ~/.ssh/authorized_keys
Painel da hospedagem ou do provedor cloud	Controla tudo, inclusive backups	Conta sem MFA
E-mail do administrador	Permite reset de senha do WP	Trocar a senha do WP e deixar o e-mail comprometido
Chaves de API (pagamento, SMTP, WhatsApp)	Podem ter vazado junto	Esquecer tokens gravados em wp_options

Derrube as sessões ativas

Gere novos salts em https://api.wordpress.org/secret-key/1.1/salt/ e substitua no wp-config.php. Isso invalida todos os cookies de login na hora, inclusive o do invasor.

Feche a porta dos fundos mais óbvia

Adicione define( 'DISALLOW_FILE_EDIT', true ); ao wp-config.php. É a recomendação oficial de hardening do WordPress e impede que alguém com acesso ao painel edite código de plugin ou tema pelo navegador.

Hora 4 a 12: encontre a porta de entrada

Esta é a etapa que separa a recuperação de um WordPress invadido de uma faxina cosmética. O relatório State of WordPress Security in 2026, da Patchstack, dá o tamanho do problema: 11.334 vulnerabilidades novas em 2025 (alta de 42%), 91% em plugins, 9% em temas e apenas 6 no núcleo do WordPress — todas de baixa prioridade. Ou seja: a porta quase nunca é o WordPress em si.

Compare os arquivos com a fonte oficial

Com WP-CLI instalado no servidor, dois comandos resolvem metade da investigação:

• wp core verify-checksums compara cada arquivo do núcleo com os checksums publicados pelo WordPress.org e lista o que foi alterado.
• wp plugin verify-checksums --all faz o mesmo para os plugins do repositório oficial.

Os dois rodam sem carregar o WordPress, o que evita executar código malicioso durante a verificação. Plugins premium e temas comprados não têm checksum público — e é justamente onde mora o risco: a Patchstack contou 3 vezes mais vulnerabilidades exploradas ativamente em componentes premium do que nos gratuitos.

Onde o invasor costuma se esconder

• wp-content/mu-plugins/: plugins que carregam sempre e não aparecem na lista comum.
• wp-content/uploads/: qualquer .php aqui é suspeito.
• Tabela wp_options: scripts injetados em siteurl, home ou em widgets.
• Tabela wp_users e wp_usermeta: admins criados pelo invasor.
• Cron do sistema (crontab -l de cada usuário) e cron do WordPress: tarefas que recriam o malware depois da limpeza.
• .htaccess em subpastas, com regras de redirecionamento condicional.

Cruze com os logs

Com os arquivos alterados em mãos, procure no access.log as requisições POST para eles, próximas da data de modificação. Normalmente a trilha leva a um plugin específico, a um formulário de upload ou a um login por força bruta. Sem essa resposta, não avance para a limpeza.

Hora 12 a 24: limpar, reconstruir ou restaurar?

Com a porta de entrada identificada, você escolhe a estratégia para o WordPress invadido em questão. A tabela abaixo é a régua que uso na prática.

Situação	Estratégia	Por quê
Poucos arquivos alterados, porta identificada, sem acesso root do invasor	Limpar no lugar	Mais rápido, preserva ajustes do ambiente
Dezenas de arquivos alterados ou malware em vários plugins	Reconstruir a instalação	Mais seguro que caçar arquivo por arquivo
Backup comprovadamente anterior à invasão, e porta identificada	Restaurar e corrigir a vulnerabilidade	Rápido, mas só se você sabe a data do comprometimento
Indício de acesso root, chave SSH desconhecida, binário alterado	Servidor novo	Não dá para confiar no sistema operacional

Como reconstruir sem levar o malware junto

1. Suba um servidor ou diretório limpo.
2. Baixe núcleo, plugins e temas da fonte oficial, nunca da pasta infectada.
3. Copie apenas wp-content/uploads/ depois de remover todo arquivo executável.
4. Importe o banco auditado (usuários, opções e conteúdo revisados).
5. Aplique a correção da porta de entrada antes de abrir o site ao público.

A armadilha do backup

Restaurar só funciona se o backup é anterior à invasão — e a invasão quase sempre é anterior ao sintoma. É comum o malware ficar dormente por dias ou semanas antes de ativar o redirecionamento. É por isso que backup sem histórico longo e sem teste de restauração não protege quase nada; escrevi sobre essa rotina em backup com restauração testada, e a lógica vale para qualquer sistema.

Evitar reinfecção: o que muda depois do incidente

A pior notícia sobre um WordPress invadido é que ele costuma ser invadido de novo pela mesma porta. Segundo a Patchstack, a mediana ponderada até a primeira exploração em massa de uma vulnerabilidade muito explorada foi de 5 horas após a divulgação, e 46% das vulnerabilidades não tinham correção disponível na data em que vieram a público. Atualizar "quando der" não é mais política de segurança.

Hardening mínimo, direto da documentação oficial

• Permissões: diretórios em 755, arquivos em 644, wp-config.php em 440 ou 400.
• Banco de dados: o usuário do WordPress só precisa de SELECT, INSERT, UPDATE e DELETE no dia a dia. Tire DROP, ALTER e GRANT.
• Edição de arquivos pelo painel desativada (DISALLOW_FILE_EDIT).
• Autenticação em dois fatores para todos os administradores.

O que a documentação não diz, mas a operação ensina

• Plugin pirata ("nulled") é a porta de entrada mais barata que existe. Remova, mesmo que o incidente não tenha vindo dele.
• Plugin abandonado há mais de um ano sai do ar ou ganha substituto.
• WAF na borda. A mesma pesquisa da Patchstack testou defesas tradicionais de hospedagem e viu que elas barraram só 26% dos ataques específicos de WordPress. Um firewall de aplicação com regras específicas contra WordPress invadido por exploração em massa (Cloudflare, por exemplo) muda essa conta.
• Monitoramento de integridade: agende o verify-checksums e alerte quando algo mudar.
• Atualização com staging: testar em cópia antes de aplicar em produção evita a desculpa clássica de "não atualizo porque quebra".

LGPD e Google: os prazos que correm junto com a limpeza

Enquanto você limpa o WordPress invadido no servidor, dois relógios externos estão contando.

ANPD: 3 dias úteis

Se a invasão atingiu dados pessoais — cadastro de clientes, formulários, pedidos de WooCommerce, lista de alunos — a Resolução CD/ANPD nº 15/2024 obriga o controlador a comunicar a ANPD em 3 dias úteis a partir do momento em que soube que o incidente afetou dados pessoais. As informações podem ser complementadas, de forma fundamentada, em até 20 dias úteis. Incidente descoberto numa sexta-feira vence na quarta seguinte.

Aqui a documentação da hora 0 do WordPress invadido vira prova: quais dados, quantos titulares, quais medidas foram tomadas. Sem log e sem snapshot, você comunica no escuro. Se o assunto é novo na sua empresa, vale ler o que já escrevi sobre vazamento de dados e como evitar e o que o caso Dígitro ensinou às empresas.

Google: dias ou semanas

Depois de limpar o WordPress invadido e confirmar que nada restou, peça revisão no relatório "Problemas de segurança" do Search Console. Pela documentação do Google, revisões de malware levam alguns dias; as de spam por invasão podem levar várias semanas. Pedir revisão antes de a limpeza estar completa só prolonga o aviso vermelho nos resultados de busca.

Quanto custa e quando não fazer sozinho

O custo real de um WordPress invadido raramente é a limpeza. É a soma de tráfego perdido enquanto o Google exibe o alerta, vendas que não entraram, horas da equipe e, se houve dado pessoal, exposição regulatória.

Dá para tratar o WordPress invadido sozinho quando

• Você tem acesso SSH e sabe usar WP-CLI.
• O site é institucional, sem cadastro de clientes nem pagamento.
• Há backup antigo e testado.
• A porta de entrada ficou clara na análise de logs.

Não trate o WordPress invadido sozinho quando

• O site coleta dados pessoais ou processa pagamento (LGPD entra em jogo).
• Há sinais de acesso root, processos estranhos ou chaves SSH desconhecidas.
• É a segunda invasão em poucos meses — a porta não foi fechada da primeira vez.
• O WordPress divide servidor com outro sistema (ERP, Moodle, API do WhatsApp). O invasor pode ter pulado de um para o outro.

Nesse último caso, a pergunta deixa de ser "como limpar o site" e vira "o que mais esse servidor expõe". É exatamente o tipo de diagnóstico que fazemos na consultoria de segurança da Agathas Web.

Como a Agathas Web resolve isso

Na Agathas Web o trabalho acontece em duas frentes, e você escolhe qual precisa.

Consultoria: diagnóstico e plano de incidente

A consultoria em TI e segurança é o caminho para quem teve um WordPress invadido e precisa entender o que aconteceu e garantir que não se repita:

• Conversa inicial gratuita (30 a 60 minutos) para entender o cenário, a stack e o que já foi feito. Se o incidente está em andamento, diga isso na primeira mensagem.
• Auditoria de segurança e LGPD em 2 a 3 semanas: OWASP Top 10 e ASVS aplicados a código, infraestrutura e API, política de acessos, criptografia, plano de incidente documentado e mapeamento LGPD, com entrega pronta para auditor externo. Investimento de R$ 6 a 12 mil, com orçamento fechado depois da conversa inicial.
• Análise de causa raiz (Five Whys e Fishbone) para incidentes recorrentes — a gente não trata sintoma.
• NDA assinado antes do acesso, com acesso read-only que você pode revogar a qualquer momento.
• CTO as a Service (8 a 40 horas por mês) se a empresa quer alguém sênior acompanhando decisões de infraestrutura daqui em diante.

Você sai com o relatório e decide se implementa com a gente, com outro fornecedor ou com o time interno.

Sustentação contínua: para não depender de sorte

Se o problema de fundo é não ter ninguém cuidando do servidor, a hospedagem gerenciada cobre a operação: WAF Cloudflare, fail2ban e hardening do sistema, backup diário e incremental com criptografia AES-256 e restauração testada todo mês, patch crítico aplicado em até 72 horas após o CVE público e SLA contratual de resposta em até 15 minutos para incidente crítico. Um dos casos que recebemos foi de uma plataforma corporativa atacada por ransomware com o fornecedor anterior: restauramos tudo em 6 horas, reconstruímos a infraestrutura do zero e treinamos a equipe em hardening.

Para contratar, o caminho é o mesmo nas duas frentes: fale com a gente pela página de consultoria e conte o que está acontecendo.

Conclusão: o relógio começa quando você descobre

Um WordPress invadido não se resolve com um plugin de segurança instalado às pressas. Resolve-se com ordem: documentar antes de apagar, conter antes de limpar, achar a porta antes de reconstruir e fechar a porta antes de reabrir o site. Pular etapa é a receita da reinfecção.

Se você está lendo isto com o WordPress invadido e o site fora do ar, siga o plano da hora 0. Se está lendo por precaução, use o hardening da seção de reinfecção como checklist ainda esta semana. E se a empresa não tem quem faça nenhuma das duas coisas, agende a conversa inicial da consultoria — é gratuita, e a gente sai dela com um escopo claro do que o seu servidor precisa.