Aviso de Segurança de Setembro de 2026

A Brevo divulgou dois incidentes de segurança separados em setembro de 2026 envolvendo sua plataforma de clientes e infraestrutura.

O primeiro envolveu acesso não autorizado a 138 contas de clientes da Brevo, com várias contas posteriormente usadas para distribuir emails de phishing através da infraestrutura legítima da Brevo.

Dias depois, um comprometimento separado envolvendo o ambiente Cloudflare da Brevo resultou na entrega de JavaScript malicioso através de sites controlados pela Brevo e ativos incorporados por clientes.

Pesquisadores de segurança independentes estimam que o segundo incidente teve o potencial de alcançar mais de 100.000 sites usando componentes da Brevo.

Juntos, os incidentes destacam uma realidade cada vez mais importante para organizações que dependem de plataformas de email e marketing de terceiros:

Infraestrutura confiável ainda pode se tornar um canal de ataque quando os sistemas ou contas que a controlam são comprometidos.

Eles também levantam uma questão importante para organizações cujos domínios permanecem configurados com DMARC em p=none:

Seu domínio está realmente aplicando proteção contra uso não autorizado, ou apenas o está monitorando?

I. O Que Aconteceu na Brevo?

A Brevo divulgou dois incidentes de segurança distintos em setembro de 2026.

Incidente 1: Comprometimento de Conta SSO SAML

Em 10 de setembro de 2026, a Brevo identificou um problema de segurança envolvendo sua implementação de Single Sign-On SAML.

De acordo com o relatório oficial de incidente da Brevo, um invasor explorou um problema de limite de autorização para obter acesso a:

138 contas de clientes da Brevo

A Brevo relatou que:

• 6 contas foram usadas para enviar emails de phishing.
• Contatos foram exportados de 43 contas.
• 93 contas não mostraram atividade significativa do invasor.

A Brevo identificou o problema aproximadamente às 06:30 UTC em 10 de setembro e declarou que a rota de acesso havia sido fechada por volta das 08:30 UTC.

A empresa também desconectou todos os usuários ativos em sua plataforma.

Segundo a Brevo, o invasor criou uma conta Brevo, configurou SSO e convidou usuários legítimos da Brevo para aquele ambiente.

O problema ocorreu porque a autenticação através da configuração de SSO de uma organização não foi adequadamente restrita a essa organização.

Em vez disso, o invasor pôde obter acesso a outras organizações às quais esses usuários convidados podiam acessar.

A Brevo descreveu a causa raiz como um limite de autorização que não havia sido corretamente aplicado.

II. Phishing Foi Enviado Através da Infraestrutura Legítima da Brevo

Um dos aspectos mais importantes da divulgação da Brevo é que as mensagens de phishing não foram simplesmente mensagens falsificadas enviadas de infraestrutura não relacionada.

Elas foram enviadas através da infraestrutura legítima da Brevo.

A Brevo declarou explicitamente que:

As mensagens passaram nas verificações normais de autenticação de email porque se originaram de infraestrutura legítima.

Essa distinção é crítica.

SPF, DKIM e DMARC podem determinar se um email está tecnicamente autenticado.

Eles respondem perguntas como:

• Este servidor estava autorizado a enviar?
• A mensagem foi assinada criptograficamente?
• O domínio de envio autenticado está alinhado com o domínio From visível?

Mas eles não podem responder:

A conta autorizada em si estava sendo controlada por um invasor?

Se um invasor comprometer uma conta legítima em uma plataforma autorizada e enviar mensagens através de infraestrutura corretamente configurada, as mensagens resultantes podem passar com sucesso em SPF, DKIM e DMARC.

É por isso que a autenticação de email deve ser vista como uma camada de uma arquitetura de segurança de email mais ampla.

III. Um Segundo Incidente da Brevo Ocorreu Quatro Dias Depois

Em 14 de setembro de 2026, a Brevo sofreu um segundo incidente de segurança tecnicamente diferente.

A Brevo confirmou que um invasor obteve uma chave de API Cloudflare de longa duração com permissões completas de conta.

