Como saber se seu site WordPress foi hackeado

Existe uma diferença entre suspeitar que o site foi hackeado e ter certeza. E essa diferença importa muito, porque agir na suspeita errada pode fazer você apagar arquivos legítimos, perder dados ou deixar o problema real intacto enquanto trata o sintoma errado.

Antes de limpar qualquer coisa, antes de reinstalar qualquer plugin, antes de ligar para a hospedagem, você precisa confirmar o comprometimento por evidência técnica — não por instinto ou por um aviso que pode ser falso positivo.

Este guia é sobre exatamente isso: como identificar com precisão se o seu WordPress foi invadido, quais sinais confirmam o problema e quais são ruído, e qual o caminho correto a partir do momento em que a invasão está confirmada.

O que significa “site WordPress hackeado”

Um site WordPress hackeado é aquele em que um agente não autorizado obteve acesso à instalação — seja ao painel administrativo, aos arquivos do servidor, ao banco de dados ou a uma combinação dos três — e modificou algo sem o consentimento do proprietário.

A modificação pode ser visível (um redirecionamento para outro site, conteúdo estranho aparecendo nas páginas) ou completamente invisível para quem visita o site (um backdoor instalado para acesso futuro, um script de mineração de criptomoeda rodando em segundo plano, ou spam sendo enviado em nome do seu domínio).

O problema central de um WordPress invadido não é o que você vê. É o que você não vê.

Na maioria dos casos documentados no relatório de segurança da WPScan (base de dados com mais de 50 mil vulnerabilidades catalogadas em plugins, temas e no core do WordPress), a porta de entrada foi explorada semanas ou meses antes de qualquer sintoma aparecer. O invasor instala o que precisa e espera. O site continua funcionando normalmente para visitantes e para o proprietário — até que algo ativa o próximo passo do ataque.

Por que o WordPress é um alvo tão frequente

O WordPress alimenta cerca de 43% de todos os sites da internet, segundo dados do W3Techs (2026). Essa popularidade tem um lado negativo direto: ela torna o WordPress o alvo mais lucrativo para ataques automatizados em escala.

Bots varrem a internet continuamente buscando instalações do WordPress com versões específicas de plugins que possuem vulnerabilidades conhecidas (CVEs — Common Vulnerabilities and Exposures). Quando encontram, exploram automaticamente, sem intervenção humana. Não é um hacker escolhendo seu site: é um sistema automatizado verificando se você está na lista de vulneráveis.

Três categorias respondem pela esmagadora maioria das invasões, segundo pesquisa publicada sobre vulnerabilidades em CMS:

Plugins desatualizados são a principal porta de entrada. Vulnerabilidades em componentes extensíveis de CMS tornaram-se os vetores favoritos de ataque, conforme análise do GovCERT.HK sobre tendências de segurança cibernética. Um plugin com uma falha de SQL injection ou XSS conhecida há três semanas, sem atualização aplicada, é uma porta aberta.

Senhas fracas ou reutilizadas são o segundo vetor mais comum. Credenciais de login comprometidas em outros serviços são testadas automaticamente contra painéis WordPress. A autenticação de dois fatores — recomendação explícita do guia de Hardening WordPress da documentação oficial — elimina esse vetor quase completamente.

Temas e plugins de fontes não oficiais (chamados de “nulled” ou pirateados) carregam backdoors de fábrica. São instalados como se fossem legítimos e abrem acesso permanente ao invasor desde o primeiro dia.

Os sinais de que seu WordPress foi hackeado

Os sinais se dividem em duas categorias: os que qualquer visitante pode perceber e os que só aparecem em diagnóstico técnico. A segunda categoria é onde a maioria das invasões vive.

Sinais visíveis — o que você ou seus visitantes percebem

Redirecionamento para outro site. O visitante acessa a URL do seu site e é levado para uma página de farmácia, cassino, conteúdo adulto ou qualquer outro domínio que você não controla. Às vezes isso acontece só para visitantes que chegam pelo Google, não para você que acessa diretamente — o invasor faz isso para dificultar a detecção.

