Você abre o Search Console e vê páginas que nunca criou. Ou um cliente avisa que o site está com links suspeitos no rodapé. O link injetado no WordPress quase sempre aparece assim: uma âncora estranha no HTML, às vezes visível, às vezes não. E quando você administra vários sites, o problema se multiplica, porque o mesmo invasor costuma voltar pelas mesmas credenciais.
Este artigo mostra a ordem de diagnóstico que separa injeção no banco de dados de injeção em arquivos e de JavaScript ofuscado. Também cobre o caso em que o link só aparece para quem chega pelo Google e some para quem está logado como administrador.
Antes de tudo: por que o link injetado no WordPress some para você
Se você entra no site logado e não vê nada, não significa que o link não existe. Muitos scripts injetados usam cloaking por user-agent: entregam o link apenas para o bot do Google ou para visitantes que chegam de busca. Para o seu navegador com cookie de admin, a página sai limpa.
Por isso, o primeiro teste é abrir a URL suspeita em uma janela anônima, sem login, e com user-agent de Googlebot. Você pode usar a extensão de troca de user-agent do navegador ou o comando curl no terminal:
curl -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" https://seusite.com.br/pagina-suspeita | grep -i "http"Compare a saída com a versão que você vê logado. Se o HTML for diferente, o cloaking está ativo. Nesse caso, o código que injeta o link costuma estar em um arquivo PHP do tema ou em um plugin, não no conteúdo do post.
Separe injeção no banco de injeção em arquivo
Existem três lugares principais onde o link injetado no WordPress pode estar. Cada um pede uma abordagem diferente.
| Local | Como aparece | Como confirmar |
|---|---|---|
| Banco de dados (wp_posts, wp_options, wp_usermeta) | Link no conteúdo de posts, em widgets, em menus ou em campos de usuário | Busca direta no banco por trechos do domínio suspeito |
| Arquivos de tema ou plugin | Link no rodapé, no header, em funções PHP | Comparação de checksum com a versão oficial ou data de modificação |
| JavaScript ofuscado | Script estranho no rodapé, geralmente em base64 ou com nomes aleatórios | Inspeção do código-fonte e busca por eval(, base64_decode ou domínios desconhecidos |
Na prática, a ordem mais rápida é começar pelo banco, porque é onde a maioria das injeções fica e onde a limpeza é menos arriscada. Se o banco estiver limpo e o link continuar aparecendo, o problema está em arquivo.
Varredura no banco: o que procurar e onde
Acesse o banco pelo phpMyAdmin ou pela linha de comando. Faça backup antes de qualquer alteração. Depois, rode consultas de busca pelo domínio ou trecho suspeito. Use o prefixo real da sua instalação, que pode não ser wp_.
SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%dominio-suspeito%' OR post_excerpt LIKE '%dominio-suspeito%';Repita para wp_options (especialmente option_name como widget_*, theme_mods_* e siteurl), para wp_postmeta e para wp_usermeta. Em muitos casos, o invasor insere o link em um widget de texto ou em um campo de descrição de usuário, que o tema exibe sem escapar.
Se encontrar, não edite direto no banco sem saber o que está fazendo. O ideal é corrigir pelo painel quando possível (widgets, menus) e pelo banco apenas quando o conteúdo estiver em post ou option que o painel não acessa. Antes de limpar, anote o nome do domínio injetado: ele ajuda a rastrear a origem.
Varredura em arquivos: checksum e data de modificação
Para saber se um arquivo foi alterado, compare o checksum com o da versão oficial. O WordPress oferece a API de checksum para o core, e plugins e temas têm seus próprios repositórios. Você pode usar WP-CLI:
wp core verify-checksums
wp plugin verify-checksums --all
wp theme verify-checksums --allSe o comando apontar arquivos alterados, veja a data de modificação. Arquivos de tema e plugin costumam ter data da última atualização oficial. Se um arquivo tem data de ontem e você não atualizou nada, é sinal de que a porta de entrada ainda está aberta. Isso muda a prioridade: em vez de só limpar, você precisa fechar o acesso antes.
Também vale procurar por arquivos PHP desconhecidos na raiz, em wp-content/uploads e em wp-includes. Invasores costumam deixar backdoors com nomes parecidos com arquivos legítimos.
O caso do JavaScript ofuscado no rodapé
Quando o link injetado no WordPress não está no banco nem em arquivo de tema, ele pode estar em um script injetado no rodapé via wp_footer ou em um arquivo JS carregado de fora. Procure no código-fonte por <script> que você não reconhece, especialmente os que usam eval, base64_decode ou concatenam strings para esconder o domínio.
Um teste rápido é desativar todos os plugins e trocar para um tema padrão. Se o link sumir, o problema está em um plugin ou no tema. Se continuar, pode estar no core ou em um Must-Use plugin (wp-content/mu-plugins), que não aparece na lista normal do painel.
Ordem de limpeza para não ser reinfectado
Limpar sem fechar a porta é perda de tempo. A ordem que costuma funcionar é:
- Troque todas as senhas: painel, FTP, banco, e-mail e chaves de API.
- Troque as chaves de segurança do WordPress (
AUTH_KEY,SECURE_AUTH_KEYe as demais emwp-config.php). Isso invalida todas as sessões ativas. - Revise os usuários administradores e remova contas desconhecidas.
- Só então remova o link do banco e dos arquivos.
- Atualize core, temas e plugins para as versões mais recentes.
- Reinstale os arquivos do core e dos plugins afetados a partir de uma fonte limpa.
Se você não trocar as credenciais antes, o invasor volta pelo mesmo acesso. Em vários sites, isso significa repetir o processo várias vezes. Por isso, o passo 1 e 2 vêm antes da limpeza.
Para confirmar se o site foi realmente comprometido e não é apenas um falso positivo, vale revisar o artigo sobre WordPress invadido: como confirmar e agir. Ele ajuda a diferenciar sinais claros de suspeita.
Vários sites ao mesmo tempo: como varrer em lote
Se você administra vários sites, fazer isso um por um é inviável. Duas abordagens ajudam:
- Varredura no banco em lote: exporte uma lista de domínios suspeitos e rode a consulta
LIKEem cada banco. Você pode automatizar com um script que percorre os bancos e grava o resultado em um arquivo. - Comparação de checksum em lote: use WP-CLI em cada instalação e colete a saída. Sites com arquivos alterados aparecem rapidamente.
Além disso, monitore a data de modificação dos arquivos. Se um site apresenta arquivos alterados em datas próximas, provavelmente a mesma vulnerabilidade foi explorada em vários. Nesse caso, a triagem de vulnerabilidade em plugin WordPress ajuda a identificar qual plugin é o ponto de entrada comum.
Ferramentas de gestão de múltiplos sites, como o 100% WP, ajudam a manter atualizações, backups e monitoramento em um só lugar, o que reduz a janela de exposição a esse tipo de ataque. Mas a limpeza em si ainda exige o diagnóstico manual descrito aqui.
Quando NÃO limpar por conta própria
Se o link injetado no WordPress estiver acompanhado de redirecionamentos, queda de performance ou arquivos desconhecidos em uploads, o comprometimento pode ser mais profundo. Nesses casos, limpar apenas o link visível não resolve, porque o invasor mantém backdoors.
Também não tente limpar sem backup. Se você remover uma linha errada no banco, pode quebrar o site. E se o site for de um cliente com dados sensíveis, o risco de responsabilidade é grande.
Erros comuns ao remover link injetado
- Remover o link do post e não verificar widgets, menus e usermeta.
- Não trocar as senhas antes de limpar.
- Ignorar arquivos com data de modificação recente.
- Não verificar Must-Use plugins.
- Deixar a versão do WordPress ou de plugins desatualizada.
Outro erro é achar que o problema acabou porque o link sumiu para você. Se o cloaking estiver ativo, o link injetado no WordPress pode continuar aparecendo para o Google. Teste em janela anônima e com user-agent de bot depois da limpeza.
Prevenção para quem gerencia vários sites
Manter tudo atualizado é o básico. Além disso, use senhas únicas, ative autenticação de dois fatores e restrinja o acesso ao wp-login.php por IP ou por plugin de segurança. Monitore alterações de arquivos e faça backup frequente.
Para sites de clientes, documente o processo de resposta a incidentes. Assim, quando um link injetado no WordPress aparecer, você já sabe a ordem: isolar, trocar credenciais, limpar e verificar. Se precisar de ajuda especializada, o serviço de segurança e remoção de malware pode ser acionado.
Por fim, se você está assumindo sites de terceiros, vale avaliar a segurança antes de aceitar o projeto, como mostra o artigo sobre WordPress é seguro? O que avaliar antes de assumir um site.