Segundo a Brevo, essa credencial havia sido armazenada no código-fonte da aplicação.

O invasor usou a chave de API comprometida para implantar um Cloudflare Worker malicioso dentro do ambiente da Brevo.

Esse Worker era capaz de modificar o tráfego que passava pela infraestrutura CDN da Brevo.

Por aproximadamente cinco horas e meia, JavaScript malicioso foi injetado em:

• brevo.com
• sendinblue.com
• Páginas de login, conta e integração da Brevo
• sibforms.com
• Formulários da Brevo
• Widgets de Conversas da Brevo
• Carregadores de SDK da Brevo
• Arquivos JavaScript incorporados por clientes da Brevo em seus próprios sites

A Brevo relatou que a janela de impacto principal durou aproximadamente:

Das 15:01 UTC até 20:30 UTC em 14 de setembro.

O Ataque ClickFix

Visitantes afetados pelo JavaScript malicioso podiam ver uma página de verificação Cloudflare falsa.

A página instruía usuários do Windows a realizar ações incluindo:

1. Pressionar Win + R
2. Colar um comando
3. Executar esse comando

Seguir essas etapas fazia com que malware fosse baixado no computador da vítima.

Essa técnica é comumente referida como ClickFix.

A Brevo também relatou que, em sites WordPress que incorporavam componentes Brevo afetados, o script malicioso tentava instalar e ativar um plugin quando um administrador WordPress conectado visitava o site.

A Brevo removeu o Cloudflare Worker malicioso, revogou as credenciais comprometidas, excluiu nomes de host controlados pelo invasor e purgou caches de borda afetados.

A empresa declarou que os scripts comprometidos agora são seguros para uso.

IV. Mais de 100.000 Sites Potencialmente Expostos

A Brevo não publicou um número exato de sites de clientes que carregaram o JavaScript afetado.

No entanto, pesquisa de segurança independente da Sansec estimou que os componentes incorporados da Brevo estavam presentes em mais de 100.000 sites.

Isso não significa que 100.000 sites foram necessariamente comprometidos ou que todo visitante recebeu malware.

O conteúdo malicioso foi servido seletivamente.

No entanto, o potencial alcance de distribuição demonstra o efeito de amplificação criado quando infraestrutura JavaScript confiável de terceiros é comprometida.

Este é um risco clássico de cadeia de suprimentos.

Em vez de comprometer organizações individuais uma de cada vez, um invasor pode comprometer infraestrutura que milhares de organizações já confiam.

V. Dois Incidentes, Dois Problemas de Segurança Diferentes

É importante não combinar os dois incidentes tecnicamente.

Eles envolveram caminhos de ataque diferentes.

10 de Setembro

Vetor de ataque: Falha de autorização SSO SAML

Impacto: Acesso não autorizado a 138 contas de clientes

Resultado: Emails de phishing enviados através de contas legítimas de clientes da Brevo e dados de contato exportados de algumas contas

14 de Setembro

Vetor de ataque: Credencial de API Cloudflare comprometida

Impacto: JavaScript malicioso injetado em sites da Brevo e recursos incorporados por clientes

Alcance potencial: Mais de 100.000 sites de acordo com pesquisa de segurança independente

Resultado: Entrega de malware ClickFix e tentativa de persistência no WordPress

VI. O Que Isso Tem a Ver Com DMARC?

Nenhum dos incidentes foi causado por DMARC.

E nenhum dos incidentes deve ser representado como algo que o DMARC sozinho poderia ter prevenido.

No entanto, os incidentes destacam por que as organizações devem entender exatamente como serviços de terceiros são autorizados a usar seus domínios.

A documentação atual da Brevo fornece aos clientes uma configuração DMARC usando:

v=DMARC1; p=none; rua=mailto:[email protected]

Uma política DMARC p=none é válida.

Mas é importante entender o que ela significa.

p=none Significa Monitoramento

Sob o padrão DMARC atual, um domínio configurado com:

p=none