Conteúdo estranho aparecendo nas páginas. Links para sites externos injetados no rodapé, no conteúdo dos posts ou em lugares que você não editou. Páginas novas indexadas no Google com palavras-chave de spam (o chamado “pharma hack” — spam de SEO que faz seu site ranquear para termos de medicamentos ou produtos ilícitos).

Usuário administrador desconhecido no painel. Você abre a lista de usuários e vê uma conta com permissões de administrador que não foi criada por você. Esse é um dos sinais mais claros de comprometimento — o invasor criou um acesso permanente.

Impossibilidade de entrar no wp-admin. Suas credenciais estavam corretas ontem, você não alterou nada, mas hoje o login não funciona. Em alguns ataques, o invasor troca a senha do administrador depois de criar a própria conta.

Mensagem de aviso do Google Chrome. “Este site pode estar comprometido” ou “Site enganoso à frente” — sinais de que o Google já detectou conteúdo malicioso e sinalizou o site na busca e no navegador.

E-mails de spam sendo enviados pelo seu domínio. Você começa a receber respostas de e-mails que nunca enviou, ou sua hospedagem avisa que sua conta foi suspensa por envio de spam. O servidor da sua hospedagem está sendo usado para disparar mensagens em massa.

Site visivelmente mais lento sem motivo aparente. Scripts de mineração de criptomoeda ou processos maliciosos consomem CPU do servidor. O site fica lento sem qualquer alteração de conteúdo ou configuração.

Sinais técnicos — o que aparece no diagnóstico

Arquivos PHP dentro da pasta wp-content/uploads. A pasta de uploads não deveria conter arquivos PHP — ela existe para mídia (imagens, PDFs, vídeos). Qualquer arquivo .php dentro dela é suspeito por definição e provavelmente é um web shell, que dá acesso ao servidor via navegador.

Arquivos do core modificados recentemente sem atualização. Os arquivos do núcleo do WordPress (pasta wp-admin, wp-includes, e os arquivos na raiz como wp-login.php) não deveriam ser modificados em datas que não correspondem a uma atualização do WordPress. Se wp-login.php foi modificado ontem e você não atualizou o WordPress, é suspeito.

Problemas de segurança no Google Search Console. O relatório de Problemas de Segurança do Search Console lista o que o Google detectou: conteúdo hackeado, malware, engenharia social (phishing). Esse relatório é uma das fontes mais confiáveis para confirmar comprometimento — o Google está avisando que rastreou algo errado.

Alertas de blacklist em scanners externos. Seu domínio aparece em listas de sites maliciosos mantidas pela Sucuri, Google Safe Browsing, MX Toolbox ou similares.

Entradas de log com acessos a URLs que não existem. Os logs de acesso do servidor mostram requisições para arquivos como c99.php, shell.php, alfa.php — nomes comuns de web shells — mesmo que esses arquivos não estejam visíveis no gerenciador de arquivos.

Tarefa agendada desconhecida no WP-Cron. O invasor pode ter criado um cron job que recria arquivos maliciosos apagados. Se você limpar a infecção mas ela voltar em horas, esse é o mecanismo mais provável.

Como confirmar a invasão por evidência técnica

Suspeita não é diagnóstico. Antes de tomar qualquer ação, confirme por pelo menos duas fontes independentes.

Fonte 1: Google Search Console

Acesse o Search Console da sua propriedade e navegue até Segurança e ações manuais > Problemas de segurança. Se o Google detectou conteúdo hackeado, malware ou phishing, ele estará listado aqui com as URLs afetadas.

Esse relatório é importante por dois motivos: confirma o comprometimento com a autoridade do Google e já indica quais páginas foram afetadas, o que orienta a limpeza.

