O ataque à Brevo transformou um problema aparentemente restrito à infraestrutura de uma empresa em uma campanha de distribuição de malware com alcance potencial de mais de 100 mil sites. Uma chave de API da Cloudflare exposta no código-fonte permitiu que invasores assumissem controle suficiente da infraestrutura de borda da Brevo para alterar respostas entregues pela CDN, sem precisar modificar os servidores de origem.
Durante algumas horas em 14 de setembro de 2026, páginas da própria Brevo e scripts JavaScript incorporados por sites de clientes passaram a carregar código malicioso. A campanha combinou duas estratégias: um golpe ClickFix, direcionado aos visitantes, e uma tentativa de instalar uma backdoor em sites WordPress quando o visitante estava autenticado como administrador. A empresa confirmou posteriormente o comprometimento de uma chave Cloudflare e a utilização de um Cloudflare Worker malicioso.
O caso é especialmente relevante para administradores de sistemas porque demonstra como um ataque à cadeia de suprimentos, ou supply chain attack, pode atingir sites que nunca foram diretamente invadidos. Bastou um componente legítimo de terceiros ser comprometido para que o código malicioso chegasse automaticamente a uma grande quantidade de páginas.
Como o ataque à Brevo comprometeu a infraestrutura
A origem técnica do incidente está em uma chave de API da Cloudflare com permissões amplas, que permanecia codificada no código-fonte de uma aplicação da Brevo. Segundo o relatório pós-incidente da empresa, a credencial era de longa duração e possuía permissões suficientes para permitir a criação e alteração de Workers, rotas e registros DNS em zonas administradas pela companhia.
Isso criou uma situação particularmente perigosa: em vez de explorar diretamente cada site de cliente, os invasores conseguiram comprometer um ponto central da infraestrutura que distribuía conteúdo para esses sites.
A Brevo informou que não encontrou evidências de que o comprometimento tivesse alterado os servidores de origem ou a infraestrutura de entrega de e-mails. O problema estava na camada de distribuição e processamento das respostas.
Imagem: @calgarywebdev
O papel dos Cloudflare Workers na alteração de código
O Cloudflare Workers permite executar código na borda da rede, próximo dos usuários finais. Na prática, isso significa que uma resposta HTTP pode ser modificada antes de chegar ao navegador, mesmo que o arquivo original armazenado no servidor de origem permaneça intacto.
Foi exatamente esse mecanismo que tornou o incidente difícil de detectar por verificações tradicionais de integridade.
O Worker controlado pelos invasores conseguia reescrever respostas entregues pela CDN, acrescentando instruções JavaScript maliciosas aos conteúdos legítimos. A técnica também permitiu remover cabeçalhos de segurança, incluindo o Content-Security-Policy (CSP), que poderia dificultar o carregamento de determinados recursos externos.
A investigação da Sansec encontrou versões modificadas de componentes como o SDK Loader e o widget Brevo Conversations. Uma linha adicional era suficiente para criar dinamicamente um elemento <script> e carregá-lo a partir de uma infraestrutura controlada pelos invasores.
Esse detalhe é importante para administradores: um arquivo localmente íntegro não significa necessariamente que o conteúdo entregue aos visitantes esteja íntegro quando existe uma camada de CDN, proxy ou processamento na borda.
Janela de exposição e subdomínios atingidos
A atividade maliciosa foi observada em 14 de setembro, durante aproximadamente cinco horas e meia. A Brevo informou uma janela de exposição entre 16h07 e 20h30 UTC, enquanto a análise independente da Sansec registrou atividade entre aproximadamente 16h05 e 20h13 UTC. As diferenças decorrem dos métodos utilizados para determinar o início e o fim da atividade.
Entre os serviços e domínios afetados estavam brevo.com, sendinblue.com e sibforms.com, além de componentes JavaScript incorporados nos sites dos clientes.
A investigação também identificou subdomínios maliciosos sob sendibt1.com, domínio pertencente à própria infraestrutura da Brevo. Os hosts utilizados na campanha deixaram de resolver em 15 de setembro, e a empresa removeu o Worker, revogou a chave comprometida, eliminou credenciais relacionadas, retirou hosts controlados pelos invasores e realizou a limpeza do cache da borda.
Engenharia social e a tática do ClickFix
Depois de conseguir inserir seu código nos componentes da Brevo, o invasor passou a utilizar uma técnica conhecida como ClickFix.
O golpe exibia uma falsa tela de verificação do Cloudflare, geralmente apresentada como uma etapa para confirmar que o visitante era humano. O objetivo era aproveitar a aparência familiar de uma proteção legítima para induzir a vítima a executar uma ação perigosa.
Em vez de simplesmente clicar em um botão, a página instruía o usuário a realizar uma sequência de comandos no Windows, utilizando recursos como Win+R, colagem do conteúdo da área de transferência e execução.
O detalhe mais perigoso é que o comando podia ser colocado previamente no clipboard. A vítima acreditava estar apenas realizando uma verificação de segurança, mas acabava executando conteúdo fornecido pelo atacante.
Esse tipo de fraude explora diretamente a confiança do usuário. Não é necessário encontrar uma vulnerabilidade no navegador quando a própria vítima é convencida a executar o comando.
No caso da Brevo, o impacto foi ampliado pelo modelo de distribuição: um único código malicioso inserido em componentes compartilhados poderia alcançar visitantes de uma grande quantidade de sites que utilizavam os serviços afetados. A Sansec estimou que mais de 100 mil sites poderiam ter sido expostos.
O impacto direto no WordPress: backdoor e acesso administrativo
O ataque à Brevo teve uma segunda camada especialmente preocupante para administradores de WordPress.
O script malicioso verificava determinadas condições no navegador, incluindo se o visitante estava autenticado como administrador do WordPress. Quando encontrava uma sessão administrativa compatível, a campanha tentava aproveitar essa sessão legítima para instalar um plugin malicioso.
Isso muda completamente o cenário de risco.
Não era necessário explorar uma falha conhecida do WordPress ou descobrir a senha do administrador naquele momento. A própria sessão autenticada do administrador poderia ser utilizada para realizar a instalação.
O plugin malicioso Web Media Optimizer
O componente identificado como Web Media Optimizer aparentava ser um plugin legítimo, mas funcionava como uma backdoor persistente e carregador de JavaScript malicioso.
O arquivo malicioso era distribuído como um pacote de plugin e podia ser instalado por meio das funcionalidades administrativas do WordPress. Depois da instalação, o código procurava ocultar sua presença da interface convencional de gerenciamento de plugins e copiava componentes para a pasta mu-plugins, utilizada pelos chamados must-use plugins.
Essa característica é particularmente relevante durante uma investigação.
Um administrador pode abrir o painel do WordPress, consultar a lista normal de plugins e não encontrar nada suspeito. Entretanto, um código instalado diretamente em wp-content/mu-plugins pode continuar sendo carregado automaticamente.
A análise também identificou comunicação com infraestrutura remota para obter JavaScript adicional. Dessa maneira, o plugin poderia funcionar como uma espécie de ponte entre o WordPress comprometido e a infraestrutura de distribuição da campanha.
Burlar autenticação sem senha
Outro componente grave do Web Media Optimizer era uma chave de autenticação incorporada no próprio plugin.
Segundo a análise publicada sobre o malware, essa chave permitia aos atacantes gerar uma sessão válida de administrador sem conhecer a senha original da conta. Isso transforma a instalação do plugin em um mecanismo de persistência e acesso posterior.
Por esse motivo, encontrar o plugin ou qualquer artefato relacionado deve ser tratado como possível comprometimento da conta administrativa, e não simplesmente como a presença de um plugin indesejado.
Administradores afetados devem considerar a rotação de senhas, sessões, tokens e outras credenciais potencialmente expostas, além da investigação dos registros de acesso.
Guia prático de limpeza e mitigação para administradores
Se você administra um site WordPress que utilizava componentes da Brevo, a prioridade é verificar se houve exposição em 14 de setembro de 2026.
1. Verifique os registros de acesso
Procure nos logs do servidor, WAF, CDN ou proxy atividades incomuns durante a janela aproximada de 16h05 a 20h30 UTC.
Um indicador importante é uma requisição semelhante a:
/wp-admin/update.php?action=upload-plugin
Também merece investigação uma solicitação posterior relacionada à ativação de um plugin.
A ausência desse indicador não elimina o risco, mas sua presença durante o período da campanha deve ser investigada imediatamente. A análise técnica da Sansec recomenda atenção especial a esses eventos.
2. Procure plugins instalados em 14 de setembro
No painel do WordPress, verifique plugins instalados ou ativados na data do incidente.
Não se limite à interface administrativa. Compare a lista apresentada pelo WordPress com o conteúdo físico de:
wp-content/plugins/
e:
wp-content/mu-plugins/
Procure arquivos ou diretórios que não correspondam ao inventário conhecido do site.
3. Investigue o Web Media Optimizer
Qualquer presença inesperada do Web Media Optimizer deve ser considerada um indicador de comprometimento.
Não basta desativar o plugin pelo painel. Como o malware podia ocultar sua presença e utilizar mu-plugins, é necessário revisar os arquivos diretamente no servidor e procurar cópias persistentes.
Antes de apagar evidências, preserve uma cópia para análise forense quando isso for possível.
4. Revogue credenciais potencialmente expostas
Se um administrador acessou o site durante a janela de exposição e havia uma sessão ativa, faça uma rotação das senhas administrativas.
Também é recomendável invalidar sessões existentes e revisar contas administrativas desconhecidas ou criadas recentemente.
Em ambientes profissionais, investigue ainda chaves de API, tokens, credenciais de deploy e acessos SSH que possam ter sido acessados a partir de uma máquina comprometida.
5. Verifique JavaScript externo
Revise os scripts carregados pelo site e compare versões atuais com cópias conhecidas como legítimas.
Componentes de terceiros devem ser tratados como parte da superfície de ataque. Uma dependência aparentemente confiável pode ser alterada na origem, na CDN ou durante a entrega.
Também é recomendável manter uma Content Security Policy (CSP) adequada e monitorar violações. No caso da Brevo, os registros de CSP ajudaram pesquisadores a identificar e medir a atividade maliciosa.
6. Se alguém executou o comando do ClickFix, trate o computador como comprometido
Caso um administrador ou usuário tenha seguido as instruções da falsa verificação e colado e executado um comando, a investigação não deve ficar limitada ao WordPress.
O computador utilizado deve passar por uma análise completa de segurança. Também é prudente alterar credenciais utilizadas nessa máquina, especialmente quando havia acesso administrativo, VPN, SSH, painéis de hospedagem ou sistemas corporativos.
O que o ataque à Brevo ensina sobre segurança de terceiros
O incidente mostra por que a segurança de um site moderno não depende apenas do código instalado no próprio servidor.
Um site pode estar atualizado, utilizar plugins legítimos e não apresentar nenhuma vulnerabilidade conhecida, mas ainda assim carregar um script de terceiros comprometido. Se esse script possui acesso amplo ao DOM, pode alterar a experiência do visitante e, em determinadas condições, participar de uma cadeia de comprometimento muito maior.
Para administradores WordPress, a principal lição é ampliar a auditoria para além do wp-admin. CDNs, scripts externos, widgets, APIs, DNS, Workers e contas de fornecedores também fazem parte da superfície de ataque.
O ataque à Brevo demonstra ainda que credenciais armazenadas no código-fonte, principalmente chaves com privilégios elevados e longa duração, podem transformar uma falha de gestão de segredos em um incidente de escala global.
Se você administra um site WordPress que utiliza Brevo, verifique os registros de 14 de setembro, revise plugins e mu-plugins, procure alterações inesperadas e investigue qualquer execução de comandos associada ao ClickFix. Compartilhar esse alerta com outros administradores também pode ajudar a identificar comprometimentos que ainda não foram percebidos.