Ataques Supply Chain ao WordPress: Como 400.000 Sites Foram Comprometidos

Em abril de 2026, mais de 400.000 sites WordPress foram comprometidos num dos ataques mais sofisticados de sempre ao ecossistema WordPress. Um comprador anónimo adquiriu 31 plugins legítimos através da plataforma Flippa e, oito meses depois, ativou uma backdoor que tinha plantado silenciosamente em todos eles.

Este não foi um ataque a uma vulnerabilidade técnica. Foi um ataque à confiança — ao sistema que faz o WordPress funcionar.

O que é um ataque supply chain?

Um ataque supply chain (cadeia de abastecimento) não explora uma falha no código — explora a confiança no fornecedor. Em vez de atacar o seu site diretamente, o atacante compromete algo em que o seu site confia: um plugin, um tema, uma biblioteca, ou até o próprio sistema de atualizações.

No ecossistema WordPress, isto é particularmente perigoso porque:

• Existem mais de 61.000 plugins no repositório oficial do WordPress.org
• 91% das vulnerabilidades WordPress em 2025 foram encontradas em plugins
• O sistema de atualizações automáticas distribui código para milhares de sites sem revisão humana intermédia
• Não existe assinatura criptográfica que verifique a autenticidade das atualizações

Quando instala um plugin e ativa as atualizações automáticas, está a confiar que o autor desse plugin vai manter a integridade do código — para sempre. O que acontece quando esse autor muda?

Caso 1: EssentialPlugin — 31 plugins comprados no Flippa

A compra silenciosa

O portfolio EssentialPlugin incluía 31 plugins com mais de 400.000 instalações totais. Foram desenvolvidos pela equipa WP Online Support desde 2015, mas a receita tinha caído 35-45% em 2024. O portfolio foi colocado à venda no Flippa — uma plataforma legítima de compra e venda de ativos digitais.

Um comprador identificado apenas como “Kris”, com histórico em SEO, criptomoedas e marketing de gambling online, adquiriu tudo por um valor de seis dígitos no início de 2025.

O Flippa chegou a publicar um caso de estudo sobre a transação bem-sucedida em julho de 2025. As mais de 400.000 instalações nunca foram notificadas da mudança de proprietário.

A backdoor dormente

A 8 de agosto de 2025, o novo proprietário lançou a versão 2.6.7 de todos os plugins. O changelog dizia apenas: “Check compatibility with WordPress version 6.8.2”. Uma mensagem completamente normal.

Escondidas nessa atualização estavam 191 linhas adicionais de código PHP malicioso, inseridas no ficheiro class-anylc-admin.php dentro do módulo wpos-analytics. O ficheiro passou de 473 para 664 linhas.

A backdoor consistia em três componentes:

1. Endpoint REST API sem autenticação — acessível por qualquer pessoa na internet
2. Método fetch_ver_info() — contactava analytics.essentialplugin.com e executava a resposta sem qualquer validação, usando @unserialize()
3. Método version_info_clean() — permitia a criação arbitrária de ficheiros no servidor

O aspeto mais engenhoso: o servidor de comando e controlo (C2) era resolvido através de um smart contract Ethereum. Mesmo que o domínio fosse bloqueado, o atacante podia apontar para um novo domínio atualizando o contrato na blockchain — tornando um takedown tradicional ineficaz.

A ativação — 6 horas e 44 minutos

A 5-6 de abril de 2026, oito meses após plantar a backdoor, o atacante ativou-a. A janela de injeção durou 6 horas e 44 minutos (das 04:22 às 11:06 UTC de 6 de abril).

Nesse período, o payload:

• Criou o ficheiro wp-comments-posts.php na raiz do WordPress (imitando o legítimo wp-comments-post.php)
• Injetou aproximadamente 6KB de código PHP malicioso no wp-config.php
• Instalou spam de SEO visível apenas para o Googlebot — os donos dos sites viam tudo normal ao navegar

O cloaking era sofisticado: verificava o user-agent do visitante e servia conteúdo diferente para motores de busca (links de gambling, crypto e farmacêuticas) e para utilizadores humanos (o site original, intacto). Este tipo de manipulação destrói o posicionamento orgânico do site — algo que, como abordámos no artigo sobre como aparecer no topo do Google, leva meses ou anos a construir.

A descoberta e resposta