Se você não tem o Search Console configurado para o seu site, esta é também uma boa razão para fazê-lo. Leia sobre auditoria de SEO para entender como o Search Console se encaixa no monitoramento do site.

Fonte 2: Scanner externo

O Sucuri SiteCheck (sitecheck.sucuri.net) faz uma varredura gratuita no HTML público do seu site e cruza com bases de malware conhecidas. Não requer instalação de nada. Ele detecta injeções visíveis no código da página, redirecionamentos maliciosos e presença em blacklists.

Limitação importante: scanners externos enxergam o que o visitante vê. Backdoors em arquivos PHP do servidor, web shells na pasta uploads e injeções no banco de dados que não aparecem no frontend visível não são detectados por varredura externa.

Fonte 3: Verificação de arquivos modificados

Via painel da hospedagem, gerenciador de arquivos ou SSH, verifique quais arquivos foram modificados recentemente. O comando Unix para isso:

find /caminho-do-wordpress -name "*.php" -newer /caminho-do-wordpress/wp-config.php -type f

Esse comando lista todos os arquivos PHP modificados depois do wp-config.php. Arquivos do core modificados sem que uma atualização do WordPress tenha sido aplicada são suspeitos. Arquivos PHP em wp-content/uploads são quase sempre maliciosos.

Fonte 4: Verificação de usuários administradores

No painel do WordPress: Usuários > Todos os usuários, filtrar por “Administrador”. Qualquer conta que você não criou ou não reconhece é um sinal claro de comprometimento.

Falsos positivos: o que pode parecer invasão mas não é

Nem todo comportamento suspeito é invasão. Antes de entrar em modo de emergência, verifique:

Aviso do antivírus do visitante. Alguns antivírus bloqueiam sites com base em regras próprias, às vezes incorretas. Um visitante dizendo que seu antivírus bloqueou o site não confirma invasão — confirma que o antivírus do visitante tem uma regra que bloqueia algo no seu site, que pode ser legítimo.

Site lento por sobrecarga normal. Um pico de tráfego, um plugin de cache mal configurado ou uma hospedagem compartilhada sobrecarregada produzem lentidão sem nenhuma relação com segurança.

Redirecionamento causado por configuração incorreta. Um plugin de SEO, uma regra de .htaccess ou uma migração de HTTP para HTTPS mal feita pode causar redirecionamentos que parecem maliciosos mas têm explicação técnica simples.

Cache desatualizado. Conteúdo estranho aparecendo pode ser cache de uma versão anterior do site ou conteúdo vindo de um plugin de terceiros que você mesmo instalou.

A confirmação por duas fontes independentes — especialmente o Google Search Console e a verificação de arquivos — elimina a maioria dos falsos positivos.

O que acontece quando o site fica invadido sem que ninguém perceba

Essa é a parte que mais preocupa quem trabalha com segurança WordPress: a maioria das invasões não causa nenhum sintoma imediato visível. O invasor não quer que você perceba. Ele quer:

Usar seu servidor para enviar spam — aproveitando a reputação do seu domínio para disparar e-mails que passam pelos filtros antispam.

Usar sua posição no Google para SEO parasita — injetando páginas ocultas no seu site que ranqueiam para termos de spam, sem aparecer para você quando você visita o site normalmente.

Manter um backdoor para acesso futuro — seu site pode ser usado como ponto de entrada para atacar outros sistemas ou ficar disponível para venda em mercados de acesso inicial.

Minerar criptomoedas — usando os recursos do servidor de forma silenciosa, o que explica a lentidão sem causa aparente.

As consequências concretas de uma invasão sem detecção precoce incluem: queda no ranqueamento do Google (quando o conteúdo de spam é detectado e o site é penalizado), inclusão em blacklists de e-mail (o que compromete a entregabilidade de qualquer e-mail enviado pelo domínio), suspensão da hospedagem por uso abusivo de recursos, e perda de credibilidade com clientes que recebem avisos de segurança ao acessar o site.