está operando em Modo de Monitoramento.

Sistemas de recebimento de email podem avaliar DMARC e gerar dados de relatório, mas o proprietário do domínio não está solicitando tratamento restritivo baseado especificamente em uma falha DMARC.

Isso torna p=none extremamente útil durante a implantação inicial de DMARC.

As organizações podem descobrir:

• Quais sistemas estão enviando email usando seu domínio
• Se o SPF está alinhado
• Se o DKIM está alinhado
• Quais plataformas de terceiros estão autorizadas
• Qual infraestrutura desconhecida pode estar se passando pelo domínio

Mas p=none não é aplicação de DMARC.

VII. Monitoramento DMARC vs Aplicação

Existem três estados principais de política DMARC.

p=none

Monitoramento

Fornece visibilidade sobre autenticação e alinhamento.

Nenhuma preferência de tratamento restritivo é solicitada com base em falha DMARC.

p=quarantine

Aplicação

Solicita que receptores tratem mensagens que falham em DMARC de forma mais restritiva.

Dependendo do provedor receptor, isso pode envolver colocação em spam, quarentena ou outro tratamento.

p=reject

Aplicação Mais Forte

Expressa a preferência de política DMARC mais forte para mensagens que falham na validação DMARC.

Provedores receptores, em última análise, retêm controle sobre a disposição final de uma mensagem.

A distinção prática é:

p=none monitora.

p=quarantine e p=reject aplicam uma política.

p=none Causou os Incidentes da Brevo?

Não.

Este ponto é importante.

No incidente de 10 de setembro, invasores obtiveram acesso a contas legítimas da Brevo.

Se uma conta Brevo comprometida envia email através de infraestrutura Brevo adequadamente autenticada, essas mensagens podem passar com sucesso em DMARC.

Mudar um domínio de:

p=none

para:

p=reject

não necessariamente bloquearia uma mensagem maliciosa autenticada originada de uma conta autorizada comprometida.

DMARC não analisa a intenção ou conteúdo de um email.

DMARC responde uma pergunta diferente:

Esta mensagem está autenticada e alinhada com o domínio que afirma representar?

Essa distinção é fundamental.

VIII. Então Por Que a Aplicação de DMARC Importa?

Considere um invasor diferente.

Este invasor não comprometeu a Brevo.

Ele não tem acesso ao Microsoft 365.

Ele não tem acesso ao Google Workspace.

Ele não controla nenhuma plataforma legitimamente autorizada a enviar email em nome da organização.

Em vez disso, o invasor simplesmente tenta enviar:

From: [email protected]

usando infraestrutura controlada pelo invasor.

Se essa infraestrutura não pode fornecer autenticação SPF ou DKIM alinhada com empresa.com, a mensagem falha em DMARC.

Com:

p=none

o proprietário do domínio está principalmente monitorando a falha.

Com uma política de aplicação como:

p=quarantine

ou:

p=reject

a organização expressa uma política de tratamento restritivo para aquela mensagem falhada.

Essa é uma das funções de segurança mais importantes do DMARC.

Ela reduz a capacidade de um invasor de personificar diretamente um domínio protegido usando infraestrutura não autorizada.

p=none É Frequentemente o Ponto de Partida Correto

As organizações não devem simplesmente mover todos os domínios imediatamente para p=reject.

Fazer isso sem entender o ambiente de envio da organização pode interromper emails legítimos.

Organizações modernas podem enviar email através de:

• Microsoft 365
• Google Workspace
• Salesforce
• HubSpot
• Brevo
• Zendesk
• Plataformas de marketing
• Sistemas de faturamento
• Sistemas de CRM
• Plataformas de RH
• Provedores de email transacional
• Sistemas de tickets
• Plataformas de segurança
• Aplicações internas

Antes da aplicação, esses sistemas precisam ser descobertos e corretamente autenticados.

É por isso que p=none é frequentemente um estágio de implantação apropriado.

A questão é se deve permanecer como a postura de segurança permanente.

IX. DMARC Implantado Nem Sempre Significa DMARC Aplicado