Austin Ginder, fundador da Anchor Hosting, descobriu o compromisso através de um alerta no painel WordPress de um cliente. Usando backups e pesquisa binária forense, identificou a janela exata de injeção.

A 7 de abril, a equipa de revisão de plugins do WordPress.org confirmou o compromisso e fechou permanentemente todos os 31 plugins. A 8 de abril, o WordPress.org forçou uma atualização automática para a versão 2.6.9.1.

Problema crítico: esta atualização forçada desativou o mecanismo de phone-home, mas NÃO removeu o código malicioso já injetado no wp-config.php. Sites que receberam a atualização automática continuavam comprometidos sem saber.

Caso 2: Smart Slider 3 Pro — 800.000 instalações

Na mesma semana, o Smart Slider 3 Pro (um dos plugins de slider mais populares do mundo, com 800.000+ instalações) foi comprometido através de um ataque diferente: o atacante obteve acesso não autorizado aos servidores de atualização da Nextend, o developer.

A versão maliciosa 3.5.1.35 foi distribuída pelo canal oficial de atualizações Pro durante aproximadamente 6 horas antes de ser detetada pelo Patchstack.

Quatro camadas de persistência

O malware do Smart Slider foi excecionalmente sofisticado, instalando quatro backdoors independentes que sobreviviam mesmo à remoção completa do plugin:

1. Must-Use Plugin — ficheiro em wp-content/mu-plugins/object-cache-helper.php que carrega automaticamente e não pode ser desativado pelo painel
2. Injeção no tema — código malicioso adicionado ao functions.php do tema ativo
3. Ficheiro core falso — wp-includes/class-wp-locale-helper.php com chave de autenticação armazenada em ficheiro oculto
4. Conta de administrador oculta — username wpsvc_ seguido de hash, com email [email protected], escondida das listagens de utilizadores através de filtros no WordPress

Adicionalmente, o malware exfiltrava para o servidor C2 (wpjs1.com): URL do site, versão WordPress e PHP, email do administrador, nome da base de dados, e as credenciais em texto simples da conta oculta.

Não são casos isolados: um padrão crescente

Estes ataques seguem um padrão documentado que remonta a pelo menos 2017:

O padrão “comprar, plantar backdoor, esperar” é particularmente eficaz porque: a dormência permite que a atualização maliciosa se propague ao máximo de instalações via auto-updates; a inatividade gera confiança; e o WordPress.org não tem mecanismo para auditar mudanças de propriedade retroativamente.

Porque é que o WordPress.org não impede isto?

O repositório oficial do WordPress.org tem lacunas estruturais que facilitam ataques supply chain:

• Sem verificação de transferência de propriedade — quando um plugin muda de mãos, a confiança, reputação e privilégios de auto-update transferem-se automaticamente para o novo dono, sem auditoria
• Sem assinatura criptográfica — os ficheiros ZIP são distribuídos via SVN sem assinatura digital (ao contrário do npm que exige 2FA e provenance attestation)
• Revisão apenas na submissão inicial — plugins novos são revistos, mas não existe revisão quando um plugin existente muda de proprietário
• Equipa sobrecarregada — em 2025, as submissões semanais duplicaram de ~150 para ~330, mas o tamanho da equipa manteve-se inalterado

Em outubro de 2024, o WordPress.org introduziu 2FA obrigatório para autores de plugins. Mas o ataque EssentialPlugin contornou esta medida porque o atacante era legitimamente o dono da conta.

O seu site está comprometido? Como verificar

Se o seu site usa (ou usou) algum dos plugins afetados, verifique imediatamente:

Ficheiros suspeitos

• wp-comments-posts.php na raiz do WordPress (NÃO é um ficheiro core — o legítimo é wp-comments-post.php, no singular)
• wp-content/mu-plugins/object-cache-helper.php
• wp-includes/class-wp-locale-helper.php e wp-includes/.cache_key
• wp-math-captcha.dat e wp-math-captcha.dat.tmp na raiz

Verificação do wp-config.php

O seu wp-config.php deve terminar com require_once ABSPATH . 'wp-settings.php';. Qualquer código PHP após essa linha, especialmente referências a analytics.essentialplugin.com ou verificações de HTTP_USER_AGENT, indica compromisso.

Base de dados

