O ataque à cadeia de suprimentos da BdThemes colocou usuários de diversos plugins WordPress diante de um cenário especialmente perigoso: código malicioso foi entregue por uma infraestrutura externa utilizada pelos próprios plugins, permitindo que invasores executassem ações no contexto de administradores autenticados. A campanha foi identificada pela equipe de inteligência da Wordfence em 7 de agosto de 2026, e os plugins afetados foram temporariamente retirados do diretório oficial do WordPress.org para investigação.
O caso envolve extensões populares do ecossistema Elementor, incluindo Element Pack, Prime Slider, Pixel Gallery, Ultimate Post Kit, Ultimate Store Kit, Live Copy Paste e Smart Admin Assistant. O aspecto mais preocupante é que o ataque não dependia necessariamente da substituição dos arquivos dos plugins: os invasores envenenaram uma resposta JSON remota consumida pelo painel administrativo.
Isso muda completamente a forma como um administrador deve pensar sobre segurança. Uma instalação pode ter arquivos aparentemente legítimos e ainda assim executar código malicioso recebido de um servidor externo. Por isso, atualizar ou reinstalar o plugin, embora importante, não é suficiente quando já existe suspeita de comprometimento.
Como funcionou o ataque à cadeia de suprimentos da BdThemes
O ataque explorou a confiança estabelecida entre os plugins da BdThemes e uma infraestrutura externa responsável por fornecer informações promocionais e conteúdo exibido no painel do WordPress.
De acordo com a investigação publicada pela Wordfence, os atacantes conseguiram comprometer a infraestrutura da BdThemes e modificar a resposta fornecida por uma API. O conteúdo malicioso era então entregue aos sites que utilizavam os plugins afetados.
Esse modelo é particularmente perigoso porque o código malicioso não precisa aparecer dentro do arquivo ZIP distribuído pelo WordPress.org.
Em uma atualização tradicional comprometida, um scanner de integridade pode comparar os arquivos instalados com uma versão conhecida. No ataque da BdThemes, porém, o conteúdo malicioso podia ser obtido em tempo de execução, diretamente da infraestrutura remota.
A diferença é fundamental: o arquivo local continua parecendo legítimo, enquanto a resposta recebida pelo navegador é que foi adulterada.
O papel do feed JSON e da falha XSS
Os plugins afetados utilizavam uma estrutura de conteúdo remoto para apresentar informações no wp-admin. O problema surgiu quando os dados recebidos passaram a ser tratados como confiáveis.
A investigação aponta para uma falha de Cross-Site Scripting (XSS) relacionada ao componente Biggopti. Um dos elementos envolvidos era o parâmetro display_id, utilizado durante o processamento do conteúdo apresentado no painel.
Com a infraestrutura remota comprometida, os atacantes puderam fornecer dados especialmente preparados para explorar essa falha. Em vez de exibir apenas texto ou uma informação promocional, o navegador do administrador podia interpretar parte da resposta como JavaScript executável.
O detalhe mais importante é que a vítima não precisava necessariamente clicar em um link malicioso.
Bastava um administrador autenticado abrir uma página do painel do WordPress que carregasse o conteúdo comprometido. A partir desse momento, o navegador executava o código dentro do contexto da sessão administrativa.
Esse é um dos motivos pelos quais o incidente merece atenção especial: uma integração criada originalmente para exibir notícias ou promoções acabou se transformando em um canal de execução de código privilegiado.
Da execução de JavaScript aos administradores ocultos
Depois da execução do código no navegador do administrador, o ataque podia avançar para ações dentro do próprio WordPress.
Entre os comportamentos observados estão a criação de contas administrativas não autorizadas, instalação de componentes de persistência e implantação de webshells.
Um dos indicadores associados ao incidente é o arquivo emer-run.php. Também foram identificados outros nomes de arquivos e valores no banco de dados que podem indicar a presença de mecanismos de persistência.
A criação de administradores fraudulentos é especialmente grave porque permite que o atacante mantenha acesso mesmo depois que a origem inicial da infecção desaparece.
Em determinados casos, os usuários maliciosos também podem ser ocultados da interface administrativa, dificultando uma verificação superficial. Por isso, a investigação deve incluir o banco de dados e os registros do servidor, e não apenas a tela de usuários do WordPress.
Plugins BdThemes afetados e alcance do incidente
A campanha atingiu uma quantidade relevante de extensões da BdThemes. Entre os plugins apontados estão:
- Element Pack
- Prime Slider
- Pixel Gallery
- Ultimate Post Kit
- Ultimate Store Kit
- Live Copy Paste
- Smart Admin Assistant
O Element Pack e o Prime Slider merecem atenção especial por sua presença no ecossistema de plugins para Elementor. A documentação oficial da BdThemes confirma o relacionamento desses produtos e outros componentes da empresa.
A Wordfence informou que os plugins afetados foram temporariamente fechados no diretório oficial do WordPress.org enquanto a investigação prosseguia.
O episódio também não deve ser confundido com uma única vulnerabilidade convencional de plugin. O problema envolve uma cadeia de confiança inteira: fornecedor, infraestrutura remota, resposta JSON, código responsável por processá-la e navegador do administrador.
Isso explica por que o incidente é mais relevante do que simplesmente descobrir uma falha XSS isolada.
Como verificar se o site foi comprometido
Administradores que utilizaram os plugins afetados devem considerar a possibilidade de comprometimento e realizar uma investigação.
O primeiro passo é revisar todos os usuários administrativos. Procure contas que não foram criadas pela equipe, endereços de e-mail desconhecidos, nomes incomuns e usuários adicionados recentemente.
Quando possível, a verificação deve ser feita também diretamente no banco de dados, principalmente porque contas maliciosas podem ser manipuladas para dificultar sua visualização no painel.
Depois, faça uma auditoria dos arquivos do servidor. Procure por webshells, backdoors e arquivos PHP inesperados, especialmente em diretórios como:
- wp-content/plugins/
- wp-content/uploads/
- wp-content/mu-plugins/
- diretório raiz da instalação;
- arquivos modificados recentemente.
O nome emer-run.php deve ser tratado como um indicador importante no contexto deste incidente, mas não significa que sua ausência prove que o site esteja limpo.
Também é importante investigar indicadores no banco de dados. Relatos técnicos mencionam valores como fz_emer_login_tokens e fz_emer_done_v1 associados ao comprometimento.
Se forem encontrados indicadores suspeitos, evite simplesmente apagar arquivos. Preserve os logs e evidências, isole o ambiente quando necessário e considere envolver o provedor de hospedagem ou uma equipe especializada em resposta a incidentes.
Como reduzir o risco de novos ataques
A primeira medida é atualizar os plugins afetados para versões consideradas seguras pelo fornecedor, quando essas versões estiverem disponíveis, e remover extensões que não sejam necessárias.
Entretanto, se o site esteve exposto durante a campanha, a atualização deve ser apenas uma parte da resposta. É necessário verificar se o atacante conseguiu criar usuários, alterar arquivos ou estabelecer persistência.
Também é recomendável:
Trocar as credenciais administrativas, incluindo senhas do WordPress, hospedagem, FTP/SFTP, SSH e banco de dados quando houver possibilidade de exposição.
Invalidar sessões existentes, renovando as chaves e salts do WordPress para impedir que sessões potencialmente roubadas continuem válidas.
Revisar logs de acesso, procurando requisições inesperadas ao painel, criação de usuários e alterações administrativas.
Usar um WAF, adicionando uma camada capaz de detectar padrões suspeitos e bloquear determinados comportamentos antes que atinjam a aplicação.
Monitorar alterações de arquivos, principalmente em diretórios graváveis pelo WordPress.
Reduzir privilégios, mantendo o menor número possível de contas com acesso administrativo.
O caso também oferece uma lição importante para desenvolvedores: conteúdo remoto exibido dentro de uma área privilegiada nunca deve ser considerado automaticamente confiável. Respostas de APIs precisam ser validadas, sanitizadas e escapadas de acordo com o contexto.
O que o caso BdThemes ensina sobre segurança no WordPress
O comprometimento da BdThemes mostra que ataques à cadeia de suprimentos podem escapar dos mecanismos tradicionais de detecção.
Um scanner pode verificar os arquivos locais e não encontrar nada porque o conteúdo malicioso está sendo entregue por uma API externa. Da mesma forma, remover o plugin depois do ataque pode não eliminar uma conta administrativa fraudulenta ou um webshell já instalado.
A principal lição é que dependências externas também fazem parte da superfície de ataque.
Para administradores WordPress, isso significa que a auditoria de segurança precisa considerar não apenas temas, plugins e versões instaladas, mas também APIs, feeds, bibliotecas e serviços remotos utilizados por esses componentes.
Para desenvolvedores, o incidente reforça a necessidade de tratar dados externos como não confiáveis desde a origem. Um feed promocional aparentemente inofensivo pode se tornar uma porta de entrada para uma invasão completa quando é renderizado no contexto privilegiado de um administrador.
E para quem administra vários sites, fica uma pergunta incômoda: quantos plugins instalados atualmente podem executar conteúdo remoto dentro do seu painel administrativo sem uma validação independente da origem e da integridade desses dados?
Essa é uma questão que vai muito além da BdThemes. É uma discussão sobre como todo o ecossistema WordPress deve lidar com dependências externas, confiança e segurança da cadeia de suprimentos.