Esta distinção é frequentemente negligenciada.

Um domínio pode ter um registro DMARC válido enquanto ainda opera inteiramente em Modo de Monitoramento.

Por exemplo:

v=DMARC1; p=none;

significa que DMARC está presente.

Mas o domínio não passou para aplicação.

É por isso que as organizações devem distinguir entre:

Implantação de DMARC

e:

Aplicação de DMARC

Elas não são sinônimas.

X. Conformidade Mínima Não É Proteção Máxima

Principais provedores de caixas de correio cada vez mais exigem autenticação de remetentes em massa.

Esses requisitos melhoraram substancialmente a segurança de email em todo o ecossistema.

Mas muitos requisitos de remetente aceitam:

p=none

como uma política DMARC mínima.

A palavra importante é:

mínima

Uma empresa pode, portanto, satisfazer um requisito de remetente em massa enquanto ainda opera seu domínio em Modo de Monitoramento.

Para empresas, instituições financeiras, empresas regulamentadas e marcas de alto valor, conformidade regulatória ou de plataforma não deve automaticamente ser considerada a mesma coisa que proteção máxima de domínio.

XI. Clientes da Brevo Devem Revisar Sua Configuração DMARC Atual

A Brevo atualmente fornece aos clientes uma política DMARC usando:

v=DMARC1; p=none; rua=mailto:[email protected]

Organizações usando a Brevo devem verificar se esta é também a política de segurança DMARC mais ampla da organização.

Deve haver apenas um registro DMARC válido por domínio.

As organizações devem, portanto, evitar publicar registros DMARC concorrentes simplesmente porque múltiplas plataformas de email solicitam autenticação.

Remetentes de terceiros devem, em vez disso, ser incorporados à arquitetura de autenticação existente da organização.

XII. As Organizações Devem Remover a Brevo?

Não simplesmente por causa desses incidentes.

Se a Brevo permanece como um sistema de negócios legítimo ativamente usado pela organização, remover abruptamente registros de autenticação pode interromper emails legítimos.

Em vez disso, as organizações devem reavaliar a relação de confiança.

1. Confirmar Que a Brevo Ainda É Necessária

Toda plataforma externa autorizada a usar um domínio corporativo deve ter um propósito comercial legítimo atual.

Plataformas não utilizadas não devem permanecer indefinidamente autorizadas.

2. Revisar a Segurança da Conta Brevo

As organizações devem revisar:

• Contas de administrador
• Configuração de SSO
• Usuários privilegiados
• Credenciais de API
• Credenciais SMTP
• Configuração de MFA
• Logs de acesso à conta

3. Revisar Sua Política DMARC

Determine se o domínio da organização atualmente opera em:

p=none

p=quarantine

ou:

p=reject

Não assuma que a existência de um registro DMARC significa que o domínio está aplicando DMARC.

4. Identificar Todos os Remetentes Autorizados

As organizações devem entender todas as plataformas atualmente enviando email usando seus domínios.

Infraestrutura de envio desconhecida deve ser investigada.

5. Validar Alinhamento SPF e DKIM

Serviços de envio legítimos devem satisfazer DMARC através de SPF e/ou DKIM corretamente alinhados.

Isso permite que emails legítimos continuem enquanto infraestrutura não autorizada é identificada.

6. Avançar Para Aplicação Quando Apropriado

Uma vez que remetentes legítimos foram descobertos e autenticados, as organizações devem avaliar se continuar indefinidamente em Modo de Monitoramento reflete sua postura de segurança desejada.

7. Não Publicar Múltiplos Registros DMARC

Um domínio deve ter uma política DMARC coerente.

Adicionar registros DMARC independentes adicionais pode criar uma configuração inválida.

XIII. Ações Adicionais Após o Incidente de 14 de Setembro

Organizações usando componentes de site da Brevo também devem revisar a orientação de remediação da Brevo.

A Brevo recomenda especificamente ação se um usuário interagiu com o conteúdo malicioso em 14 de setembro.

