Um Comprador Misterioso, 30 Plugins e Meio Milhão de Sites em Risco

Imagine descobrir que aquele plugin WordPress que você instalou há dois anos — aquele que funcionava perfeitamente, que tinha boas avaliações e atualizações regulares — foi comprado por alguém que plantou uma porta dos fundos no código. E que essa porta ficou dormindo por 8 meses antes de acordar.

Não é ficção. Aconteceu na primeira semana de abril de 2026. E se você usa WordPress, provavelmente precisa checar seu wp-config.php agora mesmo.

A Compra que Ninguém Questionou

A história começa em 2015, quando uma equipe indiana chamada WP Online Support começou a publicar plugins gratuitos no WordPress.org. Ao longo dos anos, o portfólio cresceu: Countdown Timer Ultimate, Popup Anything on Click, WP Testimonial with Widget, SP FAQ, Timeline and History Slider — mais de 30 plugins no total, todos com versões premium.

O negócio ia bem. Os plugins tinham centenas de milhares de instalações ativas. Até que um dia, o fundador Minesh Shah decidiu vender tudo. Listou a empresa inteira no Flippa — a plataforma de compra e venda de ativos digitais — e encontrou um comprador.

O comprador se identificava apenas como “Kris”. Background em SEO, cripto e marketing de cassino online. Pagou seis dígitos pelo portfólio inteiro. Rebatizou tudo como “Essential Plugin”.

E o WordPress.org? Não fez absolutamente nada. Não existe nenhum mecanismo para sinalizar ou revisar transferências de propriedade de plugins. Nenhuma notificação de “mudança de controle” para os usuários. Nenhuma revisão adicional de código quando um novo committer aparece.

A transferência aconteceu silenciosamente. E o primeiro commit SVN do novo dono já carregava o backdoor.

191 Linhas que Comprometeram Tudo

Em 8 de agosto de 2025, a versão 2.6.7 foi publicada. O changelog dizia: “Check compatibility with WordPress version 6.8.2”. Parece inofensivo, certo? Afinal, todo mundo atualiza plugins por compatibilidade.

Só que escondidas nessa atualização estavam 191 linhas de código malicioso. Três componentes críticos:

1. Um método fetch_ver_info() que usava file_get_contents() para buscar dados de servidores controlados pelo atacante e passava as respostas para @unserialize() — a função PHP mais perigosa que existe quando alimentada com dados externos

1. Um método version_info_clean() capaz de executar funções arbitrárias a partir de dados desserializados remotamente

1. Um endpoint REST API sem autenticação, com permission_callback: __return_true — literalmente qualquer pessoa na internet poderia acessá-lo

A desserialização PHP é um vetor clássico de Remote Code Execution (RCE). Quando você passa dados não confiáveis para unserialize(), um atacante pode criar objetos arbitrários que executam código durante a destruição. É o tipo de vulnerabilidade que aparece em todo curso de segurança. E estava ali, escondida num plugin “de compatibilidade”.

O Módulo Fantasma: wpos-analytics

Aqui fica realmente engenhoso. Os plugins comprometidos incluíam um módulo chamado wpos-analytics. Nome inocente — parece um sistema de analytics interno, certo?

Na prática, o módulo se conectava a analytics.essentialplugin.com e baixava um arquivo chamado wp-comments-posts.php. Repare no nome: quase idêntico ao arquivo legítimo do WordPress core wp-comments-post.php. A diferença é um “s” no final. Quem olha a listagem de arquivos passa batido.

Esse arquivo, por sua vez, injetava aproximadamente 6KB de PHP diretamente no wp-config.php — o arquivo mais crítico de qualquer instalação WordPress, aquele que contém as credenciais do banco de dados, os salts de segurança e as configurações essenciais.

A injeção era anexada à linha require_once ABSPATH . 'wp-settings.php', garantindo que o código malicioso executasse em toda requisição. Cada page view, cada chamada de API, cada acesso ao admin — tudo passava pelo backdoor.

Blockchain Como Infraestrutura de Comando e Controle

Se a engenharia do backdoor já era sofisticada, a infraestrutura de comando e controle (C2) era de outro nível.

Em vez de usar domínios tradicionais — que poderiam ser derrubados com um simples pedido de takedown — o atacante resolveu os endereços C2 através de smart contracts na Ethereum. O payload injetado consultava endpoints RPC públicos da blockchain para descobrir para onde enviar os dados e de onde receber instruções.

Isso significa que mesmo que pesquisadores de segurança derrubassem todos os domínios envolvidos, o atacante poderia simplesmente atualizar o smart contract para apontar para um novo servidor. Sem downtime. Sem rastro fácil de seguir.

