Plugins WordPress vulneráveis: auditar, atualizar, substituir

O ponto fraco de um site WordPress raramente é o próprio WordPress. Lidar com vulnerabilidades em plugins WordPress resume-se a quatro hábitos: saber exatamente o que está instalado, atualizar depressa, apagar o que não faz falta e substituir o que já ninguém mantém.

Este guia mostra como criar cada um destes hábitos, como reconhecer plugins abandonados e o que fazer no caso incómodo de uma vulnerabilidade já ser pública sem que exista correção. É um dos pontos da nossa lista de verificação de segurança para WordPress e, na maioria dos sites, o que mais pesa.

O que dizem os números sobre vulnerabilidades em plugins WordPress

Os números anuais mais detalhados vêm do relatório da Patchstack State of WordPress Security in 2026, que abrange o ano de 2025. A Patchstack é uma empresa de segurança que vende proteção contra estes riscos, por isso convém ler o relatório como uma fonte bem informada e não como uma estatística oficial. As principais conclusões:

• 11 334 novas vulnerabilidades no ecossistema WordPress em 2025, mais 42 % do que em 2024.
• 91 % estavam em plugins e 9 % em temas. O núcleo do WordPress teve seis, todas de baixa prioridade.
• 17 % (1 966) eram de gravidade elevada e com probabilidade de virem a ser usadas em ataques automatizados em massa.
• 46 % não tinham correção disponível do programador no momento da divulgação pública.
• O controlo de acessos deficiente (broken access control) foi a categoria mais explorada.

Ou seja: a lista de plugins é a superfície de ataque do site. Cada plugin é código de outra equipa, a quem se confia o site e os dados que ele contém.

Porque é que a rapidez das atualizações importa

Os atacantes não escolhem os sites a dedo. Varrem a internet à procura de uma versão vulnerável de um plugin e exploram automaticamente cada site que encontram. Segundo o mesmo relatório, nas vulnerabilidades mais exploradas, a mediana ponderada do tempo até à exploração em massa foi de cinco horas, e cerca de metade das vulnerabilidades de alto impacto foram exploradas em menos de 24 horas.

Uma janela de manutenção mensal é demasiado lenta para estes casos. As versões de segurança precisam de um circuito mais rápido do que as atualizações de funcionalidades. Aplicar correções a tempo é também uma parte básica das medidas de segurança "adequadas" exigidas pelo artigo 32.º do RGPD, e a Diretiva NIS2, no art. 21.º, n.º 2, alínea e), inclui o tratamento de vulnerabilidades entre as medidas mínimas das organizações abrangidas.

Passo 1: Manter um inventário de plugins

Não se pode atualizar nem avaliar o que não se conhece. Um inventário simples por site, nem que seja uma folha de cálculo, deve registar:

• nome do plugin, slug e versão instalada
• origem: WordPress.org, um fornecedor comercial ou código próprio
• porque está instalado e quem o pediu
• estado da licença e data de renovação, no caso dos plugins premium
• se as atualizações automáticas estão ativas

Com o WP-CLI, a maior parte desta informação sai num só comando:

wp plugin list --fields=name,status,version,update_version,auto_update

As versões recentes do WP-CLI também mostram o que o WordPress.org sabe sobre cada plugin, incluindo se foi encerrado:

wp plugin list --fields=name,version,wporg_status,wporg_last_updated

Os plugins que não estão alojados no WordPress.org aparecem normalmente com valores vazios, por isso esses têm de ser confirmados junto do fornecedor. Faça o mesmo para os temas com wp theme list.

Passo 2: Apagar os plugins que não usa

Desativar um plugin impede o WordPress de o carregar, mas os ficheiros ficam no servidor. Algumas vulnerabilidades podem ser exploradas pedindo diretamente os ficheiros do plugin, e os plugins inativos tendem a ficar de fora das rotinas de atualização. O próprio ecrã Saúde do site do WordPress (Ferramentas → Saúde do site) avisa que os plugins inativos são alvos tentadores para os atacantes.

Quando um plugin deixar de ser necessário, faça uma cópia de segurança e depois desative-o e apague-o no ecrã Plugins. Na linha de comandos:

wp plugin uninstall old-slider --deactivate

O wp plugin uninstall executa a rotina de desinstalação do próprio plugin, que pode também remover as suas definições e dados da base de dados, e depois apaga os ficheiros. O wp plugin delete só remove os ficheiros. Exporte primeiro tudo aquilo de que ainda precise.

Candidatos típicos: plugins de teste esquecidos depois de um projeto, funções duplicadas (dois plugins de cache ou de SEO), ferramentas de migração usadas uma única vez e plugins cuja tarefa o núcleo do WordPress já assegura.

Passo 3: Substituir plugins abandonados e "nulled"

Um plugin sem ninguém que o mantenha não vai receber correção quando for descoberta a próxima vulnerabilidade.

Sinais de que um plugin foi abandonado

• Sem atualizações recentes. Veja a data da última atualização na página do plugin no WordPress.org. O WordPress.org também mostra um aviso quando um plugin não foi testado com as 3 últimas versões principais do WordPress.
• Encerrado no WordPress.org. Um aviso a vermelho indica que o plugin foi encerrado e já não está disponível para descarregar. Ao fim de 60 dias é acrescentado o motivo, e "Security Issue" (problema de segurança) é um dos motivos possíveis. Seja qual for o motivo, enquanto o plugin estiver encerrado não chegam atualizações através do WordPress.org.
• Pedidos de suporte sem resposta, sobretudo os que referem problemas de segurança.
• Plugins premium cujo fornecedor deixou de dar sinais de vida: sem entradas novas no registo de alterações, renovações de licença que não funcionam, nenhuma resposta do suporte.

