- O mesmo atacante adquiriu mais de 30 plugins do WordPress e, no primeiro commit, inseriu código de backdoor, comprometendo a cadeia de suprimentos
- O código malicioso ficou dormente por cerca de 8 meses e foi ativado no início de abril de 2026, injetando links de spam e redirecionamentos em vários sites
- O WordPress.org desativou permanentemente 31 plugins relacionados em 7 de abril de 2026 e distribuiu uma atualização forçada
- O atacante adquiriu o portfólio ‘Essential Plugin’ no Flippa por um valor de seis dígitos e usou smart contracts da Ethereum para ocultar o domínio de C2
- O caso reproduz, em grande escala, um ataque de cadeia de suprimentos semelhante ao incidente de ‘Display Widgets’ de 2017, expondo a falta de gestão de confiança no ecossistema de plugins do WordPress
Caso de ataque à cadeia de suprimentos de plugins do WordPress
- Mais de 30 plugins do WordPress foram adquiridos pelo mesmo atacante e depois receberam backdoors
- O atacante comprou o portfólio ‘Essential Plugin’ no Flippa por uma quantia de seis dígitos e adicionou código malicioso já no primeiro commit
- O backdoor permaneceu inativo por 8 meses e foi ativado no início de abril de 2026, infectando inúmeros sites
- O WordPress.org desativou permanentemente 31 plugins relacionados em um único dia, em 7 de abril de 2026
- O caso é avaliado como uma repetição do padrão de ataque à cadeia de suprimentos semelhante ao incidente de ‘Display Widgets’ de 2017
Descoberta do ataque e resposta inicial
- A primeira infecção foi identificada por meio de um alerta de segurança no wp-admin de um site cliente
- A equipe de plugins do WordPress.org alertou que o plugin “Countdown Timer Ultimate” continha código que permitia acesso não autorizado
- O WordPress.org distribuiu uma atualização forçada (v2.6.9.1), mas alguns sites já estavam comprometidos
- A análise de segurança mostrou que o módulo
wpos-analyticsdo plugin se conectava a analytics.essentialplugin.com para baixar o arquivowp-comments-posts.php, por meio do qual era feita uma injeção em larga escala de código PHP no wp-config.php
Como o malware funciona
- O código injetado buscava links de spam, redirecionamentos e páginas falsas de um servidor C2 e os exibia apenas para o Googlebot
- O atacante usava smart contracts da Ethereum para gerenciar dinamicamente o domínio de C2
- Como o domínio era consultado via endpoint RPC da blockchain, não podia ser bloqueado por meios comuns de bloqueio de domínio
- A atualização forçada do WordPress.org apenas interrompeu a função de “phone home” do plugin, enquanto o código malicioso no wp-config.php permaneceu intacto
Rastreamento do momento da infecção via análise de backups
- Usando os backups restic do CaptainCore, foi feita a comparação do tamanho de 8 versões do arquivo
wp-config.php- Entre 04:22 e 11:06 UTC de 6 de abril de 2026, o tamanho do arquivo aumentou de 3.345 bytes para 9.540 bytes
- Confirmou-se que a infecção ocorreu nesse intervalo de 6 horas e 44 minutos
Momento da inserção do backdoor e estrutura do código
- Na versão 2.6.7 do plugin (8 de agosto de 2025), foram adicionadas 191 novas linhas de código, inserindo o backdoor
- No changelog constava “compatibilidade confirmada com WordPress 6.8.2”
- Principais funções do código adicionado
fetch_ver_info()processa dados do servidor do atacante com@unserialize()version_info_clean()executa o nome de função recebido dos dados remotos- Criação de endpoint REST API acessível sem autenticação (
permission_callback: __return_true)
- Essa estrutura permite execução arbitrária de funções (RCE) e permaneceu inativa por 8 meses, até ser ativada em 5–6 de abril de 2026
Processo de aquisição dos plugins
- A equipe original de desenvolvimento era a WP Online Support, sediada na Índia, que desenvolvia plugins desde 2015
- Depois fez rebranding para Essential Plugin e operava mais de 30 plugins gratuitos e pagos
- No fim de 2024, após uma queda de 35% a 45% na receita, a empresa colocou todo o negócio à venda no Flippa
- No início de 2025, a aquisição foi feita por uma pessoa chamada ‘Kris’, com experiência em SEO, criptomoedas e marketing de jogos de azar online
- O Flippa publicou a transação em seu blog em julho de 2025 como caso de sucesso
- No primeiro commit em SVN após a aquisição (8 de agosto de 2025), o código de backdoor foi adicionado imediatamente
- Em 5–6 de abril de 2026,
analytics.essentialplugin.comcomeçou a distribuir a carga maliciosa para todos os sites - Em 7 de abril de 2026, o WordPress.org desativou permanentemente todos os plugins da Essential Plugin (31 ao todo)
Lista de plugins desativados
- Mais de 30 plugins, incluindo Accordion and Accordion Slider, Countdown Timer Ultimate, Popup Anything on Click, WP Blog and Widgets, WP Team Showcase and Slider
- Não há resultados ao pesquisar esse autor no WordPress.org
analytics.essentialplugin.comatualmente retorna a resposta{"message":"closed"}
Casos semelhantes no passado
- Em 2017, uma pessoa chamada ‘Daley Tias’ comprou o plugin Display Widgets (com 200 mil instalações) por US$ 15.000 e inseriu código de spam
- Depois, mais de 9 plugins foram comprometidos da mesma forma
- Este caso confirma a repetição do mesmo método em escala ainda maior (mais de 30 plugins)
Recuperação dos danos e trabalho de patch
- A atualização forçada do WordPress.org foi apenas uma medida temporária
- O próprio módulo
wpos-analyticsainda continuava presente
- O próprio módulo
- Foi criada internamente uma versão corrigida que remove completamente o módulo de backdoor
- Entre 22 sites de clientes, plugins da Essential Plugin foram encontrados em 12, e 10 deles foram corrigidos manualmente
- A versão corrigida remove o diretório
wpos-analytics, elimina a função loader e adiciona-patchedao nome da versão
- Exemplos: Countdown Timer Ultimate, Popup Anything on Click, WP Testimonial with Widget
Como aplicar o patch manualmente
- Excluir o diretório
wpos-analytics/ - Remover, no arquivo principal do plugin, o bloco “Plugin Wpos Analytics Data Starts” ou
wpos_analytics_anl - Adicionar
-patchedao cabeçalhoVersion:e compactar novamente - Instalar com
wp plugin install your-plugin-patched.zip --force - Se o tamanho do arquivo
wp-config.phptiver aumentado cerca de 6 KB, deve ser considerado infecção ativa, exigindo recuperação completa
Problema de confiança no ecossistema de plugins do WordPress
- Nas últimas 2 semanas, ataques à cadeia de suprimentos ocorreram em sequência
- Plugins confiáveis são adquiridos e depois recebem código malicioso
- O direito de commit no WordPress.org é herdado e a distribuição ocorre sem nova verificação
- O WordPress.org não possui monitoramento de mudança de propriedade nem processo de reavaliação de código
- Não há alerta ao usuário nem revisão automática quando um novo committer é registrado
- A resposta da equipe de plugins foi rápida, mas o backdoor inserido permaneceu sem detecção por 8 meses
- Administradores de sites WordPress devem revisar a lista de plugins e remover ou corrigir imediatamente plugins da linha Essential Plugin, além de verificar obrigatoriamente o arquivo
wp-config.php
7 comentários
WordPress há décadas em uso...
Uso o mínimo possível de plugins, mas mesmo assim fico sempre inseguro.
Ainda assim, continua sendo mais prático do que estático, então não quero migrar!
Foi assim mesmo. Houve um aumento repentino.
WordPress é realmente... continua dando problema. Se você já usa, consulte os posts relacionados e veja algo como o EmDash.
Eu já abandonei e simplesmente migrei para uma página estática.
Instalei o EmDash, mas, por enquanto, ele é lento demais. O TTFB fica em algo como 3 segundos no mínimo, então dá a impressão de que isso foi mesmo feito para ser usado.
Ah, entendi. Então vou me contentar com algo estático mesmo hehe
Isso acaba fazendo a gente pensar que IA talvez consiga substituir CMSs cobertos de código legado pelo gerenciamento de páginas estáticas.
Comentários do Hacker News
As reações exageradas ao Mythos sempre me fazem rir
A tecnologia automatizada de detecção de vulnerabilidades pode até abalar o setor de segurança, mas isso não é o verdadeiro motivo de preocupação
A stack tecnológica atual e a governança corporativa já estão defasadas
Se for para apontar o principal culpado por piorar a situação, é a criptomoeda. Isso transformou hacking em uma indústria de bilhões de dólares e até atraiu Estados como a Coreia do Norte
Agora já é uma realidade simplesmente comprar dependências ou pagar funcionários para induzir um “erro”
Podemos escrever software quase sem bugs, mas não temos um plano para manter grandes empresas seguras nesse ambiente
Agentes autônomos com LLM serão usados por grupos de ransomware, mas não há necessidade de usar exploits de FreeBSD
Na prática, toda semana encontro bugs em PrimeVue, Vue, Spring Boot, Oracle driver, Ansible, Nvidia driver etc.
Realisticamente, código completamente sem falhas talvez só seja possível em aviões ou espaçonaves
A maioria dos desenvolvedores não deixa de escrever código sem bugs por falta de vontade, mas porque muitas vezes isso é impossível por causa de restrições do ambiente
Isso não é teoria, é realidade. Com financiamento em nível estatal, comprar insiders é muito mais fácil
Projetos OSS têm menos “bugs WTF” do que software corporativo
Em um ambiente individual, erros que ninguém cometeria por bom senso acabam sendo publicados em organizações por causa de processos de aprovação ou práticas estabelecidas
Uma cultura disfuncional em que não se pode perguntar “isso é realmente o melhor?” produz bugs em massa
Em times pequenos é fácil mudar isso, mas em grandes organizações o custo é alto
Quando olho projetos web, tudo sempre começa com “npm install”, e dezenas de bibliotecas são instaladas automaticamente
Muitas vezes nem o próprio autor sabe quais dependências transitivas foram incluídas
Numa estrutura assim, a chance de verificar ataques à cadeia de suprimentos é praticamente zero
Recentemente escrevi uma ferramenta de sincronização meteorológica só com a biblioteca padrão do Python
Não precisei usar pacotes externos como
requests, e ganhei a tranquilidade de não ter dependênciasLógica crítica como criptografia não deve ser implementada manualmente, mas depender de bibliotecas até para funções simples é exagero
Se a versão estiver fixada, mesmo que um pacote seja vendido e receba um backdoor, você não será afetado até atualizá-lo manualmente
O que assusta mais é quando o Dependabot abre automaticamente PRs de “versão de patch” e acaba introduzindo risco
sudo curl URL | bashAcho que a própria ideologia de atualização de software é o problema
Atualizações têm a vantagem dos patches de segurança, mas ao mesmo tempo podem impor mudanças que o desenvolvedor não quer ou até se tornarem maliciosas
Especialmente no caso de extensões do WordPress de desenvolvedores independentes, acho melhor nunca permitir atualização automática
O marketplace do wordpress.org não oferece suporte a uma estrutura assim, o que é arriscado
Eu já tinha escrito um comentário sobre extensões do Chrome, e se você trocar Chrome por WordPress ele continua valendo integralmente
A superfície de ataque da cadeia de suprimentos dos plugins do WordPress já era perigosa há muito tempo
Isso se deve à estrutura do ecossistema, que incentiva a instalação de muitos plugins pequenos criados por desenvolvedores individuais
Adquirir e abusar de plugins que já conquistaram confiança é um método de ataque extremamente eficiente
Como a “notificação de atualização” funciona como sinal de confiança, os usuários nem percebem que o autor mudou
Precisamos de um sistema de assinatura de pacotes e transparência, mas o WordPress melhora sua infraestrutura de segurança muito devagar
A página de administração chegava a parecer um meme de toolbar do IE6
Muitas vezes eles só instalavam a versão gratuita do Securi ou do Wordfence, sem nem configurar direito, e esperavam segurança total
Malware explícito até é bloqueado, mas práticas de bait-and-switch como inserir widgets de anúncios a partir de domínios de terceiros são toleradas
Nesse nível, quase dá para considerar uma característica intencional do sistema
É uma pena que o projeto FAIR package manager não tenha dado certo
O fair.pm tem uma estrutura distribuída inspirada no atproto, que qualquer um pode operar sem repositório central
Os pacotes são identificados por DID, e entidades como a Socket podem anexar resultados de análise como “labelers”
O usuário pode bloquear pacotes com determinados rótulos ou até operar seu próprio labeler de análise de segurança com IA
Não é perfeito, mas é uma abordagem muito melhor do que package managers centralizados
Atualmente estão cooperando com a comunidade Typo3 e expandindo para outros ecossistemas (o autor é cochair da FAIR)
A estrutura de incentivos é melhor que a do WordPress, mas ainda pode não ser suficiente
A descentralização dá liberdade, mas do ponto de vista do usuário, a inconveniência é grande
O ponto interessante deste caso é que o plugin foi adquirido via Flippa
O Flippa não é um marketplace exclusivo de WP, mas um mercado geral de compra e venda de software
Isso aumenta a preocupação de que apps ou extensões indie adquiridos de boa-fé possam mais tarde ser transformados em arma
Esses apps podem valer mais para atacantes do que para operadores legítimos
O mais assustador não é o backdoor em si, mas o fato de a aquisição ter parecido perfeitamente normal
Comprar um plugin confiável e publicar atualizações não se distingue de manutenção legítima
Não há nenhum sinal para o usuário desconfiar
Fusões e aquisições que limitam a concorrência no mercado às vezes recebem aprovação do governo
Então fico pensando se aquisições com grande impacto em segurança também não deveriam exigir aprovação de marketplace ou do governo
Veja o artigo da Wikipédia sobre Mergers and acquisitions
O WordPress foi ótimo por causa dos plugins, mas agora, por causa dessa mesma estrutura, tornou-se um ecossistema perigoso
Eu migrei para o Hugo e recomendo a outros este guia de migração
Parece que as empresas não perceberam direito quanto controle perderam ao fazer “terceirização de TI”