Um atacante alterou arquivos JavaScript confiáveis usados por sites WordPress que utilizam PushEngage, OptinMonster e TrustPulse, transformando esses arquivos em uma forma de invadir os sites.
Quando um administrador do site estava logado enquanto o arquivo era carregado, o código criava uma conta de administrador sob o controle do atacante e instalava um plugin oculto que abria uma porta de entrada. Visitantes comuns não ativavam isso.
Qualquer site afetado deve ser considerado comprometido. Os três plugins são gerenciados por uma empresa, a Awesome Motive, que não havia comentado sobre os dois plugins maiores até 15 de junho.
A empresa de segurança Sansec revelou a campanha mais ampla em 13 de junho, encontrando o mesmo código malicioso em JavaScript servido para os três plugins.
A PushEngage seguiu um dia depois com seu próprio aviso de incidente, confirmando que um atacante havia servido cópias alteradas de seu script e que sites que os carregavam poderiam ser comprometidos.
A PushEngage, adquirida pela Awesome Motive há anos, é até agora a única dos três plugins a emitir orientações; usuários do OptinMonster e do TrustPulse não receberam nenhuma comunicação oficial.
A janela de exposição não foi a mesma para cada plugin. A Sansec viu o código malicioso no OptinMonster e no TrustPulse por apenas cerca de 25 minutos em 12 de junho, primeiro por volta das 22h17 UTC e desaparecido até as 22h42. A exposição da PushEngage durou mais: várias horas em 12 de junho, e seu script ainda estava sendo servido por alguns servidores de CDN até 14 de junho.
Então, os dois plugins com mais sites tiveram a menor janela, e a PushEngage teve a maior.
A Sansec estima que os três plugins alcançam mais de 1,2 milhão de sites no total, a maior parte sendo OptinMonster, que sozinho tem mais de um milhão de instalações ativas. O plugin WordPress da PushEngage tem mais de 9.000. Esse número é de alcance, não de dano: conta os sites que executam os plugins, não os sites que foram invadidos.
Como o ataque funcionou
O script infectado não fazia nada em uma visualização normal da página. Agia apenas quando um administrador WordPress logado o carregava, usando então a sessão desse administrador para assumir o controle.
Esse design também é o motivo pelo qual o painel do WordPress não pode dizer se você foi afetado: o backdoor é construído para ficar fora das telas de administração, então a única verificação confiável é no próprio servidor.
No caso da PushEngage, os arquivos alterados eram seus scripts normais de incorporação, pushengage-web-sdk.js e pushengage-subscription.js, servidos a partir de clientcdn.pushengage.com, a rede de distribuição de conteúdo (CDN, na sigla em inglês) que entrega o script da PushEngage aos sites dos clientes. O OptinMonster e o TrustPulse foram comprometidos através de endpoints de CDN separados da Awesome Motive.
A PushEngage afirma que o resto de seus sistemas não foi afetado: não encontrou sinais de que seu aplicativo principal ou os servidores que armazenam dados de clientes tenham sido acessados.
Segundo a própria conta da PushEngage, assim que o script era executado com um administrador logado, ele:
- usava a sessão desse administrador para agir com permissões completas,
- criava uma nova conta de administrador sob o controle do atacante,
- instalava um plugin que não aparece no painel, e
- enviava os novos detalhes de login e informações do site para tidio[.]cc, um domínio falso criado para parecer com o legítimo tidio.com.
A Sansec encontrou a mesma sequência nos três plugins. O domínio tidio[.]cc foi registrado em 28 de abril, semanas antes do ataque, o que aponta para uma operação planejada em vez de um ataque rápido.
O plugin oculto é o verdadeiro prêmio. Ele abre o que é conhecido como web shell, um canal de comando remoto: qualquer pessoa que conheça a URL correta pode executar código no servidor sem fazer login. A partir daí, o atacante pode ler ou alterar qualquer arquivo, copiar o banco de dados, plantar mais backdoors, injetar código de captura de cartões, redirecionar visitantes ou roubar dados.
A conta de administrador extra é uma forma simples de voltar a ter acesso se você excluir o plugin mas esquecer da conta. E como o atacante pode executar código livremente, remover o plugin nomeado e a conta pode não ser suficiente; tanto a Sansec quanto a PushEngage dizem para assumir que outros backdoors podem permanecer.
Como o atacante entrou
Esta é a parte em que as duas contas discordam. A PushEngage diz que o atacante primeiro invadiu o servidor que executa seu site de marketing, através de uma falha conhecida no UpdraftPlus, um plugin de backup do WordPress. Esse servidor é separado dos sistemas que executam o produto e armazenam dados de clientes.
O que importava não era o servidor em si, mas uma chave presente nele: uma chave de API de CDN. Com essa chave, o atacante não precisava invadir os sistemas principais da PushEngage. Ele podia simplesmente alterar os arquivos que o CDN já estava entregando aos sites dos clientes.
A Sansec não está convencida de que o ponto de entrada esteja definido. Diz que o sistema comprometido ainda é desconhecido, com os servidores próprios da Awesome Motive sendo o lugar mais provável, a conta de CDN sendo possível, e o provedor de CDN, a BunnyNet, sendo improvável.
A análise pública da Sansec não examina nem endossa a teoria do UpdraftPlus; essa conta vem apenas da PushEngage, sobre seu próprio ambiente. O UpdraftPlus tem um bug separado de bypass de autenticação, CVE-2026-10795, que o Wordfence classifica como 8.1 (alta severidade); agora está corrigido, e o Wordfence reportou ataques contra ele, então qualquer pessoa que use o UpdraftPlus deve atualizar, independentemente de qualquer coisa.
Se esse bug teve alguma relação com essa invasão não está confirmado. Trate o ponto de entrada como não definido.
O que verificar e fazer
Segundo a linha do tempo da Sansec, os arquivos do OptinMonster e do TrustPulse estavam limpos em 13 de junho, enquanto o script da PushEngage permaneceu em alguns servidores de CDN até 14 de junho. A PushEngage diz que ainda está definindo a janela exata e desde então substituiu os arquivos comprometidos, limpou o cache do CDN, mudou a chave do CDN e todas as credenciais relacionadas, e moveu o site de marketing para uma nova infraestrutura.
Nada disso limpa um site que já foi comprometido.
Porque o backdoor se esconde do painel, você não pode descartar um comprometimento olhando para o WordPress. Se o seu site executou qualquer um dos três plugins durante a janela de ameaça, a única resposta confiável é uma varredura do lado do servidor.
Não tente resolver adivinhando se você estava logado; a maioria dos proprietários não consegue provar isso de qualquer forma. Trate os passos abaixo como o mínimo necessário.
- Execute uma varredura do lado do servidor. Qualquer pessoa que teve PushEngage, OptinMonster ou TrustPulse ativo durante a janela deve escanear o servidor diretamente. Uma verificação pelo navegador ou painel vai perder um payload que só era executado para admins logados. (A Sansec viu o mesmo payload nos três plugins, mas não confirmou que o OptinMonster e o TrustPulse foram entregues da mesma forma ou na mesma janela que a PushEngage.)
- Verifique o sistema de arquivos, não o painel. Em wp-content/plugins, procure pastas chamadas content-delivery-helper ("Content Delivery Helper") ou database-optimizer ("Database Optimizer"). Confie no que está no disco. Delete quaisquer contas de administrador que você não criou, especialmente developer_api1 ou qualquer coisa que combine com dev_xxxxxx.
- Verifique seus logs. Revise os logs de acesso do servidor web de 12 a 14 de junho UTC em busca de tráfego de saída para tidio.cc, incluindo seus caminhos /cdn-cgi/, e para o servidor do atacante em 84.201.6.54.
- Se encontrar qualquer coisa, assuma o pior. Troque tudo: senhas de administrador, chaves de API, credenciais de banco de dados e as chaves secretas (salts) em wp-config.php. Com execução de código no servidor, mais persistência pode permanecer.
