{"id":920,"date":"2026-09-25T11:07:30","date_gmt":"2026-09-25T11:07:30","guid":{"rendered":"https:\/\/100porcentowp.com.br\/central-de-ajuda\/cms\/plugin-malicioso-wordpress-identificar-varios-sites\/"},"modified":"2026-09-25T11:07:31","modified_gmt":"2026-09-25T11:07:31","slug":"plugin-malicioso-wordpress-identificar-varios-sites","status":"publish","type":"post","link":"https:\/\/100porcentowp.com.br\/central-de-ajuda\/plugins\/plugin-malicioso-wordpress-identificar-varios-sites\/","title":{"rendered":"Plugin malicioso WordPress: identificar em v\u00e1rios sites"},"content":{"rendered":"

Voc\u00ea abre o painel de um dos vinte sites que administra e encontra um plugin que n\u00e3o instalou. O nome parece familiar, a vers\u00e3o \u00e9 antiga, o autor tem um perfil estranho. Em outros dezenove sites, ele n\u00e3o aparece. Esse \u00e9 o cen\u00e1rio cl\u00e1ssico de plugin malicioso WordPress<\/strong>: a infec\u00e7\u00e3o chega por um \u00fanico ponto, mas a decis\u00e3o precisa ser tomada em escala, n\u00e3o site a site.<\/p>\n

O erro mais comum nessa hora \u00e9 ir direto ao bot\u00e3o Apagar. Plugin infectado n\u00e3o \u00e9 igual a plugin desatualizado, e remov\u00ea-lo antes de entender o que ele deixou para tr\u00e1s pode derrubar o site. Este artigo mostra como triar, comparar e isolar antes de qualquer remo\u00e7\u00e3o definitiva.<\/p>\n

Por que comparar a lista de plugins entre sites \u00e9 o primeiro passo<\/h2>\n

Quem administra um site s\u00f3 costuma olhar a lista de plugins e tentar reconhecer cada item pela mem\u00f3ria. Quem administra vinte n\u00e3o pode depender disso. A compara\u00e7\u00e3o entre sites \u00e9 o m\u00e9todo mais r\u00e1pido de achar o que n\u00e3o deveria estar ali.<\/p>\n

O racioc\u00ednio \u00e9 simples: sites do mesmo parque costumam compartilhar um n\u00facleo de plugins (cache, SEO, formul\u00e1rio, seguran\u00e7a). O que foge desse n\u00facleo merece aten\u00e7\u00e3o. Um plugin que aparece em um site e em nenhum outro \u00e9 exce\u00e7\u00e3o, e exce\u00e7\u00e3o em parque de sites \u00e9 onde mora o problema.<\/p>\n

Na pr\u00e1tica, monte uma planilha com uma coluna por site e uma linha por plugin. Marque onde cada um est\u00e1 instalado. O que aparecer em uma \u00fanica coluna, ou em um grupo pequeno que voc\u00ea n\u00e3o reconhece, entra na fila de triagem. Esse exerc\u00edcio tamb\u00e9m revela plugins que voc\u00ea instalou uma vez, esqueceu, e que agora est\u00e3o desatualizados em todos os sites.<\/p>\n

Se a lista de plugins instalados j\u00e1 \u00e9 grande demais para revisar sem crit\u00e9rio, vale entender quando um plugin ajuda ou s\u00f3 pesa<\/a> antes de decidir o que fica e o que sai.<\/p>\n

Sinais que separam plugin malicioso WordPress de plugin apenas desatualizado<\/h2>\n

Plugin desatualizado \u00e9 risco, mas n\u00e3o \u00e9 o mesmo problema. Plugin malicioso tem assinatura pr\u00f3pria. Os sinais abaixo, quando aparecem juntos, apontam para infec\u00e7\u00e3o e n\u00e3o para simples falta de atualiza\u00e7\u00e3o.<\/p>\n\n\n\n\n\n\n\n
Sinal<\/th>\nPlugin desatualizado<\/th>\nPlugin malicioso WordPress<\/th>\n<\/tr>\n
Autor<\/td>\nConhecido, com p\u00e1gina no reposit\u00f3rio<\/td>\nNome gen\u00e9rico, sem site, ou autor que n\u00e3o existe<\/td>\n<\/tr>\n
Vers\u00e3o<\/td>\nAntiga, mas com changelog p\u00fablico<\/td>\nVers\u00e3o fixa, nunca atualiza, sem changelog<\/td>\n<\/tr>\n
Arquivos<\/td>\nEstrutura previs\u00edvel<\/td>\nArquivos com nome aleat\u00f3rio, ofuscados ou em pastas fora do padr\u00e3o<\/td>\n<\/tr>\n
Banco<\/td>\nSem altera\u00e7\u00e3o fora do escopo<\/td>\nOp\u00e7\u00f5es novas com nomes estranhos, usu\u00e1rios criados, cron jobs desconhecidos<\/td>\n<\/tr>\n
Tr\u00e1fego<\/td>\nNormal<\/td>\nRequisi\u00e7\u00f5es de sa\u00edda para dom\u00ednios que voc\u00ea n\u00e3o reconhece<\/td>\n<\/tr>\n<\/table>\n

Nenhum desses sinais isolado prova infec\u00e7\u00e3o. O conjunto, sim. Um plugin com autor estranho, vers\u00e3o congelada e requisi\u00e7\u00f5es de sa\u00edda para um dom\u00ednio desconhecido \u00e9 candidato claro a isolamento imediato.<\/p>\n

O que olhar no banco de dados<\/h3>\n

Plugins maliciosos costumam deixar rastro em tr\u00eas lugares do banco: na tabela de op\u00e7\u00f5es, na de usu\u00e1rios e na de agendamentos. Procure por op\u00e7\u00f5es com nomes que n\u00e3o correspondem a nenhum plugin ativo, usu\u00e1rios criados em datas que voc\u00ea n\u00e3o reconhece e tarefas agendadas apontando para fun\u00e7\u00f5es que n\u00e3o existem no n\u00facleo.<\/p>\n

Uma op\u00e7\u00e3o nova com nome aleat\u00f3rio, sozinha, n\u00e3o prova nada: muitos plugins leg\u00edtimos criam op\u00e7\u00f5es com prefixos pr\u00f3prios. O sinal de alerta \u00e9 a combina\u00e7\u00e3o com arquivos suspeitos e tr\u00e1fego de sa\u00edda an\u00f4malo.<\/p>\n

O que olhar nos arquivos<\/h3>\n

Se voc\u00ea tem acesso a SSH, compare a pasta de plugins com a vers\u00e3o oficial de cada um. Diferen\u00e7a de arquivo entre o que est\u00e1 no servidor e o que o autor distribui \u00e9 sinal forte. Se s\u00f3 tem painel de hospedagem, use o gerenciador de arquivos e procure por arquivos PHP com data de modifica\u00e7\u00e3o muito recente em pastas que voc\u00ea n\u00e3o mexeu.<\/p>\n

Em parques grandes, esse trabalho manual n\u00e3o escala. Uma triagem de vulnerabilidade em v\u00e1rios sites<\/a> organiza a fila por risco, e n\u00e3o por ordem alfab\u00e9tica.<\/p>\n

Por que ‘desativar e apagar’ pode derrubar o site<\/h2>\n

Apagar um plugin suspeito parece a decis\u00e3o \u00f3bvia. Em muitos casos, \u00e9 a decis\u00e3o errada. Plugin infectado frequentemente j\u00e1 se acoplou ao site: registrou shortcodes usados em posts, criou tipos de conte\u00fado personalizados, hooks que outros plugins dependem, ou alterou o .htaccess.<\/p>\n

Quando voc\u00ea apaga sem isolar, o site pode perder funcionalidade que ningu\u00e9m sabe de onde vinha. Pior: o plugin pode ter deixado um backdoor em outro arquivo, e apagar o principal s\u00f3 remove a fachada. O site continua comprometido, agora sem o ind\u00edcio que denunciava o problema.<\/p>\n

A ordem correta \u00e9 isolar antes de remover:<\/p>\n

    \n
  1. Fa\u00e7a backup completo do site, arquivos e banco, antes de qualquer a\u00e7\u00e3o.<\/li>\n
  2. Desative o plugin suspeito, sem apagar.<\/li>\n
  3. Observe o site por algumas horas: erros, p\u00e1ginas em branco, funcionalidades que sumiram.<\/li>\n
  4. Se algo quebrar, voc\u00ea sabe exatamente qual plugin era respons\u00e1vel e pode reativar para investigar.<\/li>\n
  5. S\u00f3 depois de entender o que o plugin fazia, remova os arquivos e limpe o banco.<\/li>\n<\/ol>\n

    Se o site travar durante a desativa\u00e7\u00e3o, o caminho \u00e9 o mesmo de qualquer plugin problem\u00e1tico: descobrir qual plugin travou o site<\/a> antes de mexer no restante.<\/p>\n

    Triagem em lote: como agir quando o plugin malicioso WordPress aparece em v\u00e1rios sites<\/h2>\n

    Um plugin malicioso WordPress em um site \u00e9 incidente. Em vinte, \u00e9 padr\u00e3o. A diferen\u00e7a muda a estrat\u00e9gia: voc\u00ea n\u00e3o vai investigar site a site, vai decidir por regra e aplicar em lote.<\/p>\n

    O primeiro passo \u00e9 agrupar os sites por exposi\u00e7\u00e3o. Quais t\u00eam o plugin suspeito? Quais compartilham hospedagem, tema ou outro plugin com os infectados? A proximidade entre eles indica o vetor de entrada.<\/p>\n

    Depois, defina a regra de a\u00e7\u00e3o. Por exemplo: todo site com o plugin X ser\u00e1 isolado hoje, com backup antes e verifica\u00e7\u00e3o depois. Todo site sem o plugin X, mas com o mesmo tema, entra em observa\u00e7\u00e3o. Essa regra evita a paralisia de abrir vinte pain\u00e9is e decidir cada um do zero.<\/p>\n

    Por fim, registre o que foi feito. Em parque grande, a mem\u00f3ria de quem mexeu no qu\u00ea \u00e9 o primeiro item a falhar. Um log simples, com data, site, plugin e a\u00e7\u00e3o, resolve.<\/p>\n

    Se o problema veio por credencial comprometida, vale revisar tamb\u00e9m os logins de administrador em v\u00e1rios sites<\/a>, porque plugin malicioso raramente age sozinho.<\/p>\n

    Quando N\u00c3O seguir esse roteiro<\/h2>\n

    Este caminho de triagem e isolamento pressup\u00f5e que voc\u00ea tem acesso ao painel e \u00e0 hospedagem, e que o site ainda responde. H\u00e1 situa\u00e7\u00f5es em que ele n\u00e3o se aplica.<\/p>\n

    Se o site est\u00e1 fora do ar e voc\u00ea n\u00e3o consegue acessar o wp-admin, a prioridade \u00e9 recuperar o acesso antes de qualquer triagem. Se o plugin suspeito \u00e9 o plugin de login, desativ\u00e1-lo pelo painel pode trancar voc\u00ea para fora. Nesse caso, o caminho \u00e9 trocar o plugin de login sem perder o acesso<\/a>, via FTP ou SSH, e s\u00f3 depois investigar.<\/p>\n

    Se a hospedagem n\u00e3o oferece backup recente e voc\u00ea n\u00e3o tem c\u00f3pia pr\u00f3pria, n\u00e3o desative nada antes de gerar uma. Sem rede de seguran\u00e7a, qualquer passo vira aposta.<\/p>\n

    Erros comuns na hora de lidar com plugin suspeito<\/h2>\n