Um estudo sobre vulnerabilidades em CMS desatualizados identificou que 70% dos exploits graves derivam de três categorias: XSS (Cross-Site Scripting), CSRF (Cross-Site Request Forgery) e injeção de SQL — falhas que existem em plugins desatualizados e são exploradas de forma automatizada, sem que o proprietário do site perceba nada.

O que fazer imediatamente após confirmar a invasão

A sequência importa. Fazer as coisas na ordem errada — por exemplo, reinstalar o WordPress antes de fazer backup do estado infectado — pode apagar evidências do backdoor e dificultar a limpeza completa.

Primeiro: não apague nada ainda. O instinto é deletar tudo que parece suspeito, mas o backdoor raramente está no arquivo que você encontrou primeiro. O invasor quase sempre mantém múltiplos pontos de retorno. Apagar sem diagnóstico completo resulta em reinfecção em horas.

Segundo: ative o modo de manutenção. Retire o site do ar para visitantes enquanto o problema é tratado. Isso protege quem acessaria o site comprometido e impede que o Google rastreie mais conteúdo malicioso.

Terceiro: faça backup do estado atual — mesmo infectado. O backup do estado comprometido serve como evidência forense. Comparar os arquivos infectados com uma versão limpa é o caminho mais confiável para encontrar o backdoor. Sem esse backup, você está trabalhando às cegas.

Quarto: troque todas as senhas. Painel WordPress, FTP/SFTP, banco de dados e acesso ao painel da hospedagem. Se o invasor tinha acesso via credencial comprometida, as novas senhas revogam esse acesso imediatamente.

Quinto: chame alguém com experiência. Recuperação de WordPress invadido não é um processo linear. Cada invasão tem características específicas. O erro mais caro nesse momento é fazer a limpeza de forma incompleta — o site parece limpo, o problema volta em dois dias, e o processo todo recomeça com mais dano acumulado.

Se você tem dúvida sobre a extensão do comprometimento ou não tem acesso técnico para diagnosticar adequadamente, o serviço de manutenção de site WordPress inclui diagnóstico de segurança e recuperação de sites comprometidos.

Como os principais tipos de ataque se manifestam no WordPress

Entender o mecanismo do ataque ajuda a identificar o padrão correto no diagnóstico.

Backdoor via plugin ou tema nulled. O arquivo malicioso já vem embutido. Ele cria um usuário administrador oculto ou um ponto de acesso via URL específica. Sintoma típico: usuário administrador desconhecido aparece dias ou semanas depois da instalação do tema ou plugin.

Força bruta no wp-login.php. O bot tenta combinações de usuário e senha em volume. Sintoma visível no log do servidor: centenas de requisições POST para /wp-login.php em intervalo de minutos. Pode não resultar em invasão se as senhas são fortes, mas confirma que o site está sendo atacado ativamente.

SQL injection via plugin vulnerável. Um plugin com falha de SQL injection permite que o invasor execute comandos diretamente no banco de dados do WordPress. Sintoma: dados inseridos no banco sem você ter feito nada, páginas de spam aparecendo ou configurações do site alteradas.

Cross-site scripting (XSS). Script malicioso injetado no conteúdo do site que executa no navegador dos visitantes. Sintoma: visitantes relatando comportamento estranho no site (pop-ups, redirecionamentos), ou o próprio navegador do visitante bloqueando a página.

Pharma hack. Injeção de páginas ocultas otimizadas para termos de spam. Essas páginas ficam invisíveis para você quando visita o site, mas são rastreadas pelo Google. Sintoma: aparição de URLs estranhas no Google Search Console ou usuários relatando que seu site aparece em resultados de busca para termos completamente fora do seu contexto.

Web shell em uploads. Arquivo PHP colocado na pasta de uploads que funciona como um painel de controle remoto para o invasor. Sintoma: arquivos PHP em wp-content/uploads que você não colocou lá.

