Aviso de Seguridad de Septiembre de 2026
Brevo ha revelado dos incidentes de seguridad separados en septiembre de 2026 que involucraron su plataforma de clientes e infraestructura.
El primero implicó acceso no autorizado a 138 cuentas de clientes de Brevo, con varias cuentas utilizadas posteriormente para distribuir correos electrónicos de phishing a través de la infraestructura legítima de Brevo.
Días después, un compromiso separado que involucró el entorno de Cloudflare de Brevo resultó en la entrega de JavaScript malicioso a través de sitios web controlados por Brevo y activos integrados por clientes.
Investigadores de seguridad independientes estiman que el segundo incidente tuvo el potencial de alcanzar más de 100,000 sitios web que utilizan componentes de Brevo.
En conjunto, los incidentes resaltan una realidad cada vez más importante para las organizaciones que dependen de plataformas de correo electrónico y marketing de terceros:
La infraestructura confiable aún puede convertirse en un canal de ataque cuando los sistemas o cuentas que la controlan están comprometidos.
También plantean una pregunta importante para las organizaciones cuyos dominios permanecen configurados con DMARC en p=none:
¿Su dominio está realmente aplicando protección contra el uso no autorizado, o solo lo está monitoreando?
I. ¿Qué Sucedió en Brevo?
Brevo reveló dos incidentes de seguridad distintos en septiembre de 2026.
Incidente 1: Compromiso de Cuenta SAML SSO
El 10 de septiembre de 2026, Brevo identificó un problema de seguridad relacionado con su implementación de SAML Single Sign-On.
Según el informe oficial de incidente de Brevo, un atacante explotó un problema de límite de autorización para obtener acceso a:
138 cuentas de clientes de Brevo
Brevo informó que:
- 6 cuentas fueron utilizadas para enviar correos electrónicos de phishing.
- Los contactos fueron exportados de 43 cuentas.
- 93 cuentas no mostraron actividad significativa del atacante.
Brevo identificó el problema aproximadamente a las 06:30 UTC del 10 de septiembre y declaró que la ruta de acceso había sido cerrada aproximadamente a las 08:30 UTC.
La empresa también cerró la sesión de cada usuario activo en toda su plataforma.
Según Brevo, el atacante creó una cuenta de Brevo, configuró SSO e invitó a usuarios legítimos de Brevo a ese entorno.
El problema ocurrió porque la autenticación a través de la configuración SSO de una organización no estaba correctamente restringida a esa organización.
En cambio, el atacante podía obtener acceso a otras organizaciones a las que esos usuarios invitados podían acceder.
Brevo describió la causa raíz como un límite de autorización que no había sido correctamente aplicado.
II. El Phishing Fue Enviado a Través de Infraestructura Legítima de Brevo
Uno de los aspectos más importantes de la divulgación de Brevo es que los mensajes de phishing no fueron simplemente mensajes falsificados enviados desde infraestructura no relacionada.
Fueron enviados a través de infraestructura legítima de Brevo.
Brevo declaró explícitamente que:
Los mensajes pasaron las verificaciones normales de autenticación de correo electrónico porque se originaron desde infraestructura legítima.
Esta distinción es crítica.
SPF, DKIM y DMARC pueden determinar si un correo electrónico está técnicamente autenticado.
Responden preguntas como:
- ¿Este servidor estaba autorizado para enviar?
- ¿El mensaje fue firmado criptográficamente?
- ¿El dominio de envío autenticado se alinea con el dominio From visible?
Pero no pueden responder:
¿La cuenta autorizada en sí misma estaba siendo controlada por un atacante?
Si un atacante compromete una cuenta legítima en una plataforma autorizada y envía mensajes a través de infraestructura correctamente configurada, los mensajes resultantes pueden pasar exitosamente SPF, DKIM y DMARC.
Esta es la razón por la que la autenticación de correo electrónico debe verse como una capa de una arquitectura de seguridad de correo electrónico más amplia.
III. Un Segundo Incidente de Brevo Ocurrió Cuatro Días Después
El 14 de septiembre de 2026, Brevo experimentó un segundo incidente de seguridad técnicamente diferente.
Brevo confirmó que un atacante obtuvo una clave API de Cloudflare de larga duración con permisos completos de cuenta.
Según Brevo, esa credencial había sido almacenada en el código fuente de la aplicación.
El atacante usó la clave API comprometida para implementar un Cloudflare Worker malicioso dentro del entorno de Brevo.
Ese Worker era capaz de modificar el tráfico que pasaba por la infraestructura CDN de Brevo.
Durante aproximadamente cinco horas y media, JavaScript malicioso fue inyectado en:
brevo.comsendinblue.com- Páginas de inicio de sesión, cuenta e incorporación de Brevo
sibforms.com- Formularios de Brevo
- Widgets de Brevo Conversations
- Cargadores SDK de Brevo
- Archivos JavaScript integrados por clientes de Brevo en sus propios sitios web
Brevo informó que la ventana de impacto principal duró aproximadamente desde:
15:01 UTC hasta 20:30 UTC del 14 de septiembre.
El Ataque ClickFix
Los visitantes afectados por el JavaScript malicioso podían ver una página falsa de verificación de Cloudflare.
La página instruía a los usuarios de Windows a realizar acciones que incluían:
- Presionar
Win + R - Pegar un comando
- Ejecutar ese comando
Seguir esos pasos causaba que se descargara malware en la computadora de la víctima.
Esta técnica se conoce comúnmente como ClickFix.
Brevo también informó que, en sitios web de WordPress que integraban componentes de Brevo afectados, el script malicioso intentaba instalar y activar un plugin cuando un administrador de WordPress con sesión iniciada visitaba el sitio.
Brevo eliminó el Cloudflare Worker malicioso, revocó las credenciales comprometidas, eliminó los nombres de host controlados por el atacante y purgó los cachés perimetrales afectados.
La empresa declaró que los scripts comprometidos ahora son seguros de usar.
IV. Más de 100,000 Sitios Web Potencialmente Expuestos
Brevo no ha publicado un número exacto de sitios web de clientes que cargaron el JavaScript afectado.
Sin embargo, una investigación de seguridad independiente de Sansec estimó que los componentes integrados de Brevo estaban presentes en más de 100,000 sitios web.
Esto no significa que 100,000 sitios web fueron necesariamente comprometidos o que cada visitante recibió malware.
El contenido malicioso fue servido selectivamente.
Sin embargo, la huella de distribución potencial demuestra el efecto de amplificación creado cuando se compromete infraestructura JavaScript de terceros confiable.
Este es un riesgo clásico de cadena de suministro.
En lugar de comprometer organizaciones individuales una a la vez, un atacante puede comprometer infraestructura en la que miles de organizaciones ya confían.
V. Dos Incidentes, Dos Problemas de Seguridad Diferentes
Es importante no combinar los dos incidentes técnicamente.
Involucraron diferentes vectores de ataque.
10 de Septiembre
Vector de ataque: Fallo de autorización SAML SSO
Impacto: Acceso no autorizado a 138 cuentas de clientes
Resultado: Correos electrónicos de phishing enviados a través de cuentas legítimas de clientes de Brevo y datos de contacto exportados de algunas cuentas
14 de Septiembre
Vector de ataque: Credencial API de Cloudflare comprometida
Impacto: JavaScript malicioso inyectado en sitios web de Brevo y recursos integrados por clientes
Alcance potencial: Más de 100,000 sitios web según investigación de seguridad independiente
Resultado: Entrega de malware ClickFix y persistencia de WordPress intentada
VI. ¿Qué Tiene Esto que Ver con DMARC?
Ninguno de los incidentes fue causado por DMARC.
Y ninguno de los incidentes debe representarse como algo que DMARC por sí solo podría haber prevenido.
Sin embargo, los incidentes resaltan por qué las organizaciones deben entender exactamente cómo los servicios de terceros están autorizados para usar sus dominios.
La documentación actual de Brevo proporciona a los clientes una configuración DMARC usando:
v=DMARC1; p=none; rua=mailto:[email protected]Una política DMARC p=none es válida.
Pero es importante entender qué significa.
p=none Significa Monitoreo
Bajo el estándar DMARC actual, un dominio configurado con:
p=noneestá operando en Modo de Monitoreo.
Los sistemas de correo receptores pueden evaluar DMARC y generar datos de informes, pero el propietario del dominio no está solicitando tratamiento restrictivo basado específicamente en un fallo de DMARC.
Esto hace que p=none sea extremadamente útil durante la implementación inicial de DMARC.
Las organizaciones pueden descubrir:
- Qué sistemas están enviando correo electrónico usando su dominio
- Si SPF está alineado
- Si DKIM está alineado
- Qué plataformas de terceros están autorizadas
- Qué infraestructura desconocida puede estar suplantando el dominio
Pero p=none no es aplicación de DMARC.
VII. Monitoreo vs Aplicación de DMARC
Hay tres estados principales de política DMARC.
p=none
Monitoreo
Proporciona visibilidad de la autenticación y alineación.
No se solicita manejo restrictivo basado en el fallo de DMARC.
p=quarantine
Aplicación
Solicita que los receptores traten los mensajes que fallan DMARC de manera más restrictiva.
Dependiendo del proveedor receptor, esto puede involucrar colocación en spam, cuarentena u otro manejo.
p=reject
Aplicación Más Fuerte
Expresa la preferencia de política DMARC más fuerte para mensajes que fallan la validación DMARC.
Los proveedores receptores en última instancia retienen el control sobre la disposición final de un mensaje.
La distinción práctica es:
p=nonemonitorea.
p=quarantineyp=rejectaplican una política.
¿p=none Causó los Incidentes de Brevo?
No.
Este punto es importante.
En el incidente del 10 de septiembre, los atacantes obtuvieron acceso a cuentas legítimas de Brevo.
Si una cuenta de Brevo comprometida envía correo electrónico a través de infraestructura de Brevo debidamente autenticada, esos mensajes pueden pasar DMARC exitosamente.
Cambiar un dominio de:
p=nonea:
p=rejectno necesariamente bloquearía un mensaje malicioso autenticado originado desde una cuenta autorizada comprometida.
DMARC no analiza la intención o el contenido de un correo electrónico.
DMARC responde una pregunta diferente:
¿Este mensaje está autenticado y alineado con el dominio que afirma representar?
Esa distinción es fundamental.
VIII. Entonces, ¿Por Qué Importa la Aplicación de DMARC?
Considere un atacante diferente.
Este atacante no ha comprometido Brevo.
No tiene acceso a Microsoft 365.
No tiene acceso a Google Workspace.
No controla ninguna plataforma legítimamente autorizada para enviar correo electrónico en nombre de la organización.
En cambio, el atacante simplemente intenta enviar:
From: [email protected]usando infraestructura controlada por el atacante.
Si esa infraestructura no puede proporcionar autenticación SPF o DKIM alineada con empresa.com, el mensaje falla DMARC.
Con:
p=noneel propietario del dominio está principalmente monitoreando el fallo.
Con una política de aplicación como:
p=quarantineo:
p=rejectla organización expresa una política de manejo restrictivo para ese mensaje fallido.
Esa es una de las funciones de seguridad más importantes de DMARC.
Reduce la capacidad de un atacante para suplantar directamente un dominio protegido usando infraestructura no autorizada.
p=none Es a Menudo el Punto de Partida Correcto
Las organizaciones no deberían simplemente mover todos los dominios inmediatamente a p=reject.
Hacerlo sin entender el entorno de envío de la organización puede interrumpir el correo electrónico legítimo.
Las organizaciones modernas pueden enviar correo electrónico a través de:
- Microsoft 365
- Google Workspace
- Salesforce
- HubSpot
- Brevo
- Zendesk
- Plataformas de marketing
- Sistemas de facturación
- Sistemas CRM
- Plataformas de RRHH
- Proveedores de correo electrónico transaccional
- Sistemas de tickets
- Plataformas de seguridad
- Aplicaciones internas
Antes de la aplicación, estos sistemas necesitan ser descubiertos y correctamente autenticados.
Es por eso que p=none es a menudo una etapa de implementación apropiada.
La pregunta es si debería seguir siendo la postura de seguridad permanente.
IX. DMARC Implementado No Siempre Significa DMARC Aplicado
Esta distinción se pasa por alto frecuentemente.
Un dominio puede tener un registro DMARC válido mientras aún opera completamente en Modo de Monitoreo.
Por ejemplo:
v=DMARC1; p=none;significa que DMARC está presente.
Pero el dominio no se ha movido a la aplicación.
Es por eso que las organizaciones deben distinguir entre:
Implementación de DMARC
y:
Aplicación de DMARC
No son sinónimos.
X. El Cumplimiento Mínimo No Es la Protección Máxima
Los principales proveedores de buzones de correo exigen cada vez más autenticación de los remitentes masivos.
Estos requisitos han mejorado sustancialmente la seguridad del correo electrónico en todo el ecosistema.
Pero muchos requisitos de remitentes aceptan:
p=nonecomo política DMARC mínima.
La palabra importante es:
mínima
Por lo tanto, una empresa puede satisfacer un requisito de remitente masivo mientras aún opera su dominio en Modo de Monitoreo.
Para empresas, instituciones financieras, empresas reguladas y marcas de alto valor, el cumplimiento regulatorio o de plataforma no debe considerarse automáticamente lo mismo que la protección máxima del dominio.
XI. Los Clientes de Brevo Deben Revisar su Configuración DMARC Actual
Brevo actualmente proporciona a los clientes una política DMARC usando:
v=DMARC1; p=none; rua=mailto:[email protected]Las organizaciones que usan Brevo deben verificar si esta es también la política de seguridad DMARC más amplia de su organización.
Solo debería haber un registro DMARC válido por dominio.
Por lo tanto, las organizaciones deben evitar publicar registros DMARC en competencia simplemente porque múltiples plataformas de correo electrónico solicitan autenticación.
Los remitentes de terceros deben incorporarse en la arquitectura de autenticación existente de la organización.
XII. ¿Deberían las Organizaciones Eliminar Brevo?
No simplemente debido a estos incidentes.
Si Brevo sigue siendo un sistema comercial legítimo utilizado activamente por la organización, eliminar abruptamente los registros de autenticación puede interrumpir el correo electrónico legítimo.
En cambio, las organizaciones deben reevaluar la relación de confianza.
1. Confirmar que Brevo Todavía Es Necesario
Cada plataforma externa autorizada para usar un dominio corporativo debe tener un propósito comercial legítimo actual.
Las plataformas no utilizadas no deben permanecer autorizadas indefinidamente.
2. Revisar la Seguridad de la Cuenta de Brevo
Las organizaciones deben revisar:
- Cuentas de administrador
- Configuración SSO
- Usuarios privilegiados
- Credenciales API
- Credenciales SMTP
- Configuración MFA
- Registros de acceso a la cuenta
3. Revisar su Política DMARC
Determinar si el dominio de la organización actualmente opera en:
p=nonep=quarantineo:
p=rejectNo asumir que la existencia de un registro DMARC significa que el dominio está aplicando DMARC.
4. Identificar Cada Remitente Autorizado
Las organizaciones deben entender cada plataforma que actualmente envía correo electrónico usando sus dominios.
La infraestructura de envío desconocida debe investigarse.
5. Validar la Alineación SPF y DKIM
Los servicios de envío legítimos deben satisfacer DMARC a través de SPF y/o DKIM correctamente alineados.
Esto permite que el correo legítimo continúe mientras se identifica la infraestructura no autorizada.
6. Avanzar Hacia la Aplicación Cuando Sea Apropiado
Una vez que los remitentes legítimos hayan sido descubiertos y autenticados, las organizaciones deben evaluar si continuar indefinidamente en Modo de Monitoreo refleja su postura de seguridad deseada.
7. No Publicar Múltiples Registros DMARC
Un dominio debe tener una política DMARC coherente.
Agregar registros DMARC independientes adicionales puede crear una configuración inválida.
XIII. Acciones Adicionales Después del Incidente del 14 de Septiembre
Las organizaciones que usan componentes de sitios web de Brevo también deben revisar la guía de remediación de Brevo.
Brevo recomienda específicamente acciones si un usuario interactuó con el contenido malicioso el 14 de septiembre.
Si se ejecutó el comando ClickFix
Tratar la computadora afectada como potencialmente comprometida.
Brevo recomienda:
- Desconectar el sistema
- Ejecutar un escaneo de seguridad completo
- Cambiar las contraseñas utilizadas en el dispositivo
- Priorizar las credenciales de cuenta de Brevo
Si un administrador de WordPress visitó un sitio afectado
Las organizaciones que usan scripts de Brevo en WordPress deben revisar los plugins instalados o activados el 14 de septiembre.
Brevo recomienda eliminar plugins sospechosos y cambiar las credenciales de administrador.
Si un usuario inició sesión en Brevo el 14 de septiembre
Brevo recomienda cambiar la contraseña de la cuenta y revisar las credenciales API como precaución.
XIV. Qué Deben Hacer los Clientes de Skysnag
Para los clientes de Skysnag que usan Brevo, no hay ningún requisito automático de eliminar Brevo como remitente autorizado.
Brevo puede permanecer integrado como una plataforma de envío legítima mientras Skysnag continúa gestionando la autenticación de dominio más amplia y la política DMARC.
Su configuración DMARC gestionada por Skysnag existente no debe ser reemplazada por un registro genérico p=none simplemente porque Brevo solicita autenticación de dominio.
El objetivo no es bloquear infraestructura legítima.
El objetivo es asegurar que:
- Los servicios legítimos permanezcan autenticados
- Las fuentes no autorizadas no puedan suplantar fácilmente el dominio
- La alineación DMARC permanezca correcta
- La política de aplicación del dominio permanezca controlada
- Los cambios en el entorno de envío permanezcan visibles
XV. La Lección de Seguridad Más Amplia
Los dos incidentes de Brevo ilustran dos formas diferentes de riesgo de terceros.
El primero mostró que:
Una cuenta de correo electrónico legítima puede convertirse en un canal de phishing cuando la autorización de la cuenta falla.
El segundo mostró que:
La infraestructura web confiable puede convertirse en un canal de distribución de malware cuando las credenciales de infraestructura están comprometidas.
Las organizaciones dependen cada vez más de redes interconectadas de:
- Proveedores SaaS
- Plataformas de correo electrónico
- Sistemas de marketing
- CRMs
- Infraestructura CDN
- Bibliotecas JavaScript
- Proveedores de nube
- Sistemas de correo electrónico transaccional
Cada integración confiable expande las capacidades operativas de la organización.
También expande su límite de confianza.
Eso significa que la seguridad del dominio moderna debe estar estratificada.
La seguridad de la cuenta protege el acceso a plataformas autorizadas.
SPF autentica la infraestructura de envío.
DKIM autentica mensajes.
DMARC valida la alineación del dominio.
Los informes DMARC proporcionan visibilidad.
La aplicación DMARC fortalece la protección contra la suplantación directa no autorizada del dominio.
Ningún control único resuelve todas las clases de ataque.
El objetivo es hacer que esos controles funcionen juntos.
XVI. El Monitoreo Debe Conducir a una Decisión de Seguridad
DMARC p=none tiene un propósito importante.
Proporciona a las organizaciones la inteligencia necesaria para entender su entorno de envío antes de introducir la aplicación.
Pero el monitoreo es más valioso cuando en última instancia informa una decisión de seguridad.
Una vez que los remitentes autorizados hayan sido identificados y debidamente autenticados, las organizaciones deben determinar si permanecer indefinidamente en p=none refleja el nivel de protección que realmente requieren.
Porque hay una diferencia importante entre:
Saber que alguien está suplantando su dominio
y:
Publicar una política destinada a evitar que infraestructura no autorizada lo suplante exitosamente.
El monitoreo proporciona visibilidad.
La aplicación convierte esa visibilidad en política.
XVII. Verifique Su Dominio
Si su organización usa Brevo y no está seguro de si su dominio actualmente opera en p=none, p=quarantine o p=reject, Skysnag puede evaluar su postura actual de autenticación de correo electrónico, identificar infraestructura de envío autorizada y determinar un camino apropiado hacia la aplicación sin interrumpir innecesariamente el correo electrónico legítimo.
Verifique su dominio con Skysnag.
