Una clave robada de Cloudflare convirtió los widgets de Brevo en un canal de distribución de ClickFix

Brevo ha confirmado un compromiso de la cadena de suministro que permitió a los atacantes inyectar contenido malicioso en páginas alojadas por la empresa y en componentes JavaScript integrados en sitios web de clientes.

La operación no requirió modificar los servidores de origen de Brevo. En su lugar, los atacantes utilizaron una clave de API de Cloudflare robada para crear un Worker malicioso que reescribía las respuestas HTTP cuando pasaban por la red perimetral de Cloudflare.

Los cambios no autorizados permanecieron activos durante aproximadamente cinco horas y media el 14 de septiembre de 2026. La empresa de seguridad Sansec estimó que hasta 100.000 sitios web que utilizaban componentes afectados de Brevo podrían haber quedado expuestos, aunque la exposición no implica necesariamente que todos los sitios o visitantes se vieran comprometidos.

La manipulación en el perímetro afectó a páginas y scripts integrados de Brevo

Brevo identificó como principal ventana de exposición el intervalo comprendido entre las 16:07 y las 20:30 UTC del 14 de septiembre. Sansec comunicó un intervalo ligeramente distinto: de las 16:05 a las 20:13 UTC.

Las páginas afectadas incluían contenido distribuido a través de:

• brevo.com
• sendinblue.com
• login/account/my/onboarding.brevo.com
• sibforms.com

El compromiso también alcanzó recursos de Brevo cargados por sitios web de terceros, incluidos el script de formularios de Brevo, el widget Brevo Conversations y los scripts de carga del SDK de Brevo. No se han divulgado las versiones concretas de los componentes.

Esto amplió el alcance del ataque más allá de las personas que navegaban directamente por las propiedades de Brevo. Cualquier sitio web de un cliente que cargara uno de los componentes manipulados podía convertirse en un punto de distribución indirecto para el código de los atacantes.

Brevo afirmó que varios sistemas esenciales no se vieron afectados, entre ellos app.brevo.com, su API, la infraestructura de entrega de correo electrónico y los datos de las cuentas de clientes. No hay indicios de que los atacantes modificaran contenido almacenado en los servidores de origen de Brevo.

Posteriormente, Sansec informó de que los subdominios maliciosos habían dejado de resolver el 15 de septiembre y que los archivos afectados de Brevo habían sido limpiados.

Una credencial de Cloudflare codificada en el código permitió el compromiso

Los atacantes obtuvieron una clave de API de Cloudflare con una vigencia prolongada que estaba codificada directamente en el código fuente de la aplicación. La credencial tenía permisos completos sobre la cuenta, en lugar de un acceso estrictamente limitado.

Estos permisos permitieron crear Cloudflare Workers, reglas de enrutamiento y registros DNS en las zonas de Brevo. Según Brevo, esta actividad no activó ninguna alerta.

A continuación, los atacantes desplegaron un Worker capaz de interceptar y reescribir respuestas en el perímetro de la CDN. El Worker también eliminaba cabeceras HTTP de protección, incluida Content-Security-Policy, que de otro modo restringiría los scripts y recursos que un navegador puede ejecutar.

Esta arquitectura explica por qué los controles convencionales de integridad de archivos no detectaron el contenido inyectado. Los archivos alojados por Brevo permanecieron sin cambios, mientras que los visitantes recibían respuestas alteradas desde la infraestructura de Cloudflare.

Es posible que la credencial quedara expuesta ya a finales de agosto. Sin embargo, Brevo afirmó que no encontró indicios de uso malicioso antes de la ventana del ataque del 14 de septiembre.

Tras detectar el incidente, la empresa eliminó el Worker malicioso y las rutas asociadas, revocó la clave robada e invalidó las credenciales creadas mediante ella. Brevo también eliminó el secreto codificado de su código fuente, borró los nombres de host controlados por los atacantes y purgó el contenido almacenado en caché en el perímetro.

Falsas comprobaciones de Cloudflare dirigieron a usuarios de Windows hacia ClickFix

A los visitantes que recibían el contenido modificado se les mostraba una página de verificación falsa de Cloudflare. A continuación, el señuelo presentaba instrucciones de ClickFix destinadas a convencer a los usuarios de Windows para que ejecutaran un comando por sí mismos.

Los ataques ClickFix se basan en la ingeniería social, no en la explotación directa del navegador. Se indica a la víctima que, para completar una verificación, solucionar un error o superar un control de seguridad, debe copiar y ejecutar un comando. Seguir esas instrucciones puede provocar la instalación de malware.

La información disponible no identifica el comando exacto mostrado durante esta campaña ni la carga útil final para Windows. Por tanto, aún no está claro qué familias de malware recibieron los usuarios que completaron los pasos.

La técnica también ha aparecido en otras campañas de compromiso de sitios web. Una operación independiente utilizó recientemente falsos avisos de verificación en miles de sitios comprometidos de WordPress y PrestaShop, lo que demuestra hasta qué punto pueden distribuirse estos señuelos cuando se alteran recursos web de confianza.