Checklist: Como saber se meu site WordPress foi hackeado

Use esta lista para um diagnóstico inicial estruturado. Cada item com resposta “sim” aumenta a certeza de comprometimento.

Painel e acessos

Existem usuários administradores que você não criou?
Sua senha deixou de funcionar sem que você a alterasse?
Há plugins ou temas instalados que você não instalou?
Configurações do site foram alteradas sem você ter mexido nelas?

Comportamento do site

O site redireciona para outro domínio (principalmente via Google)?
Aparecem páginas ou posts que você não criou?
O site está visivelmente mais lento sem alteração de conteúdo?
Visitantes relatam avisos de segurança do navegador?

Google e e-mail

O Google Search Console mostra problemas de segurança?
Seu site aparece no Google com títulos ou descrições estranhas?
Você recebeu respostas de e-mails que nunca enviou?
A hospedagem notificou sobre envio de spam?

Arquivos e servidor

Existem arquivos PHP dentro de wp-content/uploads?
Arquivos do core do WordPress foram modificados recentemente sem atualização?
Os logs do servidor mostram acessos a URLs que não existem no seu site?
O scanner externo (Sucuri SiteCheck) detectou algo?

Regra prática: dois ou mais “sim” justificam diagnóstico técnico completo. Quatro ou mais “sim” indicam comprometimento com alta probabilidade.

O papel da manutenção preventiva nesse contexto

A maioria das invasões WordPress bem-sucedidas explora algo que deveria ter sido corrigido antes. Plugin desatualizado com CVE conhecido. Senha reutilizada. Usuário administrador com nome “admin”. Permissões de arquivo incorretas que permitem escrita onde não deveria.

Um processo estruturado de manutenção de site WordPress age exatamente nas camadas que os ataques automatizados exploram: mantém plugins e temas atualizados, monitora a integridade dos arquivos, gera backups verificados fora do servidor e aplica hardening que reduz a superfície de ataque.

Entender o risco concreto de um site sem manutenção não é só sobre segurança imediata — há também impacto direto em performance e SEO. Leia sobre o custo de deixar o WordPress sem manutenção e o que acontece com um site WordPress desatualizado para entender o quadro completo.

Sites que já tiveram problemas de lentidão associados podem ter uma conexão com a hospedagem. Se você identificou que o site estava lento antes de perceber a invasão, leia também sobre e-commerce lento por hospedagem — nem sempre o problema é segurança, mas os sintomas se sobrepõem.

Perguntas frequentes

Como saber se meu site WordPress foi hackeado sem acesso técnico?

Os sinais mais acessíveis para quem não tem acesso técnico são: redirecionamento para outro site, conteúdo estranho aparecendo nas páginas, aviso do Google Chrome ao acessar o site, e alerta no Google Search Console (Segurança e ações manuais > Problemas de segurança). Um scanner externo gratuito como o Sucuri SiteCheck também detecta injeções visíveis no HTML sem exigir instalação de nada.

O site parece normal para mim mas clientes estão recebendo avisos. Isso é invasão?

Provavelmente sim. Muitos ataques são configurados para mostrar conteúdo malicioso apenas para visitantes que chegam pelo Google ou que acessam de dispositivos móveis, enquanto o proprietário que acessa diretamente não vê nada errado. Isso é feito deliberadamente para dificultar a detecção. Verifique o Google Search Console imediatamente.

Posso limpar um WordPress hackeado sozinho?

Depende da extensão do comprometimento. Invasões simples — um plugin com arquivo modificado, por exemplo — podem ser tratadas com reinstalação limpa do plugin e troca de senhas. Invasões com backdoor instalado, web shell em uploads, ou injeção no banco de dados requerem diagnóstico técnico cuidadoso. Fazer uma limpeza incompleta é pior do que não fazer nada, porque você fica com a sensação de que o problema foi resolvido enquanto o backdoor permanece ativo.

