Hackers exploram falha em dados da BdThemes para tomar controle administrativo de sites WordPress
Pesquisadores de segurança descobriram um ataque sofisticado à cadeia de suprimentos envolvendo a BdThemes, desenvolvedora conhecida por seus plugins para WordPress. A campanha maliciosa levou à suspensão temporária de diversos plugins no diretório oficial da plataforma, enquanto uma análise completa é conduzida para avaliar o impacto e corrigir as falhas exploradas.
Ao contrário do que costuma ocorrer em incidentes de supply chain, nenhum arquivo de código-fonte hospedado no repositório WordPress.org foi adulterado. Em vez disso, os atacantes miraram um ponto menos óbvio, porém crítico: o fluxo remoto de dados JSON usado pelos plugins para exibir banners promocionais dentro do painel administrativo dos sites. De acordo com a Wordfence, essa manipulação foi suficiente para permitir a injeção de código malicioso diretamente no navegador de administradores autenticados.
Entre os plugins impactados estão alguns bastante populares no ecossistema do WordPress. O Element Pack Addons for Elementor, que registra mais de 100 mil instalações ativas, aparece como um dos principais afetados. Também foram incluídos na lista 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. As páginas desses plugins no diretório oficial foram fechadas por volta de 7 e 8 de agosto de 2026, permanecendo fora do ar para novos downloads enquanto passam por auditoria.
O problema técnico foi rastreado até um componente interno denominado Biggopti, distribuído junto aos plugins da BdThemes. Essa biblioteca é responsável por buscar, em um servidor de API, os banners e conteúdos promocionais que são exibidos dentro do painel “wp-admin” do WordPress. Para isso, ela consome arquivos JSON armazenados em um bucket no serviço DigitalOcean Spaces, que passaram a ser o elo frágil explorado pelos criminosos.
A Wordfence identificou que o processamento das respostas JSON apresentava uma vulnerabilidade de cross-site scripting (XSS) associada ao parâmetro “display_id” da API Sigmative. O conteúdo retornado por esse parâmetro não recebia tratamento ou sanitização adequados no lado do cliente, abrindo espaço para que dados maliciosos fossem interpretados como código JavaScript. Na prática, qualquer invasor capaz de alterar essas respostas da API poderia fazer com que scripts arbitrários fossem executados dentro do navegador.
Como a funcionalidade afetada é carregada em páginas do painel administrativo do WordPress, o ataque ocorre de forma silenciosa: basta que um usuário com privilégios de administrador acesse o “wp-admin” enquanto o conteúdo adulterado está sendo servido. O JavaScript malicioso é executado em segundo plano, sem qualquer interação adicional. A falha recebeu pontuação CVSS 5.4, sendo classificada como de severidade média, mas com potencial de impacto grave devido ao nível de acesso que pode ser obtido.
A análise histórica do código indica que a alteração vulnerável foi introduzida inicialmente em 1º de março de 2026, no plugin “bdthemes-prime-slider-lite”. Posteriormente, o mesmo padrão de código foi incorporado a outros produtos da BdThemes. O aspecto mais preocupante é que toda a cadeia de ataque ocorre via infraestrutura de API: os plugins legítimos continuam aparentemente intactos, sem atualizações maliciosas nem modificações em arquivos hospedados no servidor do cliente. Toda a malignidade é injetada a partir de respostas remotas.
Segundo os pesquisadores, os invasores conseguiram acesso de escrita ao bucket utilizado pela BdThemes no DigitalOcean Spaces. A partir daí, substituíram as respostas JSON legítimas por versões adulteradas, preparadas para explorar a falha de XSS. Uma vez executado no navegador do administrador, o código malicioso passa a realizar uma série de ações automáticas: cria contas privilegiadas não autorizadas, instala um plugin contendo um web shell e estabelece comunicação com uma infraestrutura de comando e controle (C2), que coordena o restante da operação.
O principal payload distribuído aos sites comprometidos parte do endpoint “api-data-all-records”. Dentro desse fluxo, um arquivo JavaScript identificado como “w2.js” é carregado pelo navegador e passa a se comunicar com um servidor C2 localizado no domínio “ia-cdn[.]com”. Nesse contato inicial, ele envia a origem (domínio) do site comprometido, permitindo que a infraestrutura de comando avalie o alvo e retorne instruções específicas sobre como proceder.
Quando o servidor C2 autoriza a continuação do ataque, o script “w2.js” utiliza a API REST do WordPress para criar uma nova conta administrativa com privilégios totais, tudo sem o conhecimento do verdadeiro administrador. Em seguida, baixa um arquivo ZIP disfarçado como plugin legítimo e usa o próprio mecanismo padrão de instalação de plugins do WordPress para implantar um web shell em PHP, batizado de “emer-run.php”, que se torna a principal porta dos fundos no ambiente.
Esse web shell, por sua vez, instala dois mecanismos de persistência no diretório de “mu-plugins”, destinado a plugins obrigatórios que o WordPress carrega automaticamente. O primeiro mecanismo atua como uma backdoor administrativa, permitindo acesso ao painel sem autenticação, desde que um parâmetro específico seja inserido na URL. O segundo funciona como um componente de ocultação avançado, interceptando consultas ao banco de dados para esconder contas maliciosas da lista de usuários e manipular a contagem apresentada aos administradores, tornando a invasão ainda mais discreta.
Os especialistas também identificaram um payload alternativo, chamado “x.js”, hospedado na própria infraestrutura da desenvolvedora e entregue por um endpoint diferente da API. Esse código tem um papel peculiar: ele gera credenciais administrativas determinísticas com base no hostname do site comprometido. Ou seja, a partir do domínio, é possível calcular matematicamente um par de usuário e senha que será sempre o mesmo para aquele site.
Esse algoritmo de geração previsível permite que os operadores da campanha recuperem o acesso aos sites invadidos a qualquer momento, sem manter um banco de dados central com todos os logins comprometidos. Basta aplicar a mesma fórmula sobre o domínio da vítima para recriar as credenciais. Para equipes de resposta a incidentes, essa característica também é útil: ao entender a lógica, é possível identificar contas administrativas falsas criadas pelo ataque e removê‑las de forma mais eficiente.
Depois de calcular as credenciais, o “x.js” as utiliza para criar um novo administrador malicioso. Em seguida, envia informações detalhadas sobre o comprometimento ao servidor C2, alimentando o painel de controle dos atacantes com o status e as características dos sites afetados. Os pesquisadores ainda relacionaram a infraestrutura de comando e controle empregada nessa campanha a outros dois ataques recentes, o que sugere um grupo ativo e com experiência em explorar falhas em ecossistemas amplamente utilizados.
Para proprietários e administradores de sites WordPress, o incidente expõe um ponto cego comum na gestão de segurança: a confiança irrestrita em conteúdos remotos usados por plugins legítimos. Muitos plugins consomem dados externos para banners, atualizações de templates, notícias do desenvolvedor ou estatísticas, e esses fluxos frequentemente não passam por auditoria de segurança tão rigorosa quanto o código-fonte principal. Quando um invasor compromete esse canal, consegue atingir milhares de sites de uma só vez.
Um aspecto importante desse caso é a dificuldade de detecção. Como os arquivos do plugin instalados no servidor do cliente permanecem, em grande parte, intactos, análises superficiais podem não encontrar nada de anormal. O ponto de entrada está em dados recebidos dinamicamente, que não aparecem em scanners tradicionais de malware baseados apenas em arquivos locais. Portanto, ferramentas de monitoramento de comportamento, de análise de requisições externas e de integridade do painel administrativo tornam-se cada vez mais relevantes.
Para reduzir o risco de ataques semelhantes, especialistas recomendam algumas medidas práticas: revisar periodicamente a lista de plugins instalados e remover aqueles que não são estritamente necessários; priorizar extensões com histórico sólido de atualizações e de resposta a falhas; acompanhar comunicados de segurança dos desenvolvedores; e manter logs detalhados de acessos administrativos, inclusive via API REST. Em cenários como o descrito, a auditoria de logs pode revelar a criação de contas suspeitas ou instalações de plugins em horários ou IPs incomuns.
Outra recomendação é restringir o uso da API REST para ações administrativas sensíveis, especialmente em sites que não dependem diretamente dessas funcionalidades para operações públicas. Há soluções que permitem limitar o acesso à API ou exigir camadas adicionais de autenticação. Além disso, a aplicação de cabeçalhos de segurança no navegador, como Content Security Policy (CSP), pode mitigar parte do impacto de vulnerabilidades XSS ao restringir a execução de scripts provenientes de domínios não autorizados.
Equipes de desenvolvimento de plugins também podem extrair lições importantes do incidente. Qualquer dado obtido de serviços externos – inclusive aqueles operados pela própria empresa – deve ser tratado como potencialmente não confiável. Isso significa validar, sanitizar e escapar adequadamente conteúdos antes de inseri‑los no DOM ou de interpretá‑los como HTML/JavaScript. A adoção de revisões de código focadas em XSS, testes de penetração direcionados a fluxos de API e modelagem de ameaças ajuda a identificar pontos de falha antes que sejam explorados por atacantes.
No curto prazo, administradores que utilizam plugins da BdThemes devem verificar se há atualizações de segurança disponíveis, desativar temporariamente extensões que ainda estejam sob revisão oficial e realizar varreduras em busca de contas administrativas desconhecidas, plugins recém-instalados sem explicação e arquivos suspeitos, como web shells fora do padrão. A exclusão de usuários maliciosos, a remoção de backdoors e a redefinição de senhas de todos os administradores são passos fundamentais na resposta ao incidente.
O caso BdThemes evidencia como a segurança de sites WordPress não depende apenas do núcleo da plataforma, mas de uma cadeia complexa que inclui desenvolvedores de plugins, serviços de hospedagem de arquivos, provedores de API e até buckets de armazenamento em nuvem. Quando qualquer elo dessa cadeia é comprometido, milhares de sites podem ser afetados em efeito cascata. Fortalecer controles em cada ponto e adotar uma postura de desconfiança saudável em relação a conteúdos externos é essencial para reduzir a superfície de ataque e evitar que campanhas semelhantes se repitam.