Se o comando ClickFix foi executado

Trate o computador afetado como potencialmente comprometido.

A Brevo recomenda:

• Desconectar o sistema
• Executar uma varredura de segurança completa
• Alterar senhas usadas no dispositivo
• Priorizar credenciais da conta Brevo

Se um administrador WordPress visitou um site afetado

Organizações usando scripts Brevo no WordPress devem revisar plugins instalados ou ativados em 14 de setembro.

A Brevo recomenda remover plugins suspeitos e alterar credenciais de administrador.

Se um usuário fez login na Brevo em 14 de setembro

A Brevo recomenda alterar a senha da conta e revisar credenciais de API como precaução.

XIV. O Que Clientes Skysnag Devem Fazer

Para clientes Skysnag usando Brevo, não há requisito automático para remover a Brevo como remetente autorizado.

A Brevo pode permanecer integrada como uma plataforma de envio legítima enquanto o Skysnag continua a gerenciar a autenticação de domínio mais ampla e política DMARC.

Sua configuração DMARC gerenciada pelo Skysnag existente não deve ser substituída por um registro genérico p=none simplesmente porque a Brevo solicita autenticação de domínio.

O objetivo não é bloquear infraestrutura legítima.

O objetivo é garantir que:

• Serviços legítimos permaneçam autenticados
• Fontes não autorizadas não possam facilmente se passar pelo domínio
• O alinhamento DMARC permaneça correto
• A política de aplicação do domínio permaneça controlada
• Mudanças no ambiente de envio permaneçam visíveis

XV. A Lição de Segurança Maior

Os dois incidentes da Brevo ilustram duas formas diferentes de risco de terceiros.

O primeiro mostrou que:

Uma conta de email legítima pode se tornar um canal de phishing quando a autorização da conta falha.

O segundo mostrou que:

Infraestrutura web confiável pode se tornar um canal de distribuição de malware quando credenciais de infraestrutura são comprometidas.

As organizações dependem cada vez mais de redes interconectadas de:

• Provedores SaaS
• Plataformas de email
• Sistemas de marketing
• CRMs
• Infraestrutura CDN
• Bibliotecas JavaScript
• Provedores de nuvem
• Sistemas de email transacional

Cada integração confiável expande as capacidades operacionais da organização.

Ela também expande seu limite de confiança.

Isso significa que a segurança de domínio moderna deve ser em camadas.

Segurança de conta protege acesso a plataformas autorizadas.

SPF autentica infraestrutura de envio.

DKIM autentica mensagens.

DMARC valida alinhamento de domínio.

Relatórios DMARC fornecem visibilidade.

Aplicação de DMARC fortalece proteção contra personificação direta de domínio não autorizada.

Nenhum controle único resolve todas as classes de ataque.

O objetivo é fazer esses controles trabalharem juntos.

XVI. Monitoramento Deve Levar a uma Decisão de Segurança

DMARC p=none tem um propósito importante.

Ele fornece às organizações a inteligência necessária para entender seu ambiente de envio antes de introduzir aplicação.

Mas o monitoramento é mais valioso quando, em última análise, informa uma decisão de segurança.

Uma vez que remetentes autorizados foram identificados e adequadamente autenticados, as organizações devem determinar se permanecer indefinidamente em p=none reflete o nível de proteção que elas realmente requerem.

Porque há uma diferença importante entre:

Saber que alguém está se passando pelo seu domínio

e:

Publicar uma política destinada a impedir que infraestrutura não autorizada se passe com sucesso por ele.

Monitoramento fornece visibilidade.

Aplicação transforma essa visibilidade em política.

XVII. Verifique Seu Domínio

Se sua organização usa a Brevo e você não tem certeza se seu domínio atualmente opera em p=none, p=quarantine ou p=reject, o Skysnag pode avaliar sua postura atual de autenticação de email, identificar infraestrutura de envio autorizada e determinar um caminho apropriado em direção à aplicação sem interromper desnecessariamente emails legítimos.

Verifique seu domínio com o Skysnag.