{"id":875,"date":"2026-09-20T17:04:44","date_gmt":"2026-09-20T17:04:44","guid":{"rendered":"https:\/\/100porcentowp.com.br\/central-de-ajuda\/cms\/link-injetado-wordpress-achar-limpar-varios-sites\/"},"modified":"2026-09-20T17:04:44","modified_gmt":"2026-09-20T17:04:44","slug":"link-injetado-wordpress-achar-limpar-varios-sites","status":"publish","type":"post","link":"https:\/\/100porcentowp.com.br\/central-de-ajuda\/seguranca\/link-injetado-wordpress-achar-limpar-varios-sites\/","title":{"rendered":"Link injetado WordPress: achar e limpar em v\u00e1rios sites"},"content":{"rendered":"

Voc\u00ea abre o Search Console e v\u00ea p\u00e1ginas que nunca criou. Ou um cliente avisa que o site est\u00e1 com links suspeitos no rodap\u00e9. O link injetado no WordPress quase sempre aparece assim: uma \u00e2ncora estranha no HTML, \u00e0s vezes vis\u00edvel, \u00e0s vezes n\u00e3o. E quando voc\u00ea administra v\u00e1rios sites, o problema se multiplica, porque o mesmo invasor costuma voltar pelas mesmas credenciais.<\/p>\n

Este artigo mostra a ordem de diagn\u00f3stico que separa inje\u00e7\u00e3o no banco de dados de inje\u00e7\u00e3o em arquivos e de JavaScript ofuscado. Tamb\u00e9m cobre o caso em que o link s\u00f3 aparece para quem chega pelo Google e some para quem est\u00e1 logado como administrador.<\/p>\n

Antes de tudo: por que o link injetado no WordPress some para voc\u00ea<\/h2>\n

Se voc\u00ea entra no site logado e n\u00e3o v\u00ea nada, n\u00e3o significa que o link n\u00e3o 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\u00e1gina sai limpa.<\/p>\n

Por isso, o primeiro teste \u00e9 abrir a URL suspeita em uma janela an\u00f4nima, sem login, e com user-agent de Googlebot. Voc\u00ea pode usar a extens\u00e3o de troca de user-agent do navegador ou o comando curl<\/code> no terminal:<\/p>\n

curl -A \"Mozilla\/5.0 (compatible; Googlebot\/2.1; +http:\/\/www.google.com\/bot.html)\" https:\/\/seusite.com.br\/pagina-suspeita | grep -i \"http\"<\/code><\/pre>\n
Compare a sa\u00edda com a vers\u00e3o que voc\u00ea v\u00ea logado. Se o HTML for diferente, o cloaking est\u00e1 ativo. Nesse caso, o c\u00f3digo que injeta o link costuma estar em um arquivo PHP do tema ou em um plugin, n\u00e3o no conte\u00fado do post.<\/p>\n
Separe inje\u00e7\u00e3o no banco de inje\u00e7\u00e3o em arquivo<\/h2>\n
Existem tr\u00eas lugares principais onde o link injetado no WordPress pode estar. Cada um pede uma abordagem diferente.<\/p>\n\n\n\n\n\n
Local<\/th>\nComo aparece<\/th>\nComo confirmar<\/th>\n<\/tr>\n
Banco de dados (wp_posts, wp_options, wp_usermeta)<\/td>\nLink no conte\u00fado de posts, em widgets, em menus ou em campos de usu\u00e1rio<\/td>\nBusca direta no banco por trechos do dom\u00ednio suspeito<\/td>\n<\/tr>\n
Arquivos de tema ou plugin<\/td>\nLink no rodap\u00e9, no header, em fun\u00e7\u00f5es PHP<\/td>\nCompara\u00e7\u00e3o de checksum com a vers\u00e3o oficial ou data de modifica\u00e7\u00e3o<\/td>\n<\/tr>\n
JavaScript ofuscado<\/td>\nScript estranho no rodap\u00e9, geralmente em base64 ou com nomes aleat\u00f3rios<\/td>\nInspe\u00e7\u00e3o do c\u00f3digo-fonte e busca por eval(<\/code>, base64_decode<\/code> ou dom\u00ednios desconhecidos<\/td>\n<\/tr>\n<\/table>\n
Na pr\u00e1tica, a ordem mais r\u00e1pida \u00e9 come\u00e7ar pelo banco, porque \u00e9 onde a maioria das inje\u00e7\u00f5es fica e onde a limpeza \u00e9 menos arriscada. Se o banco estiver limpo e o link continuar aparecendo, o problema est\u00e1 em arquivo.<\/p>\n
Varredura no banco: o que procurar e onde<\/h2>\n
Acesse o banco pelo phpMyAdmin ou pela linha de comando. Fa\u00e7a backup antes de qualquer altera\u00e7\u00e3o. Depois, rode consultas de busca pelo dom\u00ednio ou trecho suspeito. Use o prefixo real da sua instala\u00e7\u00e3o, que pode n\u00e3o ser wp_<\/code>.<\/p>\n
SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%dominio-suspeito%' OR post_excerpt LIKE '%dominio-suspeito%';<\/code><\/pre>\n
Repita para wp_options<\/code> (especialmente option_name<\/code> como widget_*<\/code>, theme_mods_*<\/code> e siteurl<\/code>), para wp_postmeta<\/code> e para wp_usermeta<\/code>. Em muitos casos, o invasor insere o link em um widget de texto ou em um campo de descri\u00e7\u00e3o de usu\u00e1rio, que o tema exibe sem escapar.<\/p>\n
Se encontrar, n\u00e3o edite direto no banco sem saber o que est\u00e1 fazendo. O ideal \u00e9 corrigir pelo painel quando poss\u00edvel (widgets, menus) e pelo banco apenas quando o conte\u00fado estiver em post ou option que o painel n\u00e3o acessa. Antes de limpar, anote o nome do dom\u00ednio injetado: ele ajuda a rastrear a origem.<\/p>\n
Varredura em arquivos: checksum e data de modifica\u00e7\u00e3o<\/h2>\n
Para saber se um arquivo foi alterado, compare o checksum com o da vers\u00e3o oficial. O WordPress oferece a API de checksum para o core, e plugins e temas t\u00eam seus pr\u00f3prios reposit\u00f3rios. Voc\u00ea pode usar WP-CLI:<\/p>\n
wp core verify-checksums\nwp plugin verify-checksums --all\nwp theme verify-checksums --all<\/code><\/pre>\n
Se o comando apontar arquivos alterados, veja a data de modifica\u00e7\u00e3o. Arquivos de tema e plugin costumam ter data da \u00faltima atualiza\u00e7\u00e3o oficial. Se um arquivo tem data de ontem e voc\u00ea n\u00e3o atualizou nada, \u00e9 sinal de que a porta de entrada ainda est\u00e1 aberta. Isso muda a prioridade: em vez de s\u00f3 limpar, voc\u00ea precisa fechar o acesso antes.<\/p>\n
Tamb\u00e9m vale procurar por arquivos PHP desconhecidos na raiz, em wp-content\/uploads<\/code> e em wp-includes<\/code>. Invasores costumam deixar backdoors com nomes parecidos com arquivos leg\u00edtimos.<\/p>\n
O caso do JavaScript ofuscado no rodap\u00e9<\/h2>\n
Quando o link injetado no WordPress n\u00e3o est\u00e1 no banco nem em arquivo de tema, ele pode estar em um script injetado no rodap\u00e9 via wp_footer<\/code> ou em um arquivo JS carregado de fora. Procure no c\u00f3digo-fonte por <script><\/code> que voc\u00ea n\u00e3o reconhece, especialmente os que usam eval<\/code>, base64_decode<\/code> ou concatenam strings para esconder o dom\u00ednio.<\/p>\n
Um teste r\u00e1pido \u00e9 desativar todos os plugins e trocar para um tema padr\u00e3o. Se o link sumir, o problema est\u00e1 em um plugin ou no tema. Se continuar, pode estar no core ou em um Must-Use plugin (wp-content\/mu-plugins<\/code>), que n\u00e3o aparece na lista normal do painel.<\/p>\n
Ordem de limpeza para n\u00e3o ser reinfectado<\/h2>\n
Limpar sem fechar a porta \u00e9 perda de tempo. A ordem que costuma funcionar \u00e9:<\/p>\n
    \n
  1. Troque todas as senhas: painel, FTP, banco, e-mail e chaves de API.<\/li>\n
  2. Troque as chaves de seguran\u00e7a do WordPress (AUTH_KEY<\/code>, SECURE_AUTH_KEY<\/code> e as demais em wp-config.php<\/code>). Isso invalida todas as sess\u00f5es ativas.<\/li>\n
  3. Revise os usu\u00e1rios administradores e remova contas desconhecidas.<\/li>\n
  4. S\u00f3 ent\u00e3o remova o link do banco e dos arquivos.<\/li>\n
  5. Atualize core, temas e plugins para as vers\u00f5es mais recentes.<\/li>\n
  6. Reinstale os arquivos do core e dos plugins afetados a partir de uma fonte limpa.<\/li>\n<\/ol>\n
    Se voc\u00ea n\u00e3o trocar as credenciais antes, o invasor volta pelo mesmo acesso. Em v\u00e1rios sites, isso significa repetir o processo v\u00e1rias vezes. Por isso, o passo 1 e 2 v\u00eam antes da limpeza.<\/p>\n
    Para confirmar se o site foi realmente comprometido e n\u00e3o \u00e9 apenas um falso positivo, vale revisar o artigo sobre WordPress invadido: como confirmar e agir<\/a>. Ele ajuda a diferenciar sinais claros de suspeita.<\/p>\n
    V\u00e1rios sites ao mesmo tempo: como varrer em lote<\/h2>\n
    Se voc\u00ea administra v\u00e1rios sites, fazer isso um por um \u00e9 invi\u00e1vel. Duas abordagens ajudam:<\/p>\n