Eu já vi ataques supply chain sofisticados, mas usar a blockchain como dead drop para C2 é um patamar que poucos atingem. O atacante claramente sabia o que estava fazendo.

8 Meses de Silêncio

O detalhe mais perturbador? O backdoor ficou inativo por 8 meses inteiros. De agosto de 2025 a abril de 2026, nenhuma atividade maliciosa visível. O código estava ali, dormindo, passando por todas as verificações de segurança.

Por que esperar tanto?

Primeiro, para construir confiança. Quanto mais tempo um plugin funciona sem problemas após uma atualização, menos pessoas voltam a auditar o código. Segundo, para maximizar a superfície de ataque. A cada mês que passava, mais sites atualizavam para a versão 2.6.7. Mais vítimas entravam na rede.

A ativação aconteceu entre 5 e 6 de abril de 2026. O módulo wpos-analytics começou a baixar o payload, injetar o wp-config.php e servir conteúdo para o C2. O ataque focava em SEO spam: conteúdo oculto servido exclusivamente para o Googlebot, invisível para donos dos sites e administradores. Links de cassino, cripto e farma escondidos nas páginas.

Para o visitante humano, o site continuava normal. Para o Google, era uma fazenda de spam.

A Resposta do WordPress.org (Tarde Demais)

Em 7 de abril de 2026, a equipe de plugins do WordPress.org finalmente agiu. Fecharam permanentemente todos os 31 plugins do autor Essential Plugin em um único dia.

No dia seguinte, 8 de abril, forçaram um auto-update para a versão 2.6.9.1 em todas as instalações. Mas a “correção” foi… questionável.

O que a atualização fez:

• Adicionou instruções return; para pular o código malicioso
• Comentou a linha do backdoor

O que a atualização não fez:

• Remover as injeções no wp-config.php
• Deletar o módulo wpos-analytics inteiro
• Limpar o arquivo wp-comments-posts.php falso

Ou seja: se o seu site já tinha sido comprometido ativamente, a atualização não resolveu nada. O código malicioso no wp-config.php continuava executando normalmente, independente do plugin.

Lista dos Plugins Afetados

Aqui vai a lista parcial dos plugins que foram fechados. Se você tem qualquer um desses instalado, pare o que está fazendo e vá verificar agora:

• Countdown Timer Ultimate
• Popup Anything on Click
• WP Testimonial with Widget
• WP Team Showcase and Slider
• SP FAQ
• Timeline and History Slider
• Album and Image Gallery Plus Lightbox
• SP News and Widget
• WP Blog and Widgets
• Featured Post Creative
• Post Grid and Filter Ultimate
• Logo Showcase Ultimate
• WP Starter starter templates

E mais cerca de 18 outros. Ao todo, centenas de milhares de instalações ativas foram comprometidas.

Um cliente da Anchor.host — a empresa que publicou a investigação original — descobriu que 12 dos seus 26 plugins Essential Plugin estavam presentes em 22 sites diferentes. Todos comprometidos.

O Elefante na Sala: WordPress.org Não Verifica Transferências

Esse ataque expôs uma falha estrutural que muita gente já suspeitava mas ninguém tinha provado de forma tão brutal: o WordPress.org não tem nenhum processo para verificar transferências de propriedade de plugins.

Qualquer pessoa pode comprar um plugin popular — com centenas de milhares de instalações — e receber acesso direto ao SVN para publicar atualizações. Sem verificação de identidade. Sem revisão de código adicional. Sem alerta para os usuários.

É exatamente o mesmo vetor do ataque ao XZ Utils em 2024 — e não é o único ecossistema vulnerável a supply chain attacks, quando o mantenedor original transferiu o projeto para um ator malicioso que plantou um backdoor no SSH. A diferença é que o ecossistema WordPress tem uma superfície de ataque incomparavelmente maior: mais de 43% dos sites da internet rodam WordPress (e há quem argumente que isso precisa mudar).

Fluxo do ataque:

1. Plugin popular (30+, milhares de installs)
2. Compra via Flippa (sem verificação)
3. Acesso SVN concedido automaticamente
4. Commit malicioso (versão 2.6.7)
5. 8 meses dormindo
6. Ativação → C2 via Ethereum
7. SEO spam servido ao Googlebot
8. Detecção → Fechamento (31 plugins)

Como Verificar Se Você Foi Afetado

Se você administra sites WordPress, faça isso agora:

1. Busque os plugins afetados:

wp plugin list --format=csv | grep -iE "(countdown-timer|popup-anything|wp-testimonial|wp-team-showcase|sp-faq|timeline-history|album-image-gallery|sp-news|wp-blog-widgets|featured-post-creative|post-grid-filter|essential-plugin)"

2. Verifique o tamanho do wp-config.php:

O arquivo normalmente tem entre 2KB e 4KB. Se o seu tem mais de 8KB, você provavelmente foi comprometido. Procure por blocos de código após a linha require_once ABSPATH . 'wp-settings.php'.

3. Procure o módulo wpos-analytics:

find /caminho/do/wp-content/plugins/ -type d -name "wpos-analytics"

Se encontrar, delete imediatamente.

4. Procure o arquivo falso:

find /caminho/do/wordpress/ -name "wp-comments-posts.php"

O arquivo legítimo do WordPress é wp-comments-post.php (sem o “s”). Se wp-comments-posts.php existir, é o backdoor.

5. Procure marcadores no código:

grep -r "Plugin Wpos Analytics Data Starts" /caminho/do/wp-content/
grep -r "wpos_analytics_anl" /caminho/do/wp-content/

Por Que Scanners de Segurança Não Pegaram Isso

Você pode estar se perguntando: “mas eu uso Wordfence / Sucuri / iThemes Security — por que não detectou?”

A resposta é simples e incômoda. A maioria dos scanners de segurança WordPress trabalha com assinaturas conhecidas. Eles procuram padrões de malware já catalogados. O backdoor do Essential Plugin era código novo, customizado, e — aqui está o pulo do gato — vinha de uma fonte considerada confiável: o repositório oficial do WordPress.org.

Plugins instalados pelo WordPress.org recebem um nível implícito de confiança. Os scanners geralmente não fazem análise profunda de código em plugins do repositório oficial. Verificam checksums de arquivos core, procuram por assinaturas de malware conhecidas, mas não fazem análise estática de cada atualização de plugin procurando por chamadas a unserialize() com dados externos.

Além disso, o uso do @ antes do unserialize() — o operador de supressão de erros do PHP — garantia que nenhum warning ou notice aparecesse nos logs. O código falhava silenciosamente se algo desse errado e executava sem rastro quando tudo funcionava.

Ferramentas de SAST (Static Application Security Testing) como PHPStan ou Psalm com plugins de segurança teriam flaggado a chamada a unserialize() com dados de file_get_contents(). Mas quem roda SAST em plugins de terceiros? Praticamente ninguém.

O Que Fazer Se Estiver Comprometido

A mera remoção do plugin não basta. Você precisa:

1. Limpar o wp-config.php — remova todo código após a linha require_once ABSPATH . 'wp-settings.php' que não deveria estar ali
2. Deletar o diretório wpos-analytics/ de todos os plugins afetados
3. Remover o wp-comments-posts.php (com “s”) se existir
4. Trocar todas as senhas — banco de dados, admin, salts do WordPress
5. Regenerar os salts em wp-config.php
6. Auditar o banco de dados — busque por usuários admin criados recentemente que você não reconhece
7. Escanear com Wordfence ou Sucuri para encontrar outros vestígios

Não É a Primeira Vez (e Não Será a Última)

Em 2017, um comprador chamado “Daley Tias” comprou o plugin Display Widgets — que tinha 200.000 instalações — por meros $15.000. Usou exatamente a mesma metodologia: comprar, plantar backdoor, lucrar com SEO spam. Acabou comprometendo pelo menos 9 plugins adicionais antes de ser pego.

Quase uma década depois, o WordPress.org continua com o mesmo ponto cego.

A Patchstack também documentou recentemente um comprometimento similar no Smart Slider 3 Pro, e o ecossistema npm sofreu ataque parecido com o LiteLLM, onde o payload transmitia dados para um servidor C2 em wpjs1.com/api/v3/register-agent. O padrão se repete: comprar ou comprometer o acesso, plantar código malicioso, esperar.

Se você depende do WordPress para o seu negócio — e estatisticamente há uma boa chance de que sim — a hora de implementar monitoramento de integridade de arquivos, auditoria regular de plugins e verificação de checksums é agora. Não amanhã. Não depois do próximo ataque.

O WHOIS do Essential Plugin foi atualizado em 30 de agosto de 2025 para “Kim Schmidt” em Zurique, com um email ProtonMail. Ninguém sabe se é uma identidade real. Ninguém sabe quantos outros portfólios de plugins esse mesmo grupo já comprou. E essa é a parte que deveria tirar o sono de quem administra sites WordPress.

Fonte de inspiração: Someone Bought 30 WordPress Plugins and Planted a Backdoor in All of Them — Anchor.host