Uma campanha de ataques vem explorando duas vulnerabilidades distintas de Cross-Site Scripting (XSS) armazenado em plugins populares do WordPress, usando exatamente o mesmo código malicioso para se infiltrar nos sites afetados. A Plustag IA acompanhou tentativas de exploração contra ambas as falhas e, em todos os casos registrados, o mesmo arquivo JavaScript foi baixado a partir do domínio imgcdn1.com. Até o momento, dois plugins foram confirmados como vetores de ataque, mas o número final pode ser maior.
A primeira observação ocorreu em 4 de outubro de 2026, quando se identificou uma tentativa de exploração da falha CVE-2026-93836, presente no plugin WPC Product Bundles for WooCommerce. No dia seguinte, o mesmo payload foi detectado novamente, desta vez explorando a vulnerabilidade CVE-2026-94504, encontrada no plugin Ninja Forms.
Campanha de XSS no WordPress usa mesmo payload em dois plugins diferentes
O script distribuído nos ataques não se trata de um simples scanner de vulnerabilidades nem de uma prova de conceito. Trata-se, na verdade, de um implante de pós-exploração e persistência projetado para ser executado diretamente no navegador de um administrador autenticado do WordPress.
Assim que é acionado, o código malicioso aproveita a sessão autenticada da vítima na área wp-admin para instalar um plugin fraudulento, criar uma nova conta de administrador, ativar um mecanismo adicional de persistência oculto e enviar os resultados da invasão para uma infraestrutura controlada pelos atacantes.
A análise do plugin instalado revelou um gerenciador de arquivos não autenticado, escondido por trás de sete camadas de ofuscação, além de um segundo script responsável por criar um administrador invisível na tela de usuários do WordPress. Esse mesmo script instala uma URL de login secreta, capaz de autenticar como se fosse o proprietário original do site, e ainda altera as datas dos próprios arquivos para que pareçam mais antigos do que a própria instalação do WordPress.
Detalhes das vulnerabilidades exploradas
A primeira falha identificada, CVE-2026-93836, afeta o WPC Product Bundles for WooCommerce até a versão 8.6.6 e permite que um valor numérico de quantidade, aparentemente válido, passe pela validação do sistema enquanto carrega código malicioso adicional. Esse valor acaba sendo armazenado nos metadados do pedido do WooCommerce e, posteriormente, renderizado de forma insegura.
Nas requisições observadas em 4 de outubro, o payload foi enviado por meio do parâmetro woosb_ids[…][qty], combinando um prefixo numérico seguido de uma tag de script.
Já a segunda falha, CVE-2026-94504, está presente no Ninja Forms até a versão 3.15.3. O plugin armazena envios de campos de texto não formatado controlados pelo atacante e pode renderizá-los sem a devida codificação segura de HTML no editor administrativo legado de submissões. Dessa forma, ao visualizar o envio comprometido, o JavaScript injetado é executado dentro do contexto administrativo do WordPress. A versão 3.15.4 já corrigiu o problema, reforçando o escape de saída na tela administrativa afetada.
Nesse segundo caso, o payload foi enviado pelo endpoint normal de AJAX do Ninja Forms, localizado em /wp-admin/admin-ajax.php com o parâmetro action=nf_ajax_submit, inserindo o valor malicioso em múltiplos campos do formulário.
Embora os métodos de injeção sejam adaptados a cada contexto vulnerável, o código de pós-exploração permanece centralizado na mesma infraestrutura dos atacantes — e é justamente esse segundo estágio compartilhado que conecta as duas tentativas a uma única campanha.
Como funciona o script malicioso x.js
O arquivo x.js recuperado durante a análise é um script de pós-exploração e persistência feito sob medida para o WordPress. Ele apresenta ofuscação leve, principalmente por meio de tabelas de strings codificadas e buscas indiretas de funções.
O fluxo geral de execução segue a seguinte sequência: exploração do XSS armazenado no wp-admin, resolução da origem do site, comunicação inicial com o servidor de comando e controle (C2), instalação do plugin, criação do administrador oculto, busca pelo arquivo emer-run.php e, por fim, envio do relatório de volta ao C2.
O ponto mais relevante é que o próprio JavaScript não depende de uma segunda vulnerabilidade no lado do servidor — ele simplesmente utiliza funcionalidades administrativas legítimas do WordPress, aproveitando a sessão já autenticada do administrador.
A sessão do administrador sequestrada silenciosamente
Um aspecto importante é que o malware nunca rouba o cookie do administrador. Como o JavaScript é executado dentro do contexto de segurança do próprio site comprometido, as requisições de mesma origem para /wp-admin/ carregam automaticamente a sessão do usuário já autenticado. Com isso, o script consegue carregar páginas administrativas privilegiadas, captura os nonces de CSRF exigidos para ações administrativas legítimas e os reutiliza para executar essas mesmas ações por conta própria.
Por isso, cookies do tipo HttpOnly não oferecem proteção nesse cenário, já que o JavaScript em nenhum momento lê o cookie diretamente — ele apenas se aproveita da sessão autenticada do administrador, herdando todas as permissões que esse usuário possui.
Comunicação com o servidor de comando e controle
Antes de executar qualquer ação de persistência, o malware entra em contato com o endereço https://imgcdn1.com/fz/c.php?xa=check&site=. A resposta recebida contém campos de estado como plugin, admin, emer e skip, que permitem ao servidor de comando e controle identificar quais etapas do ataque já foram concluídas em determinada vítima.
O malware também guarda informações de execução localmente no navegador, em uma chave de Local Storage que começa com __xp_v9_. As etapas bem-sucedidas são registradas como plugin, admin e emer, sendo que um comprometimento completo acaba sendo marcado como all — o que evita repetições desnecessárias caso o XSS armazenado seja executado mais de uma vez.
Os dados de status são enviados de volta usando diversos mecanismos do navegador, entre eles fetch(), navigator.sendBeacon() e uma alternativa baseada em requisição de imagem, o que aumenta as chances de o servidor de comando e controle receber o resultado mesmo que a navegação seja interrompida no meio do processo.
Instalação do plugin malicioso
Utilizando a sessão da vítima, o script acessa a página /wp-admin/plugin-install.php?tab=upload, extrai o nonce de upload necessário, baixa um arquivo ZIP a partir de https://imgcdn1.com/fz/c.php?xa=pkg e o envia para instalação dentro do próprio painel administrativo do site comprometido.
Diante desse cenário, administradores de sites WordPress que utilizam o WPC Product Bundles for WooCommerce ou o Ninja Forms devem verificar com urgência se estão nas versões corrigidas pelos respectivos fabricantes. Como a exploração depende apenas de uma sessão autenticada já aberta no navegador, medidas tradicionais como a proteção de cookies HttpOnly não são suficientes — reforçando a importância de atualizações constantes e de monitoramento ativo contra tentativas de injeção de scripts maliciosos.
Com informações de patchstack.com.