O malware voltou depois que eu limpei. Por quê?

Porque a limpeza removeu o sintoma mas não o backdoor. O invasor quase sempre instala múltiplos pontos de retorno — um arquivo oculto em local incomum, um cron job que recria os arquivos apagados, ou um usuário administrador que ficou esquecido. A reinfecção em horas ou dias após a limpeza é sinal de que o ponto de retorno não foi encontrado e removido.

Quanto tempo leva para o Google remover o aviso de site malicioso?

Depois que você limpa o site e solicita revisão no Google Search Console (opção disponível na seção Problemas de Segurança), o Google pode levar de 1 a 3 dias para reanalisar e remover o aviso. Esse prazo não pode ser acelerado. O site precisa estar genuinamente limpo para a revisão ser aprovada — se o Google encontrar conteúdo malicioso na segunda varredura, o processo reinicia.

Meu plugin de segurança não detectou a invasão. Como isso é possível?

Plugins de segurança protegem contra os vetores que conhecem e para os quais estão configurados. Um backdoor bem ofuscado em um arquivo com nome inocente, ou um ataque via canal que o plugin não monitora, pode passar despercebido. Nenhum plugin de segurança substitui verificação periódica de integridade de arquivos e monitoramento de logs.

Qual é o sinal mais confiável de que o WordPress foi hackeado?

A combinação de alerta no Google Search Console com arquivos PHP encontrados dentro de wp-content/uploads é o par de evidências mais confiável. Separadamente, cada um poderia ter outra explicação; juntos, confirmam comprometimento com alta certeza.

Conclusão

A invasão de um WordPress raramente aparece como um alerta vermelho na tela. Ela aparece como um redirecionamento que “acontece às vezes”, uma página estranha que “não sei como apareceu”, um site que ficou um pouco mais lento, ou — no pior caso — como uma mensagem da hospedagem avisando que a conta foi suspensa.

O diagnóstico correto começa por cruzar pelo menos duas fontes de evidência: o Google Search Console, um scanner externo e a verificação de arquivos modificados. Agir na suspeita certa é o que separa uma limpeza eficaz de um ciclo interminável de reinfecção.

Se você identificou sinais de comprometimento ou quer estabelecer um processo que previna invasões antes que aconteçam, o serviço de manutenção de site WordPress inclui monitoramento de segurança, varredura de arquivos e resposta a incidentes.

Fontes e referências

WPScan Vulnerability Database (2025) — base de dados com vulnerabilidades catalogadas em plugins, temas e core do WordPress. Disponível em: wpscan.com
W3Techs Web Technology Surveys (2026) — participação de mercado do WordPress em CMS. Disponível em: w3techs.com
GovCERT.HK — Cybersecurity Threat Trends. Análise de componentes extensíveis como vetor de ataque em CMS.
NIST SP 800-83 — Guide to Malware Incident Prevention and Handling. Framework de resposta a incidentes de malware com fases de Preparação, Detecção, Contenção e Recuperação.
OWASP Top 10 — análise de falhas sistêmicas em aplicações web incluindo XSS, CSRF e SQL Injection. Disponível em: owasp.org
WordPress Developer Documentation — Hardening WordPress. Recomendações oficiais de segurança incluindo permissões de arquivo, proteção do wp-config.php e autenticação de dois fatores. Disponível em: developer.wordpress.org
Google Search Central — Security issues report. Documentação oficial sobre categorias de problemas de segurança detectados pelo Google. Disponível em: developers.google.com/search
Tese sobre Vulnerabilidades em CMS Desatualizados — análise estatística identificando XSS, CSRF e SQL Injection como responsáveis por 70% dos exploits graves em CMS.
RFC 2196 — Site Security Handbook. Modelo de segurança “deny all” e compromissos entre usabilidade e proteção.
Outpost24 Research — From LFI to Remote Code Execution. Escalação de vulnerabilidade de inclusão de arquivo para execução remota.