Como auditar um plugin de WordPress antes de o instalar

Há uma chamada que qualquer pessoa que mantenha sites WordPress já recebeu alguma vez: “O Google mostra o meu site com títulos em japonês e anúncios de casinos”. Muitas vezes, a origem é um plugin instalado meses antes, por vezes com milhares de instalações e boas avaliações, que tinha uma vulnerabilidade por corrigir ou mesmo uma porta das traseiras.

Limpar um site assim custa horas de trabalho urgente e, sobretudo, confiança. Por isso, não instalamos nenhum plugin em produção sem passar primeiro por um protocolo de auditoria.

O repositório oficial do WordPress tem dezenas de milhares de plugins. Muitos são excelentes, alguns são perigosos e a maioria é medíocre. Saber distingui-los antes de instalar é indispensável.

Porque é que os plugins são um risco especial

O WordPress executa o código dos plugins com os mesmos privilégios que o núcleo. Um plugin pode:

• Ler e modificar qualquer dado da base de dados.
• Enviar dados para servidores externos sem que saibas.
• Injetar código no frontend para roubar informação dos utilizadores.
• Criar utilizadores administradores ocultos.
• Descarregar e instalar mais malware se fizer parte de uma cadeia de infeção.

Além disso, há riscos de desempenho (plugins que tornam cada página mais lenta), de compatibilidade (conflitos com outros plugins ou com o tema) e de manutenção (plugins abandonados que deixam de funcionar com as atualizações do WordPress).

Auditar antes de instalar não garante que não haja problemas, mas elimina a maioria dos riscos evidentes.

Fase 1: avaliação no repositório (antes de descarregar)

Antes de tocar no código, revemos a informação pública do plugin:

Última atualização. Um plugin que está há mais de um ano sem ser atualizado é suspeito. Preferimos plugins atualizados nos últimos 3 a 6 meses.

Compatibilidade com a tua versão do WordPress. Se o plugin indica que só foi testado até uma versão de há vários anos, há risco de incompatibilidades. Não é um veto automático, mas é um sinal de alerta.

Número de instalações ativas. Mais instalações costumam significar mais olhos a rever o código. A nossa regra: abaixo de 1.000 instalações ativas, o plugin precisa de uma revisão de código mais aprofundada; abaixo de 100, desconfiamos, a não ser que venha de um programador conhecido. Atenção, porque a popularidade também não é garantia: os plugins mais instalados são também os mais apetecíveis para os atacantes.

Historial de vulnerabilidades. Consultamos bases de dados públicas como as da WPScan, da Patchstack ou da Wordfence. Ter tido vulnerabilidades não o exclui (acontece a quase todos os grandes); o que importa é quanto tempo se demorou a corrigi-las. E se a ficha do plugin aparecer fechada no repositório, não o instales até saberes porquê: o WordPress.org fecha plugins, entre outros motivos, por falhas de segurança por resolver.

Avaliações e suporte. Lemos as avaliações negativas recentes e os tópicos de suporte em aberto. Um plugin com muitos “deu cabo do meu site” ou “o suporte não responde” é um sinal de alarme, seja qual for a avaliação média.

Programador. É uma empresa consolidada ou um programador desconhecido? Tem outros plugins com boa reputação e uma forma clara de contacto?

Se falhar em vários destes critérios, nem sequer descarregamos o código: no WordPress há alternativas para quase tudo.

Fase 2: análise de código (para plugins novos ou pouco testados)

Para os plugins que passam a fase 1 mas são críticos para o projeto ou vêm de fontes menos conhecidas, revemos o código. Não é preciso ser especialista em PHP para ver o mais evidente:

Funções perigosas. Procuramos eval(), exec(), shell_exec() ou base64_decode(). A sua presença não implica que o plugin seja malicioso, mas precisa de justificação. Um plugin de SEO que usa eval() é suspeito.

Chamadas externas. Procuramos wp_remote_get(), wp_remote_post(), file_get_contents() com URL ou curl. A que servidores se liga? Um plugin de formulários que envia dados para um domínio sem relação com o serviço é um sinal de alarme.

Criação de utilizadores ou funções. Cria utilizadores administradores? Acrescenta novas permissões? Pode ser legítimo (num plugin de áreas de membros, por exemplo), mas tem de fazer sentido com o que o plugin faz.

Código ofuscado. Código ofuscado ou codificado em base64 sem motivo aparente. Alguns plugins premium fazem-no para se protegerem; num gratuito, é um sinal de alerta.

Escrita de ficheiros. O plugin tenta modificar ficheiros do núcleo do WordPress ou do tema? Raramente é necessário e é uma via de infeção clássica.

Nesta fase, combinamos ferramentas automáticas, como o plugin oficial Plugin Check ou o PHP_CodeSniffer com as regras do WordPress Coding Standards, com uma revisão manual dos ficheiros principais.

Fase 3: teste num ambiente isolado

Nunca instalamos um plugin diretamente em produção. O fluxo é este:

1. Instalação local. Instalamos o plugin num ambiente de desenvolvimento local (Docker, LocalWP ou semelhante).
2. Teste de funcionalidade básica. Faz o que promete? As definições são guardadas corretamente?
3. Consumo de recursos. Com o Query Monitor ou uma ferramenta semelhante, verificamos se acrescenta consultas à base de dados, se carrega scripts desnecessários em todas as páginas ou se consome demasiada memória.
4. Teste de conflitos. Com os plugins principais do site já instalados, verificamos que não surgem erros de JavaScript, falhas de funcionamento nem avisos de PHP.
5. Revisão de segurança básica. Faz o escape correto da saída? Valida e limpa as entradas? Usa nonces e verifica permissões nos seus formulários e pedidos AJAX?

Só quando o plugin passa todas estas fases o levamos para staging e, por fim, para produção. Se afetar o desempenho, revê também como convive com a cache: explicamos isso em como configurar corretamente um sistema de cache no WordPress.

Plugins premium: considerações adicionais

Os plugins pagos têm as suas próprias regras:

Licença e servidores de ativação. Alguns plugins premium precisam de se ligar ao servidor de licenças do programador para funcionar ou atualizar-se. Se o programador fechar, o que acontece ao teu plugin?

Atualizações. Os plugins premium não são atualizados através do repositório oficial, mas sim pelo sistema próprio do programador, normalmente associado a uma licença ativa. Se a licença expirar, deixas de receber correções de segurança.

Código fechado. Alguns plugins premium têm o código ofuscado ou cifrado com ferramentas como o ionCube, o que impede uma auditoria completa. Nesse caso, dependes totalmente da reputação do programador.

Cópias “nulled”. As versões pirateadas de plugins premium que circulam gratuitamente na internet são uma das vias de infeção mais habituais. Não há poupança que compense esse risco.

Aqui, o percurso do programador pesa ainda mais: preferimos empresas com anos de atividade às licenças “vitalícias” de quem acabou de chegar.

Sinais que desqualificam um plugin automaticamente

Há sinais que, se aparecerem, excluem um plugin de imediato, sem mais auditoria:

• Código ofuscado num plugin gratuito.
• Chamadas a domínios suspeitos ou que mudam entre versões.
• Criação de utilizadores administradores ocultos.
• Inserção de conteúdo sem consentimento (por exemplo, links de afiliado ocultos).
• Dados introduzidos pelo utilizador que chegam sem validação a consultas SQL.
• Mais de 2 anos sem atualizações e incompatibilidade com as versões atuais do WordPress.
• Programador sem dados de contacto nem identidade verificável.

Manutenção depois de instalar

Um plugin seguro hoje pode ter amanhã uma vulnerabilidade acabada de descobrir. Por isso:

• Mantemos um inventário de todos os plugins instalados e das respetivas versões.
• Subscrevemos alertas de segurança (Wordfence, Patchstack, WPScan ou semelhantes).
• Aplicamos as atualizações de segurança num prazo de 24 a 48 horas.
• Todos os trimestres, revemos se todos os plugins instalados continuam a ser necessários.

E a segurança dos plugins serve de pouco se o acesso ao painel for fraco: palavras-passe, 2FA e gestores de palavras-passe são a outra metade do trabalho.

Perguntas frequentes

Quanto tempo demora auditar um plugin?

A fase 1 demora cerca de 5 minutos. A fase 2, de 15 a 30 minutos em plugins simples. A fase 3 depende da complexidade. Em plugins do repositório com mais de 1 milhão de instalações e bom historial, por vezes basta-nos a fase 1 e o teste em staging.

Devo evitar os plugins gratuitos?

Não. Muitos plugins gratuitos do repositório oficial são excelentes e mantidos por equipas profissionais (Yoast SEO ou WooCommerce, por exemplo). Ser gratuito não é o problema; estar abandonado, sim.

Posso confiar nos plugins do CodeCanyon ou de marketplaces semelhantes?

Com mais cautela. Não passam pela mesma revisão que o repositório oficial, por isso exigem uma auditoria mais aprofundada. Sempre que possível, compramos diretamente ao programador.

O que faço se já instalei um plugin sem o auditar e agora tenho problemas?

Desinstalá-lo nem sempre chega. Alguns deixam código residual, tabelas na base de dados ou utilizadores criados. Revê o que mudou, limpa o que ficou e pondera uma auditoria de segurança completa. Se já houver indícios de ataque, segue este guia de primeiros socorros para um site pirateado.

Conclusão

O ecossistema de plugins é um dos maiores pontos fortes do WordPress e também um dos seus maiores riscos. Instalar é um só clique, e isso esconde o que estás a permitir que seja executado no teu servidor.

Um protocolo de auditoria não é paranoia, é profissionalismo. Demora minutos e pode poupar-te horas de limpeza ou os danos à tua reputação que um ataque deixa.

Se geres sites WordPress e queres que revejamos os plugins que tens instalados, ou precisas de ajuda para limpar um site comprometido, conta-nos o teu caso. Ainda assim, preferimos ajudar-te a prevenir o problema do que a resolvê-lo depois.