Los administradores de WordPress se enfrentaron a una puerta trasera persistente

El código inyectado realizaba comprobaciones adicionales en sitios WordPress que ejecutaban un widget de Brevo afectado. En concreto, intentaba determinar si el visitante actual estaba autenticado como administrador.

Cuando se cumplía esa condición, el código intentaba descargar un archivo comprimido de plugin malicioso desde:

https://cdn10.sendibt1[.]com/p/wm.zip

Sansec no pudo recuperar el archivo durante su investigación. Sin embargo, una copia localizada en VirusTotal mostró que el paquete se hacía pasar por un plugin llamado Web Media Optimizer.

Su propósito real era proporcionar persistencia, cargar JavaScript remoto y mantener el acceso de los atacantes. Entre la infraestructura relacionada utilizada para distribuir el plugin o los scripts asociados se encontraban:

• https://yelahaye[.]surf
• https://boiseno[.]club

Tras la instalación, el plugin se ocultaba de la lista estándar de plugins de WordPress. También se copiaba en el directorio de plugins de uso obligatorio, desde donde WordPress carga automáticamente los plugins sin requerir una activación normal.

La puerta trasera se comunicaba periódicamente con:

https://glegchner.com/ads.php

En el momento del análisis, ese endpoint devolvía una dirección codificada en Base64 que resolvía a:

https://corralos[.]beer/a412dkoq.js

El JavaScript de esa ubicación se inyectaba en las páginas visibles para los visitantes con el fin de mostrar otro señuelo de ClickFix. El plugin conservaba una copia de seguridad de la URL de JavaScript válida más reciente, lo que le permitía seguir cargando código malicioso si el servidor de control dejaba de estar disponible temporalmente.

Más grave aún, el plugin contenía una clave de autenticación codificada directamente en el código. Los atacantes que tuvieran esa clave podían generar una sesión válida de administrador de WordPress sin conocer la contraseña del administrador. Por tanto, cambiar las contraseñas por sí solo puede no ser suficiente mientras el plugin siga instalado.

Los propietarios de sitios deben revisar los plugins, la configuración perimetral y las credenciales

Los administradores de WordPress que visitaran un sitio afectado mientras tenían la sesión iniciada el 14 de septiembre deberían revisar todos los plugins instalados o activados ese día. La revisión debe incluir el directorio de plugins de uso obligatorio, ya que el paquete malicioso puede no aparecer en la lista habitual del panel de administración.

Los equipos defensivos deberían buscar Web Media Optimizer, los dominios y las URL indicados, archivos PHP inesperados y sesiones de administrador desconocidas. Cualquier plugin sospechoso debe eliminarse de inmediato, seguido del cambio de las contraseñas de administrador y la finalización de las sesiones existentes.

Las organizaciones que utilicen componentes de Brevo también deberían:

• Revisar las páginas y plantillas en busca de formularios, Conversations y scripts de carga del SDK de Brevo afectados.
• Revisar la creación, modificación y actividad de enrutamiento de Cloudflare Workers.
• Examinar los cambios de DNS y los nombres de host creados recientemente.
• Auditar el uso de claves de API y las credenciales generadas mediante tokens con privilegios.
• Revocar las claves potencialmente expuestas en lugar de confiar únicamente en los calendarios de rotación.
• Eliminar los secretos integrados en el código fuente y en los artefactos de despliegue.
• Purgar las cachés de la CDN y de la aplicación después de confirmar que las rutas maliciosas han desaparecido.
• Buscar en los registros de red, proxy, DNS y web la infraestructura identificada.
• Investigar a los usuarios que se toparon con avisos de verificación de estilo Cloudflare y posteriormente ejecutaron comandos.

No se ha divulgado el número de infecciones. La estimación de Sansec de hasta 100.000 sitios web expuestos describe el posible alcance de distribución, no el número de instalaciones exitosas del plugin ni de compromisos de Windows.

El incidente se produce tras otra campaña de secuestro de cuentas de Brevo

El compromiso de Cloudflare se produjo poco después de otro incidente de seguridad relacionado con Brevo. El 10 de septiembre, la empresa informó de una campaña vinculada al SSO en la que los atacantes secuestraron cuentas de clientes y las utilizaron para enviar mensajes de phishing.

El proveedor de carteras de criptomonedas Trezor informó el 11 de septiembre de que la campaña alcanzó 347.000 direcciones de correo electrónico de usuarios y provocó el compromiso de al menos 2.500 cuentas.

Brevo no ha confirmado si esa actividad de secuestro de cuentas estaba relacionada con la clave de API de Cloudflare robada. Sin pruebas que vinculen a los operadores, la infraestructura o los métodos de acceso, ambos incidentes deben tratarse como investigaciones independientes.

No obstante, el último compromiso deja al descubierto un límite de confianza de alto impacto: una única credencial de CDN con privilegios excesivos permitió a los atacantes manipular contenido en dominios controlados por Brevo y potencialmente en miles de sitios de clientes, mientras los archivos originales permanecían intactos.