• Procure contas de administrador desconhecidas, especialmente com padrão wpsvc_* ou nomes como “PluginAUTH”, “PluginGuest”, “Options”
• Verifique as opções: _wpc_ak, _wpc_uid, _wpc_uinfo, _perf_toolkit_source

Verificação de integridade via WP-CLI

Se tem acesso à linha de comandos, pode verificar a integridade dos ficheiros core:

wp core verify-checksums
wp plugin verify-checksums --all

Estes comandos comparam os ficheiros instalados com os originais do WordPress.org e reportam quaisquer modificações.

Como proteger o seu site contra ataques supply chain

1. Minimize o número de plugins

Cada plugin é uma superfície de ataque. Faça uma auditoria regular e remova (não apenas desative — elimine) plugins que não usa. Um plugin desativado mantém os seus ficheiros acessíveis no servidor.

2. Investigue antes de instalar

Antes de instalar qualquer plugin, verifique:

• Data da última atualização (abandono = risco)
• Historial do autor no fórum de suporte
• Número de instalações ativas
• Se houve mudanças recentes de propriedade

3. Use monitorização de vulnerabilidades

Ferramentas como o Patchstack fornecem alertas antecipados de 48 horas com virtual patching — bloqueiam exploits antes mesmo de os developers lançarem correções. O Wordfence (5 milhões de instalações) oferece firewall, scanner de malware e monitorização em tempo real.

4. Controle as atualizações automáticas

Paradoxalmente, as atualizações automáticas são simultaneamente uma proteção (aplicam patches de segurança rapidamente) e um vetor de ataque (propagam código malicioso sem revisão). Como explicámos no nosso artigo sobre o que acontece quando não atualiza o seu WordPress, manter o site atualizado é essencial — mas deve ser feito com método. A estratégia recomendada:

• Core WordPress — atualizações menores automáticas (patches de segurança)
• Plugins — atualizações manuais após verificação em ambiente de staging

5. Mantenha backups verificados

A regra 3-2-1: três cópias, dois tipos de armazenamento, uma cópia offsite. E o mais importante: teste regularmente a restauração. O backup que nunca foi testado pode não funcionar quando precisar dele. Apenas 27% dos donos de sites têm um plano de recuperação documentado.

6. Implemente monitorização de integridade de ficheiros

Configure alertas automáticos para alterações em ficheiros críticos, especialmente wp-config.php e o diretório /wp-content/plugins/. Qualquer alteração fora de uma janela de manutenção planeada deve ser investigada. Um site bem otimizado e monitorizado, como descrevemos no nosso guia sobre PageSpeed Insights e performance WordPress, facilita a deteção de anomalias.

O custo de não agir

O custo médio de recuperação de um ciberataque para uma PME é de 14.500 EUR. Um serviço de manutenção e monitorização profissional custa a partir de 25 EUR por mês — menos do que um almoço de equipa.

Os números não deixam margem para dúvidas: 60% das pequenas empresas que sofrem um ciberataque sério fecham nos 6 meses seguintes. E com o tempo médio entre a divulgação de uma vulnerabilidade e a sua exploração a ser de apenas 5 horas, a janela para reagir é cada vez mais curta.

O futuro: Cyber Resilience Act europeu

A partir de setembro de 2026, o Cyber Resilience Act da União Europeia começará a impor novos requisitos a developers de software, incluindo plugins WordPress: auditorias de segurança obrigatórias, processos formais de divulgação de vulnerabilidades e notificação de incidentes. As multas podem chegar aos 15 milhões de euros.

Isto significará mudanças significativas no ecossistema WordPress nos próximos anos — e, esperamos, uma maior proteção para os utilizadores.

Conclusão

Os ataques supply chain representam uma mudança fundamental na paisagem de ameaças ao WordPress. Já não basta ter passwords fortes e manter o site atualizado — é preciso questionar a cadeia de confiança por trás de cada componente do seu site.

A boa notícia: com monitorização ativa, uma política rigorosa de plugins, backups testados e ferramentas de deteção adequadas, é possível reduzir drasticamente o risco.

Na OnePixel, a segurança dos sites dos nossos clientes é uma prioridade desde o primeiro dia. Se tem dúvidas sobre a segurança do seu site WordPress, ou se quer garantir que está protegido contra este tipo de ameaças, fale connosco. Fazemos auditorias de segurança completas e oferecemos planos de manutenção contínua que incluem monitorização, backups verificados e resposta a incidentes.