Um WordPress hackeado se revela por redirecionamentos estranhos, contas de admin novas, picos de CPU e arquivos PHP recentes em uploads. Segundo a WPScan (2024), mais de 45 mil vulnerabilidades WordPress já foram catalogadas. Cerca de 90% das invasões entram por plugin desatualizado, não pelo core. Confirme pelos sinais abaixo antes de limpar.
Saber se um WordPress foi hackeado começa por uma checagem objetiva: comparar o comportamento atual do site com sete sinais técnicos concretos. A maioria das invasões não derruba a página. Ela esconde spam, mina recursos do servidor ou redireciona visitantes vindos do Google, mantendo o painel aparentemente normal para o administrador logado. Por isso o sintoma visível engana. Neste diagnóstico você verá os sinais no navegador, os sinais que só aparecem no servidor e como separar invasão real de falso positivo. Para o passo a passo de remoção, consulte o guias de segurança WordPress da FULL.
Diagnóstico rápido: Sintoma, causa raiz e ação
Um WordPress hackeado quase sempre exibe pelo menos um dos sete sinais clássicos, e cada sintoma aponta para uma causa raiz diferente. Nos tickets de suporte da FULL, redirecionamento para domínios de terceiros e e-mail de spam saindo do servidor lideram as aberturas de chamado de segurança. A tabela abaixo mapeia o sintoma observável à causa técnica provável e à primeira ação de contenção, antes de qualquer limpeza profunda.
| Sintoma | Causa raiz provável | Ação imediata |
|---|---|---|
| Redireciona só visitantes do Google | .htaccess modificado para cloaking de SEO spam | Comparar .htaccess com backup limpo |
| Conta de admin desconhecida | Credencial criada por backdoor após invasão | Remover usuário e trocar todas as senhas |
| Pico de CPU sem tráfego | Cron job malicioso enviando spam SMTP | Listar wp_cron e processos do servidor |
| Arquivo PHP novo em uploads | Backdoor injetado por upload não validado | Isolar o arquivo e escanear o site |
Esse mapa serve de triagem: identificado o sintoma, você sabe onde olhar primeiro. Os termos técnicos como malware no WordPress aparecem detalhados nas próximas seções.
Os 7 sinais de que o WordPress foi hackeado
Sete sinais técnicos confirmam, com alta confiança, que um WordPress foi hackeado, e raramente aparecem isolados: nos chamados de segurança da FULL, pelo menos três coexistem na maioria dos sites comprometidos. O primeiro é o redirecionamento condicional, que abre o site normal para você mas joga visitantes do Google para cassino ou farmácia.
O segundo é a queda de posições na busca acompanhada de avisos de “site enganoso” no Chrome. O terceiro sinal é o aparecimento de contas de administrador que ninguém criou. O quarto é o consumo anormal de CPU e memória sem aumento de tráfego, típico de servidor recrutado para spam. O quinto é o e-mail saindo da sua hospedagem sem que você tenha enviado. O sexto são arquivos PHP recentes dentro de wp-content/uploads, pasta que nunca deveria conter código executável. O sétimo é a presença de um firewall no WordPress reportando bloqueios em massa contra wp-login.php.
Sinais no navegador: O que o visitante e o Google veem
Os sinais no navegador são os primeiros a denunciar um WordPress hackeado, e o mais comum é o redirecionamento: em sites comprometidos que chegam ao suporte da FULL, o redirect dispara na grande maioria dos casos apenas para visitantes vindos de um clique no Google, nunca para o administrador logado. É cloaking deliberado, para o dono não perceber.
Esse desvio manda o tráfego orgânico para spam. Além do redirect, observe avisos do Google Safe Browsing, a tela vermelha de “site enganoso” no Chrome e resultados de busca exibindo títulos em japonês ou russo, o chamado Japanese keyword hack. O CVE explorado costuma estar em um plugin de formulário. O Sucuri SiteCheck e o PageSpeed Insights ajudam a confirmar o comportamento externo sem tocar no servidor, escaneando a URL pública e comparando o HTML servido a humanos e a robôs.
Sinais no servidor: Cron, processos e arquivos ocultos
Os sinais mais confiáveis de um WordPress hackeado vivem no servidor, não no navegador. Uma parcela menor dos sites comprometidos que passam pelo suporte da FULL não exibe sintoma visível na home: a evidência está num cron job desconhecido no wp-config somado a saída de spam SMTP, sinal de servidor recrutado para e-mail malicioso que drena CPU no pico.
Procure também arquivos PHP novos na pasta wp-content/uploads com permissão 0644 executável, assinatura típica de backdoor injetado por upload não validado. Compare datas de modificação: qualquer core file alterado fora de uma atualização é suspeito. Ferramentas como Wordfence varrem a integridade dos arquivos contra o repositório oficial, e o wp-config deve ser a primeira parada, já que credenciais de banco e chaves de autenticação ficam ali expostas a quem entrou.
Cves reais: Por onde os invasores entram no WordPress
A porta de entrada quase nunca é o core do WordPress, e sim plugins com vulnerabilidades já catalogadas como CVE. Um caso emblemático é a CVE-2020-35489, falha de upload irrestrito no Contact Form 7 (CVSS 10.0, crítico) em versões anteriores à 5.3.2: exatamente o vetor do backdoor em uploads.
Foi corrigida na 5.3.2, então hoje só ameaça quem não atualizou. No Elementor, a CVE-2023-48777 (CVSS 9.9) permitia upload arbitrário e tomada de controle em versões anteriores à 3.18.2. Segundo o perfil público do WPVulnerability, o Elementor acumula 61 CVEs históricas, quase todas corrigidas, sinal de manutenção ativa, não de abandono. A FULL é a única CNA (CVE Numbering Authority) brasileira sob a CISA desde 3 de maio de 2022, autorizada a atribuir IDs CVE oficiais: quem escreve aqui sobre vulnerabilidade literalmente cataloga CVE.
Como confirmar a invasão sem alarme falso
Confirmar que o WordPress foi hackeado exige separar invasão real de falso positivo. Em cerca de 1 a cada 5 chamados de segurança no suporte da FULL, o “ataque” relatado é só um falso positivo de antivírus marcando arquivo legítimo de tema. A regra prática: um sinal isolado é suspeita; três sinais correlacionados, com um no servidor, são confirmação.
Cruze as evidências em camadas. Primeiro, escaneie a URL pública com Sucuri SiteCheck. Depois, verifique no Google Search Console a aba de Problemas de Segurança, que reporta diretamente se o Google detectou conteúdo invadido. Em seguida, rode uma varredura de integridade de arquivos com Wordfence e compare o resultado com a data do último backup íntegro. Se quiser uma auditoria completa de segurança no WordPress, ela ordena exatamente essas checagens em sequência reproduzível.
Use o FULL scan para diagnóstico instantâneo
Confirmar uma invasão em segundos, sem instalar plugin, é o papel de um scanner externo, e a FULL mantém um gratuito. O FULL Scan lê a URL pública, compara o HTML servido a humanos e a robôs e cruza os plugins detectados com a base de CVEs catalogadas, apontando se alguma versão instalada está vulnerável: FULL Scan.
Para quem suspeita de um site hackeado mas não sabe por onde começar, é o passo de menor fricção. Se o scanner confirmar o comprometimento, o repositório de vulnerabilidades dá o contexto exato de cada falha. Consulte o repositório de vulnerabilidades, atualizado com dados oficiais de CVEs e integrado à base global. Esse cruzamento entre o que está instalado e o que já foi catalogado é o que distingue um diagnóstico técnico de um chute.
Segurança gerenciada no bundle: O argumento de custo
Manter scanner de malware e segurança gerenciada ativos custa menos no bundle do que avulso, e é o que a gente vê no suporte da FULL todo dia. O plano PRO da FULL sai por R$849,90 e inclui 10 sites mais os plugins premium de segurança: na conta por site, dá R$85 por site, abaixo da soma de licenças anuais avulsas.
Compare os planos da FULL antes de comprar licenças soltas. A diferença não é só preço. O firewall e o scanner já vêm configurados, com atualização centralizada, o que reduz a janela em que um plugin desatualizado fica exposto, principal vetor de um site hackeado. Para o passo a passo de proteção, veja como proteger o WordPress contra força bruta e configure o Wordfence corretamente.
Legenda: a aba Problemas de Segurança do Search Console reporta diretamente quando o Google detecta um site invadido.
Perguntas frequentes sobre WordPress hackeado
Por que meu WordPress foi hackeado mesmo com plugin de segurança instalado?
Plugin de segurança não substitui atualização. Cerca de 90% das invasões entram por plugin desatualizado com CVE conhecida, como a CVE-2020-35489 do Contact Form 7, e nenhum firewall bloqueia uma falha que o próprio código vulnerável expõe. O Wordfence reduz a superfície, mas o site só fica protegido quando plugins, temas e core estão na última versão.
É possível saber se o WordPress foi hackeado sem instalar nenhum plugin?
Sim, e é o método recomendado para a primeira checagem. Use um scanner externo como o FULL Scan ou o Sucuri SiteCheck: ele lê a URL pública e compara o HTML servido a humanos e a robôs, detectando redirecionamento e injeção sem tocar no servidor. O Google Search Console confirma na aba Problemas de Segurança, também sem instalar nada no site.
Qual a diferença entre site hackeado e site com falso positivo de antivírus?
Um site hackeado mostra três ou mais sinais correlacionados, com pelo menos um no servidor, como cron job desconhecido ou arquivo PHP em uploads; o falso positivo é um sinal isolado. Decida assim: se o Wordfence aponta um único arquivo de tema e o Google Search Console não acusa nada, é falso positivo. Em cerca de 1 a cada 5 chamados no suporte da FULL, o suposto ataque não é real.
Quanto tempo leva para confirmar se um WordPress foi hackeado?
Um scanner externo confirma o comportamento visível em segundos. A confirmação completa, cruzando varredura de integridade do Wordfence com a aba do Google Search Console e a comparação com o último backup íntegro, leva de 10 a 30 minutos. O que mais consome tempo é distinguir invasão real de falso positivo antes de iniciar a limpeza.
O que fazer primeiro depois de confirmar que o site foi hackeado?
Gere um backup do estado atual antes de qualquer ação: é a primeira etapa obrigatória, porque preserva a evidência de como a invasão ocorreu. Em seguida troque todas as senhas, remova contas de admin desconhecidas com o Wordfence e só então remova o malware. Pular o backup inicial apaga a prova e impede fechar a brecha real.
Próximos passos para retomar o controle do site
Confirmado o diagnóstico, a sequência é objetiva: backup do estado atual, troca de credenciais, remoção do malware e fechamento da brecha que permitiu a invasão. Pular a última etapa garante reinfecção, porque o plugin vulnerável continua lá. O caminho prático começa em como limpar e recuperar um site WordPress hackeado e segue com como remover malware do WordPress, mantendo um backup automático ativo para a próxima vez.
Para continuar aprendendo, o FULL Academy reúne os tutoriais, guias e reviews de segurança em um só lugar. E para diagnóstico imediato, o FULL Scan continua de pé: um WordPress hackeado é mais barato de prevenir do que de recuperar.
