A documentação sobre alertas e avisos do WordPress.org explica estas mensagens. Quando as vir, planeie a substituição antes que uma emergência o obrigue a isso.

Nunca usar plugins "nulled"

Os plugins "nulled" são cópias piratas de plugins premium sem a verificação de licença. Um terceiro desconhecido alterou o código e ninguém sabe dizer o que mais foi mudado. As backdoors escondidas são um problema bem conhecido destas cópias. Além disso, nunca recebem atualizações nem suporte, pelo que não é possível corrigi-las quando surgir a próxima vulnerabilidade.

Se encontrar um destes plugins num site, substitua-o por uma cópia licenciada e trate o site como possivelmente comprometido.

Passo 4: Atualizar depressa, com atualizações automáticas ou staging

Desde o WordPress 5.5 é possível ativar as atualizações automáticas plugin a plugin, na coluna "Atualizações automáticas" do ecrã Plugins. Por omissão, o WordPress executa-as duas vezes por dia e envia os resultados por e-mail (documentação do WordPress.org). Com o WP-CLI: wp plugin auto-updates enable --all.

Dada a rapidez com que os ataques surgem, as atualizações automáticas são a predefinição certa para a maioria dos plugins. Ainda assim, um ambiente de staging faz sentido quando uma atualização que corra mal custa dinheiro a sério:

Seja qual for a escolha, mantenha cópias de segurança que já tenha reposto pelo menos uma vez e garanta que alguém lê os e-mails das atualizações.

Passo 5: Acompanhar as vulnerabilidades e agir

Onde consultar vulnerabilidades de plugins

• O registo de alterações (changelog) na página do plugin no WordPress.org ou no site do fornecedor. Procure entradas como "security fix", mas conte com descrições vagas por parte de alguns fornecedores.
• Bases de dados públicas de vulnerabilidades, como as da WPScan e da Patchstack, que permitem pesquisar pelo nome do plugin. Ambas são geridas por empresas que também vendem serviços de segurança.
• Avisos e newsletters dos fornecedores, no caso dos plugins premium.

Verificar dezenas de plugins à mão não é viável. O Security Audit & Compliance, o plugin de auditoria da secaudit.eu, assinala de origem os plugins, temas e versões do núcleo desatualizados. Depois de ativar a verificação de vulnerabilidades, compara também as versões instaladas com a base de dados de vulnerabilidades gratuita da secaudit.eu, criada todas as noites a partir da lista oficial de CVE; a lista de plugins nunca sai do seu site.

O que fazer quando ainda não há correção

Quase metade das vulnerabilidades (46 %) não tinha correção no momento da divulgação. Se uma delas afetar um plugin que usa:

1. Avalie a exposição. Os visitantes anónimos conseguem chegar à funcionalidade vulnerável, ou só os administradores com sessão iniciada?
2. Desative o plugin se puder passar sem ele durante algum tempo, e apague-o se a correção não chegar.
3. Substitua-o por uma alternativa com manutenção ativa se o fornecedor não der resposta.
4. Recorra a virtual patching se o plugin for indispensável: algumas firewalls de aplicações web (WAF) e serviços de segurança fornecem regras que bloqueiam os pedidos que correspondem ao exploit conhecido. Isto dá tempo; não corrige o código.
5. Procure sinais de comprometimento, sobretudo se a falha já era pública há algum tempo quando deu por ela. A nossa lista de sinais de que um site WordPress foi pirateado é um bom ponto de partida.

Se vende plugins: o Regulamento de Ciber-Resiliência

Para quem vende plugins, o tratamento de vulnerabilidades está a tornar-se uma obrigação legal, e parte dela já se aplica. Um plugin ou tema pago vendido a clientes na UE é um "produto com elementos digitais" na aceção do Regulamento de Ciber-Resiliência (CRA), e quem o vende é o fabricante. Desde 11 de setembro de 2026, os fabricantes têm de notificar as vulnerabilidades ativamente exploradas nos seus produtos através da plataforma única de notificação da ENISA (Single Reporting Platform): um alerta precoce no prazo de 24 horas, uma notificação no prazo de 72 horas e um relatório final no prazo de 14 dias após estar disponível uma medida corretiva.

A partir de 11 de dezembro de 2027 aplicam-se as obrigações principais, incluindo atualizações de segurança durante o período de suporte, um processo de tratamento de vulnerabilidades, uma política de divulgação coordenada e uma lista de materiais de software (SBOM). Os plugins de código aberto gratuitos e não monetizados ficam, em regra, fora deste regime dos fabricantes. Os pormenores estão no nosso guia do Regulamento de Ciber-Resiliência para quem vende plugins.

Perguntas frequentes

Um plugin desativado é seguro?

Não. Os ficheiros continuam no servidor e podem conter código explorável. Apague os plugins que não usa.

Devo ativar as atualizações automáticas em todos os plugins?

Na maioria, sim, combinadas com cópias de segurança fiáveis. Teste primeiro em staging os plugins críticos para o negócio, mas mantenha esse atraso curto.

E se um plugin de que dependo foi encerrado no WordPress.org?

Trate-o como um plugin sem manutenção até ser reaberto com uma versão corrigida e comece já a procurar uma alternativa.

Este artigo contém informação geral e não constitui aconselhamento jurídico.