Hackers exploram falha em plugins BdThemes e assumem controle administrativo de sites WordPress
Pesquisadores de segurança identificaram um sofisticado ataque à cadeia de suprimentos envolvendo a BdThemes, desenvolvedora de diversos plugins populares para WordPress. A campanha maliciosa levou a equipe responsável pelo diretório oficial de plugins da plataforma a retirar temporariamente do ar vários complementos afetados, bloqueando novos downloads enquanto é feita uma auditoria completa do incidente.
Ao contrário de muitos ataques à cadeia de suprimentos em que os criminosos adulteram diretamente o código-fonte hospedado no repositório oficial, neste caso nenhum arquivo dos plugins no WordPress.org foi modificado. O vetor principal de comprometimento foi um fluxo remoto de dados em formato JSON, consumido pelos plugins apenas para exibir banners e conteúdos promocionais dentro do painel administrativo do WordPress.
De acordo com análises técnicas, os invasores conseguiram explorar esse mecanismo aparentemente inofensivo para injetar código malicioso em sites administrados por usuários legítimos. Assim, bastava que um administrador autenticado acessasse o painel para que o JavaScript malicioso fosse executado em segundo plano, sem qualquer interação adicional.
Entre os plugins atingidos pela campanha estão, entre outros, Element Pack Addons for Elementor, presente em mais de 100 mil sites, e Live Copy Paste for Elementor, Ultimate Store Kit, Pixel Gallery Addons for Elementor, Prime Slider Addons for Elementor, Smart Admin Assistant e Ultimate Post Kit Addons for Elementor, todos com milhares de instalações ativas. As páginas desses plugins no diretório de extensões do WordPress passaram a exibir o status de “fechado” em 7 ou 8 de agosto de 2026, indicando que estão temporariamente indisponíveis até a conclusão da revisão de segurança.
O elo central dessa cadeia de ataque é um componente interno chamado Biggopti, distribuído junto com os plugins da BdThemes. Essa biblioteca é responsável por buscar, em um servidor de API, dados sobre banners promocionais e conteúdos informativos, armazenados em arquivos JSON hospedados em um bucket na infraestrutura de armazenamento em nuvem DigitalOcean Spaces. O objetivo original era apenas exibir anúncios ou mensagens no painel, mas a forma como esses dados eram processados acabou abrindo uma brecha crítica.
A investigação apontou uma vulnerabilidade de cross-site scripting (XSS) no tratamento das respostas JSON retornadas pela API Sigmative, mais especificamente no parâmetro “display_id”. O conteúdo desse parâmetro não passava por sanitização ou validação adequadas no lado do cliente. Com isso, qualquer parte que conseguisse alterar as respostas da API poderia inserir scripts que seriam executados diretamente no navegador do administrador logado.
Como o código é carregado em páginas do “wp-admin”, a área administrativa do WordPress, o ataque é particularmente perigoso: o JavaScript malicioso herda os privilégios da sessão do administrador que está utilizando o painel. Isso permite desde a criação de novos usuários com privilégios elevados até a instalação de plugins adicionais e a modificação de configurações sensíveis. A falha recebeu pontuação CVSS 5.4, classificada como severidade média, mas na prática o impacto é alto devido ao contexto privilegiado em que o código é executado.
Os pesquisadores rastrearam a origem da introdução dessa vulnerabilidade ao plugin “bdthemes-prime-slider-lite”, em uma atualização datada de 1º de março de 2026. Posteriormente, o mesmo padrão de código teria sido replicado em outros plugins do portfólio, ampliando a superfície de ataque. O diferencial da campanha é que tudo acontece por meio da infraestrutura de API e do armazenamento remoto de JSON, sem que os criminosos precisem distribuir versões adulteradas dos plugins ou comprometer diretamente os servidores dos sites.
A análise indica que os atacantes obtiveram acesso de escrita ao bucket utilizado pela BdThemes para armazenar os arquivos JSON. A partir desse ponto, substituiram o conteúdo legítimo por respostas especialmente preparadas para explorar a falha de XSS. Assim que os plugins buscavam os dados atualizados, o código malicioso era entregue e executado em navegadores de administradores autenticados.
O script injetado, ao ser executado, desencadeia uma série de ações automatizadas: ele cria novas contas administrativas não autorizadas, instala um plugin adicional contendo um web shell e estabelece comunicação com uma infraestrutura remota de comando e controle (C2). Dessa forma, os criminosos conseguem manter acesso persistente ao ambiente mesmo que a vulnerabilidade original seja corrigida posteriormente.
O principal payload é distribuído por um endpoint conhecido como “api-data-all-records”. Um arquivo JavaScript identificado como “w2.js” é responsável por contatar o servidor de comando e controle, hospedado em um domínio dedicado, e enviar dados sobre a origem do site comprometido. Com base nessas informações, o servidor decide quais instruções serão retornadas, permitindo aos invasores adaptar o ataque ao perfil de cada alvo.
Quando o C2 autoriza a invasão de um determinado site, o script utiliza a API REST do WordPress para criar uma nova conta com privilégios administrativos. Em seguida, baixa um arquivo ZIP apresentado como se fosse um plugin legítimo e aciona o mecanismo padrão de instalação de plugins da plataforma. Dentro desse pacote está um web shell PHP, nomeado “emer-run.php”, que oferece aos criminosos controle direto sobre o ambiente.
Depois de implantado, o web shell instala dois mecanismos de persistência no diretório de plugins obrigatórios do WordPress, conhecido como “mu-plugins”. O primeiro implementa uma espécie de porta dos fundos, permitindo acesso administrativo sem autenticação quando um parâmetro específico é adicionado à URL do site. O segundo atua como componente de ocultação, interferindo em consultas ao banco de dados para esconder contas maliciosas e manipular a contagem de usuários exibida na interface administrativa, dificultando a detecção manual da invasão.
Além do payload principal, os pesquisadores encontraram um segundo conjunto de código malicioso, denominado “x.js”, entregue por outro endpoint da mesma API e hospedado na própria infraestrutura do desenvolvedor. Esse script não depende de comunicação contínua com o C2 para gerar contas maliciosas: ele produz credenciais administrativas determinísticas a partir do hostname do site comprometido.
O algoritmo embutido no “x.js” calcula de forma previsível nomes de usuário e senhas com base no domínio do site. Isso significa que os operadores da campanha conseguem, em qualquer momento futuro, reconstruir localmente as credenciais de acesso para um site previamente comprometido, sem precisar manter um banco de dados centralizado com a lista de alvos. Por outro lado, essa característica oferece às equipes de resposta a incidentes uma pista importante para identificar contas criadas pelo ataque, já que as combinações seguem um padrão lógico.
Uma vez geradas as credenciais, o script cria um novo usuário com privilégios de administrador e registra informações sobre o comprometimento, que posteriormente são enviadas ao servidor de comando e controle. Esse modelo híbrido, que combina payloads dependentes de C2 com mecanismos de acesso determinístico, aumenta a resiliência da campanha mesmo diante da derrubada de parte da infraestrutura maliciosa.
Os analistas ainda relacionaram a infraestrutura de comando e controle usada nessa operação a pelo menos outros dois incidentes recentes, levantando a hipótese de que se trata de um grupo organizado que tem o WordPress e seu ecossistema de plugins como foco estratégico. O reaproveitamento de domínios, endereços IP e padrões de código sugere uma campanha contínua, em evolução, e não um ataque isolado.
Para administradores de sites que utilizam plugins da BdThemes, o risco não se resume à instalação de novas contas e web shells. Uma vez com acesso privilegiado, os invasores podem adulterar conteúdo, redirecionar visitantes para páginas de phishing, injetar malwares em arquivos de tema, roubar dados pessoais ou corporativos armazenados no banco de dados e até integrar o servidor a redes de bots usadas para outros ataques.
A natureza do ataque também ilustra um problema mais amplo: a dependência de componentes de terceiros que fazem chamadas a serviços externos a partir do painel administrativo. Mesmo funcionalidades aparentemente simples, como exibir banners ou mensagens promocionais, podem se tornar vetores de alto impacto quando não são tratadas com rigor em termos de validação de dados e controle de origem.
Especialistas recomendam que desenvolvedores de plugins adotem políticas de hardening no consumo de dados remotos, como sanitização estrita de qualquer conteúdo dinâmico, uso de listas de permissões para domínios confiáveis, validação de assinaturas digitais e minimização de lógica executada no lado do cliente com privilégios administrativos. Além disso, é fundamental revisar periodicamente bibliotecas internas, como o Biggopti, que podem ser reutilizadas em vários produtos e, portanto, multiplicar o impacto de uma única falha.
Para proprietários e gestores de sites, algumas medidas podem reduzir significativamente o risco em cenários semelhantes:
– manter todos os plugins e temas sempre atualizados;
– desinstalar extensões que não sejam estritamente necessárias;
– utilizar contas administrativas apenas quando indispensável, operando no dia a dia com perfis de menor privilégio;
– monitorar logs de acesso e alterações de usuários;
– ativar autenticação em duas etapas para contas privilegiadas;
– adotar soluções de segurança que verifiquem integridade de arquivos e comportamento anômalo no painel.
No contexto específico deste incidente, é recomendável que administradores que utilizaram qualquer um dos plugins afetados verifiquem cuidadosamente a lista de usuários em busca de contas desconhecidas, examinem o diretório “mu-plugins” em busca de arquivos suspeitos e revisem plugins instalados recentemente sem ação explícita do administrador. Se houver sinais de comprometimento, a orientação é revogar todas as chaves de API, redefinir senhas, remover arquivos maliciosos e, sempre que possível, restaurar o ambiente a partir de um backup anterior ao incidente.
O caso da BdThemes reforça a importância de tratar o ecossistema de plugins do WordPress como parte crítica da superfície de ataque de qualquer site. A combinação de uma vulnerabilidade aparentemente intermediária, como um XSS classificado como severidade média, com o contexto privilegiado do painel administrativo, demonstrou ser suficiente para levar ao controle total de milhares de instalações, evidenciando que a avaliação de risco precisa considerar não apenas a nota técnica, mas também o cenário em que a falha se manifesta.